ASLR vulnerability and EMET remedy

I saw other posts about the IE vulnerability, but I wanted to post this because of the info on the ASLR vulnerability for Windows in general and the EMET remedy:
http://krebsonsecurity.com/2010/12/exploit-published-for-new-internet-explorer-flaw/

A Comodo moderator suggests that the buffer overflow protection of Defense+ is another remedy for the ASLR vulnerability:
http://forums.comodo.com/news-announcements-feedback-cis/microsoft-issues-warning-about-critical-ie-hole-t66815.0.html

For more info and options on Comodo's technology, see https://ssj100.forumotion.com/t294-dep-vs-comodo-memory-firewall

It would be great if I could get a functional POC of this vulnerability. Then we could put it to the test!

Windows XP doesn't have ASLR, so the Comodo protections are presently the only options I am aware of for XP users.

Yes, I think that's correct. However, people who use Sandboxie appropriately should have nothing to worry from this - it's just another exploit of the many that are discovered/released monthly.

ssj100 wrote:It would be great if I could get a functional POC of this vulnerability. Then we could put it to the test!

Seems like this vulnerability could be used for a Ret2Libc attack. The Comodo BO Tester, then, is one such POC.

ssj100 wrote:Yes, I think that's correct. However, people who use Sandboxie appropriately should have nothing to worry from this

On the "ssj100's Security Setup" page, I don't see that Sandboxie prevents:
1. Malware reading passwords stored in the browser.
2. Malware changing bookmarks/favorites to point to phishing sites.
3. Malware hijacking the browser to serve in a botnet, to send spam, to hack sites that you password entry, etc.

Binky wrote:Seems like this vulnerability could be used for a Ret2Libc attack. The Comodo BO Tester, then, is one such POC.

I'd like to get a working sample regardless, since I've already tested the Comodo BO Tester.

Binky wrote:On the "ssj100's Security Setup" page, I don't see that Sandboxie prevents:
1. Malware reading passwords stored in the browser.
2. Malware changing bookmarks/favorites to point to phishing sites.
3. Malware hijacking the browser to serve in a botnet, to send spam, to hack sites that you password entry, etc.

I thought we'd already gone over this? By following steps 7-9 under "Sandboxie", you don't need to worry about such things. Furthermore, buffer overflow exploits always lead to the downloading and running of a foreign executable in order to eg. read passwords and hijack browsers. Such foreign executables would be blocked by most anti-execution software/mechanisms and Sandboxie's start/run restrictions alone would block plenty of these too. Regardless, once the browser sandbox is deleted, all this is academic.

