DefenseWall pitfalls
2 posters
Page 1 of 1
DefenseWall pitfalls
My first ever upload to youtube. Apologies in advance for horrible quality (it's a bit more visually bearable on the youtube site itself):
Re: DefenseWall pitfalls
Good initiative! Thanks.
I've been pointing out this problem for a couple of years now, but Ilya has a standard reply: "I don't see how images and text files may hurt the system". Unless you give him a working exploit, he probably won't change this behavior.
P.S.: Although I respect Illya both as a pro and as a person, I find it rather disturbing to see that for almost every major escalation problem in Windows, he has to alter his code. In standard situations he is probably right, but Windows has so many backdoors planted in, that a targeted attack against DefenseWall may not be hard to accomplish.
Paul
I've been pointing out this problem for a couple of years now, but Ilya has a standard reply: "I don't see how images and text files may hurt the system". Unless you give him a working exploit, he probably won't change this behavior.
P.S.: Although I respect Illya both as a pro and as a person, I find it rather disturbing to see that for almost every major escalation problem in Windows, he has to alter his code. In standard situations he is probably right, but Windows has so many backdoors planted in, that a targeted attack against DefenseWall may not be hard to accomplish.
Paul
p2u- Valued Member
- Posts : 211
Join date : 2010-12-14
Re: DefenseWall pitfalls
Thanks for the comments p2u. I too attempted to point out those problems on the DefenseWall forums over a year ago and I ended up getting IP banned for a year. Mind you, it wasn't Ilya that banned me.
Ilya provides some of the best support out there and I generally support his cause - why else would I be so interested in his program?
Anyway, I just did some brief (re-)testing on Windows 7 Professional with DefenseWall. It appears that if you add "dllhost.exe" to the Untrusted programs list, Windows Photo Viewer (which is the default image viewer program for Windows 7) will force run Untrusted whenever it's called. In fact, as far as I can tell, this is the only way you can get image files to open Untrusted on Windows 7 (without installing a third party image viewer).
I suppose the question now is why "dllhost.exe" isn't in the Untrusted list by default?
And unfortunately, there is no such solution on Windows XP.
Ilya provides some of the best support out there and I generally support his cause - why else would I be so interested in his program?
Anyway, I just did some brief (re-)testing on Windows 7 Professional with DefenseWall. It appears that if you add "dllhost.exe" to the Untrusted programs list, Windows Photo Viewer (which is the default image viewer program for Windows 7) will force run Untrusted whenever it's called. In fact, as far as I can tell, this is the only way you can get image files to open Untrusted on Windows 7 (without installing a third party image viewer).
I suppose the question now is why "dllhost.exe" isn't in the Untrusted list by default?
And unfortunately, there is no such solution on Windows XP.
Re: DefenseWall pitfalls
Maybe security providers are forced to do this if they want to get the 'compatible with...' logo?ssj100 wrote:I suppose the question now is why "dllhost.exe" isn't in the Untrusted list by default?
P.S.: One of the reasons I don't use all these suites and modern 'cloud' solutions is that fully trusting Microsoft applications is one of the worst things you can do from the security viewpoint (no MS bashing intended). As I said before in another topic: I have removed most of it from my computer and nothing by MS is allowed to get out through the in-built firewall with Advanced security, the only exceptions being:
svchost.exe for DHCP, explorer.exe for DNS (provider's addresses only), 'System' for L2TP (kind of VPN tunnel - provider's addresses only) and the 'hardened' Windows update services (also svchost), although these last rules (WU DNS + WU HTTP(S)) are systematically disabled until I know for sure that there are updates available. It's actually funny to see Microsoft silently blocking itself all the time when some leaktest or test exploit calls either svchost or IE (my default browser; at least that's what the system thinks). Besides, since I'm in a limited account, I can't even change the firewall rules, even if I want to. No stupid alerts, and everything locked with the Admin password, wich I pretend not to know.
Paul
p2u- Valued Member
- Posts : 211
Join date : 2010-12-14
Re: DefenseWall pitfalls
Interesting, although I can't help feeling a bit of paranoia emanating from you haha. In my opinion, if one truly doesn't trust Microsoft, one should (only) be using Linux.
Re: DefenseWall pitfalls
I'm not talking about real-life trust or distrust, of course. It's PRETENDING not to trust, just like pretending I don't know the admin password for elevating my user rights; it's just a security stance and a very effective one at that.ssj100 wrote:Interesting, although I can't help feeling a bit of paranoia emanating from you haha. In my opinion, if one truly doesn't trust Microsoft, one should (only) be using Linux.
P.S.: As far as my block rules are concerned: it's plain Default Deny. If not configured, it's not allowed. This doesn't mean that I'm actively blocking running services, which would be a very bad thing to do. Svchost is just so limited with all those unnecessary services disabled and removed, that it makes only the minimum required queries, nothing more. The rules were set up in accordance with what the system asks. If explorer.exe only asks DNS, why allow just ANY type of connections, as you can witness in almost any Matousec Contest winners' solutions? In case of an exploit, this would make the hacker's task just too easy. Besides, I hate alerts and a limited user shouldn't be forced to take this kind of decisions.
P.S.: For an exploit to work, all conditions have to be just right, otherwise it will fail. Usually, the exploit has different stages, which should be blocked if possible. Suppose I have Parental Controls on, but that one doesn't block dll's. Is that a nightmare? Not necessarily if all the other conditions on the work station are right. A dll needs code around it, something that loads it. If this 'something' is not present or it is blocked, the exploit won't work. Blocking the executable should really be the last stage. If you can block the download of a dropper in your firewall, this is good enough protection. Rmus makes a good point about it here: anatomy of an exploit and what you can do against it.
Paul
Last edited by p2u on 22/12/2010, 13:01; edited 1 time in total
p2u- Valued Member
- Posts : 211
Join date : 2010-12-14
Similar topics
» DefenseWall pitfalls
» DefenseWall v3.03
» DefenseWall v3.11 released
» DefenseWall and Sandboxie together?
» DefenseWall v3.04 released
» DefenseWall v3.03
» DefenseWall v3.11 released
» DefenseWall and Sandboxie together?
» DefenseWall v3.04 released
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum
|
|