Also, it appears the concerns Binky lists above are purely speculative (unless someone would like to provide me a POC or malware that's able to carry out such behaviour without the running of a further executable), but I like it! So let me speculate too - here's one such (purely theoretical) scenario/example that one may be thinking of, although I'm not a hacker/programmer, so I don't know if this will make much sense haha:

1. User visits a web-site with the IE browser
2. The web-site contains a Ret2Libc Buffer Overflow attack
3. The Buffer Overflow attack doesn't require javascript or any other scripting code to be enabled for that matter. In fact, it is able to run even if you only allowed ".txt" code to be displayed
4. The Buffer Overflow attack subsequently creates shellcode running in memory (nothing ever needs to be directly written on to the disk)
5. The shellcode becomes a staged process which creates/propagates malicious executable code (purely in memory)
6. This code is then able to carry out the above three issues listed by Binky
7. Hence Binky's recommendation/inclination to use Comodo Internet Security for its Buffer Overflow protection.

I think to say that the above scenario is very unlikely is an understatement. In fact, I doubt this scenario is possible, and even if it is, what are the chances of coming across such malware in-the-wild? Also, Sandboxie will contain all this anyway, and nothing will change on the REAL system - once the sandbox is deleted, you're completely clean again.

So the question is whether it's worth going to the trouble of installing CIS for its Buffer Overflow protection (which may or may not protect against all exploits of this kind) and risk conflict. Does the apparent added protection balance out the risk of (hidden/undiscovered) conflicts to shift the risk-beneft ratio favourably? I doubt it. Also, it can be difficult to observe conflicts unless you're really looking hard and actually using POC's and actual malware to do your testing. I think normal everyday computer use will not reveal the conflicts which result in security holes.

Can Binky or someone else try testing EMET against the Comodo BO Test?

I've personally tested on Windows 7, 32-bit, and EMET failed all three tests (even at maximum settings). And yes, I specifically added the BO Test executables (botester.exe, botester32.exe) to be covered by DEP, SEHOP, HeapSpray, MandatoryASLR, etc. However, here are some possibilities for the failure:
1. The Comodo BO test is not compatible with Windows 7 (it was released before Windows 7 existed)
2. I tested in a Virtual Machine and this could have impacted the results negatively

ssj100 wrote:Furthermore, buffer overflow exploits always lead to the downloading and running of a foreign executable in order to eg. read passwords and hijack browsers. Such foreign executables would be blocked by most anti-execution software/mechanisms and Sandboxie's start/run restrictions alone would block plenty of these too.

Not all such exploits are from .EXE or .DLL downloaded files. They can be JavaScript, Java, Flash/Action Script, etc. NoScript helps with the odds of get exploited, but my spouse freely allows scripts for all sites on a page when trying to get a TV show from some new site to play.

ssj100 wrote:Regardless, once the browser sandbox is deleted, all this is academic.

Binky wrote:On the "ssj100's Security Setup" page, I don't see that Sandboxie prevents:
1. Malware reading passwords stored in the browser.
2. Malware changing bookmarks/favorites to point to phishing sites.
3. Malware hijacking the browser to serve in a botnet, to send spam, to hack sites that you password entry, etc.

1. Stolen passwords creates problems for the user after the sandbox is deleted.
2. If the user visits a phishing site and enters personal information, same issue. Also, your documented setup doesn't say that you prevent all bookmark/favorites updates and option settings, which is impractical for most users.
3. Your banking site can be hacked to give you the exploit. Cyber thieves are quite crafty. For me, even my non-banking passwords are valuable.

My choice is either to protect against published Ret2Libc vulnerabilities with Comodo specific buffer overflow protection or avoid all third-party security software (besides Sandboxie) for the academic possibility that Sandboxie+Comodo will allow some unpublished, obscure vulnerability. I choose the former.

ssj100 wrote:I've personally tested on Windows 7, 32-bit, and EMET failed all three tests (even at maximum settings).

Not sure if you mean that your PC is vulnerable or protected by ASLR against Comodo's test of Ret2Libc.

ssj100 wrote:EMET failed all three tests (even at maximum settings).

In order to install the mitigations, EMET needs to create a new thread in the target process, which means that the protection is not enabled immediately. This suggests that you could successfully attack an application within the first few milliseconds. This also means that while testing, you should kindly wait a little before executing shell code, otherwise you can't take part in the hype circus.
P.S.: I'm sure that as soon as EMET is systematically and successfully bypassed, that someone from MS will tell us that this tool was never meant to be a security tool, that is was actually developed to teach developers to write safer applications, and that all safe hex rules (you know: don't download and/or run untrusted code) still apply. The tool may cause trouble for legitimate applications, however, as we've seen already, for example with Chrome last month.

Paul

Binky wrote:Not all such exploits are from .EXE or .DLL downloaded files. They can be JavaScript, Java, Flash/Action Script, etc. NoScript helps with the odds of get exploited, but my spouse freely allows scripts for all sites on a page when trying to get a TV show from some new site to play.

Yes, we've already gone over that too. The fact is that many exploits involve .EXE and .DLL - in fact, give me an example of an exploit AND the actual malicious action which doesn't involve one - I suspect you'll find it hard to find one. But the point is that if you know what you're doing with Sandboxie, this is all purely academic once the sandbox is deleted (regardless of whether the exploit is in the form of JavaScript etc).

Binky wrote:1. Stolen passwords creates problems for the user after the sandbox is deleted.

Sure, but you seem to be avoiding the explanation of how exactly passwords can be stolen - are you sure blocking BO attacks will prevent or reduce the risk of this? As I said, I still don't understand how passwords can be stolen/logged via eg. JavaScript alone. If you can't produce even an example (or preferably an actual working POC), this is all purely speculation. This same level of speculation can be applied to the risk of hidden conflicts caused by running more than one kernel hooking third party application - and the fact that I was able to reproduce a malicious bypass of Sandboxie in the past (about a year ago) with Comodo installed means that this risk is arguably more REAL than the purely speculative risk you are worried about.

Binky wrote:2. If the user visits a phishing site and enters personal information, same issue. Also, your documented setup doesn't say that you prevent all bookmark/favorites updates and option settings, which is impractical for most users.

Again, see above. My documented setup doesn't say anything about bookmarks/favourites because I personally don't use any haha. My documented setup isn't meant for "most users" - I have never said it was. In fact, "most users" probably would not be able to understand 99% of what I wrote. What I have implied strongly in the past is that I believe it's the strongest setup/approach for me (and probably many others).

Binky wrote:3. Your banking site can be hacked to give you the exploit. Cyber thieves are quite crafty. For me, even my non-banking passwords are valuable.

Again, purely speculative (or at least that's what I think from my current level of knowledge/experience...you can simply prove me wrong by giving me an example/POC etc, even if it's historical) - how exactly does the script or whatever steal/log passwords etc without the use of PE executable code? Trust me, again, if you can say give me a working POC (which includes both the actual exploit AND the eg. keylogging process), then I will be more convinced.

Binky wrote:My choice is either to protect against published Ret2Libc vulnerabilities with Comodo specific buffer overflow protection or avoid all third-party security software (besides Sandboxie) for the academic possibility that Sandboxie+Comodo will allow some unpublished, obscure vulnerability. I choose the former.

In my opinion, the unpublished, obscure vulnerabilities are the ones to worry about. Others are often patched before the exploits are seen in-the-wild (or before the home user comes across them), simply because they are known. And after nearly 2 years of intensive experimentation and bouncing ideas off various knowledgeable people, I still choose the latter.

Don't get me wrong, I've thought about exactly the same issues as you in the past - you only need to look at my BO testing threads to see that. Anyway, you've made some excellent points and I look forward to you proving me wrong, or at least influencing me enough to install Comodo's BO protection! Cheers mate.

EDIT: by the way, in the end, it's all about what helps you sleep at night (I just like comparing and contrasting from a personal point of view). Furthermore, it seems that your wife shares the same computer as you? If so, this potentially complicates things a lot, and I don't think the fact that she enables all scripts is the only/main worry!

Binky wrote:Not sure if you mean that your PC is vulnerable or protected by ASLR against Comodo's test of Ret2Libc.

I thought it was clear enough haha - I said EMET fails the test. This is on Windows 7, 32-bit, in VirtualBox. It would be good if someone could kindly test Comodo's BO tool on their REAL Windows 7 system and post the result.

p2u wrote:In order to install the mitigations, EMET needs to create a new thread in the target process, which means that the protection is not enabled immediately. This suggests that you could successfully attack an application within the first few milliseconds. This also means that while testing, you should kindly wait a little before executing shell code, otherwise you can't take part in the hype circus.

After "enabling" EMET, I restarted the system mate - surely that's more than a few milliseconds right?

p2u wrote:P.S.: I'm sure that as soon as EMET is systematically and successfully bypassed, that someone from MS will tell us that this tool was never meant to be a security tool, that is was actually developed to teach developers to write safer applications, and that all safe hex rules (you know: don't download and/or run untrusted code) still apply. The tool may cause trouble for legitimate applications, however, as we've seen already, for example with Chrome last month.

I can see that you've "seen the worst", or at least you always think about the worst case scenarios. I really like that - "prepare for the worst, hope for the best" though right?

ssj100 wrote:

Binky wrote:Not sure if you mean that your PC is vulnerable or protected by ASLR against Comodo's test of Ret2Libc.

I thought it was clear enough haha - I said EMET fails the test. This is on Windows 7, 32-bit, in VirtualBox. It would be good if someone could kindly test Comodo's BO tool on their REAL Windows 7 system and post the result.

I suspect Comodo's BO Tool tests something else, and that EMET will always fail. I don't know what exactly Comodo BO Tester does; haven't tried it and probably never will because I don't believe in that kind of protection.

Without intending to offend anyone, I also suspect that one should make a choice:
* either you use Sandboxie and avoid any other third-party protection, or you
* avoid Sandboxie and start using combined third-party "crutches".

Paul

ssj100 wrote:After "enabling" EMET, I restarted the system mate - surely that's more than a few milliseconds right?

I think you will face the same problem in every new session, no? Haven't tried any of this; just theorizing.

Paul

p2u wrote:I suspect Comodo's BO Tool tests something else, and that EMET will always fail. I don't know what exactly Comodo BO Tester does; haven't tried it and probably never will because I don't believe in that kind of protection.

At least two out of the three tests should be blocked by EMET, simply from Hardware DEP being enabled - I know this is the case for Windows XP, because I've personally tested it (I had to do it on my REAL system to get accurate results). However, Hardware DEP fails against one of the tests (Ret2libc), and I was curious as to whether this now passes with EMET on Windows Vista/7.

p2u wrote:I also suspect that one should make a choice:
* either you use Sandboxie and avoid any other third-party protection, or you
* avoid Sandboxie and start using combined third-party "crutches".

It seems we're in agreement (mostly) once again haha - better not make it a habit! However, Binky has raised some important points, and I don't doubt that we'll be re-visiting those points again in the future.

However your second option of "avoid Sandboxie and start using combined third-party "crutches"" would be fine as long as there's only one kernel hooking third party application involved (at least in my opinion).

The real problem is that too many people think that you can combine just about anything and go unpunished. If the system doesn't crash, this is interpreted as if all these applications are "compatible". When I see a topic on wilderssecurity like "What is your security setup?" I feel cold shivers going down my spine. Most are actually drastically weakening their so-called "protection"...

Paul

The challenge for me is to provide security yet allow my non-technical spouse, on the same PC, to do her normal things without great inconvenience. This includes online banking, online orders with the credit card, watching TV shows uploaded by viewers, online searches, bookmarking sites, etc. Sandboxie and NoScript provide most of this security, but not all.

I find the Comodo firewall (excluding HIPS) helpful. I block all communications that I can. The default web browser policy allows only UDP-based DNS requests and TCP requests to HTTP+FTP ports, which Sandboxie and Windows XP firewall cannot do. Many of my programs (outside the sandbox) want to phone home for updates and who knows what, especially installers. Brian Krebs reported on how automatic update mechanisms are being exploited. By performing a reverse-DNS on the firewall log on one of my "trusted" applications, I found that it attempted to send to Google, Yahoo and Microsoft sites. When the installation agreement says that the company will not send any personally-identifiable info from your PC, they omit the truth that your IP address together with other info they and others (online retailers) have collected into a common database IS enough to personally identify you.

Even though Sandboxie will delete malware executables when closing the browser, it is very helpful to alert the user about the malware before they continue surfing to other sites with a compromised browser (even when not doing online banking). When my spouse visited an evil site accidentally one time, the anti-virus produced a pop-up that alerted her, and she promptly closed the browser. This is because the pop-up text is easy to understand. With the heuristics disabled to minimize false positives, I find the Comodo AV quite competent.

With my decision to use Sandboxe+Comodo firewall+Comodo AV, there is only a small change to include only the buffer overflow protection of Comodo's Defense+ (see my other thread on config details). Since these Comodo protections all come together in a suite, they have been tested together. I find that there are many users on the Comodo and Sandboxie forums that use both, and both companies strive to make them work together.

With the discussions we had in the last couple of months, I believe that we have exposed the pros and cons of installing Comodo's buffer overflow protection. In this thread, we see the vast difference in user knowledge and behavior for which our security solutions apply. So I don't expect that we will arrive at the same strategy. I value our discussions and have learned many useful things.

Kind regards