Application Sandboxes: A pen-tester’s perspective

But I did see it with my own eyes round Earth. i have no reason not to think that SBIE cannot be bypassed, there are posters here like "ComputerSaysNo" who actually saw VirtualBox getting bypassed and similar stuff-I have no reason not to think that it cannot be done, I'm only saying that these tests are not enough, plus all of these tests ignore that keylogging and everything else (except kernel exploits) in the test can be blocked if you configure SBIE.
And I think it takes much more knowledge than just this test shows.

Also, what do you think about this:
"The key problem with Google Chrome's browser's sandbox is using and relying on internal Windows security mechanisms. One sucessfull privilege escalation vulnerability exploitation-and your defense is broken, SBIE does not depend on this, and this is a key difference and a key reason why I have more trust in SBIE than in Google Chrome, because of this SBIE really is more secure than Chrome.
Similar comparison comes with the old GesWall and DefenseWall-Geswall also uses and relies on internal Windows security mechanisms, unlike DefenseWall which does not-because of these facts, I'd rather pay for DefenseWall than for GesWall, this is why I rather use DefenseWall because of this non-mentioned fact DefenseWall is more secure than GesWall-exactly the same situation we have with SBIE and Google Chrome."

 

Lucky you, I always hesitate about using such products because they seem to be very similar in their approaches-I'm scared of incompatibility issues.

 

I'm not sure how they manage to work together. If a program makes a call and they intercept it, how is it handled when two programs attempt to intercept that call?

If it's done through hard overwriting of the process, I really don't see how it's possible.

If it's done through a Windows API I suppose it could just pass it from one to the other - but which one goes first? The details of how it's handled are more than I'd like to risk.

If a developer would like to comment on that, I'd appreciate it, as I truly don't know how that would be done.

 

Unfortunately, I can't harden Google Chrome on my windows xp, unfortunately there is no way of hardening Google Chrome on my windows xp.

 

I think I understand my misunderstanding here:
SBIE4, like AppGuard 4 does block all of the mentioned real world threats, however SBIE4 must be tightly configured to block such threats.
SBIE4 tightly configured does block and protect kernel mode malware/exploits, user mode malware/exploits, keylogging, remote webcam/mic access, clipboard hijack, screen scraping, steal files, network shares access as well as DefenseWall and Appguard do the same.

However, none of these products can block OS kernel exploits that depends on system's flaws, but they can block and protect against OS user mode exploits-that depends on system's flaws and everything else mentioned here and in tests, but definitely not against OS kernel mode exploits-that depends on system's flaws.
So all of the products mentioned can and they all do block and protect against kernel exploits/malware and everything else, but they cannot block/protect against OS kernel exploits-that depends on system's flaws-that's a key difference.

 

@CWS: I'm not sure what you're talking about. The only way you'd have a kernel-mode exploit that wasn't related to the OS, would be an exploit in a third-party driver.

Anyway, yes, security software can in practice block kernel exploits... some kernel exploits. I obviously haven't done much research on this, but so far I've found it depends heavily on which exploit we're talking about, and which security software.

Basically some kernel exploits have prerequisites - spawning a new process, writing a temp file, stuff like that - which can be blocked by HIPS/sandbox software. But that's different from actually making the kernel more secure (which is basically impossible on Windows).

Sandboxie does currently block Metasploit's entire repertoire of kernel attacks against Windows XP, but that doesn't mean that it will block future ones, or be capable of blocking future ones with any amount of configuration. I can already name one exploit that it can't block, period:

http://technet.microsoft.com/en-us/security/bulletin/ms06-002

Long story short: yes, security programs can block kernel attacks. But no, they cannot be trusted to block kernel attacks.

 

So what is a difference between kernel exploits and OS kernel exploits?
I don't believe this software is meant to protect against kernel vulnerabilities. Patching and updating OS is IMO a way to go.

 

I think I understand now, too bad none had the will to explain it like this like you did now-or maybe I just did not understand enough-that's my fault than.
Is Windows XP Professional Service Pack 3 vulnerable to this exploit?

So, the main question is if TIGHTLY CONFIGURED SBIE4 (and NOT SBIE4 on default level) can or cannot block this mentioned Metasploit exploit that you put the link on (big thanks for that), but what about AppGuard and DefenseWall or antivirus, antimalware firewall, anti-exploit, HIPS and etc.?

What about hardening Google Chrome on Windows XP, Windws Vista/7/8? I'm really hesitating in using it on my Windows XP, because I'm a bit confused, if I install Google Chrome, I want to harden it as well but I don't know how to do it on my Windows XP.

I guess the answer is the same-they all can't block it, they all can't protect against this or other exploits or exploits that will appear in the future.
What is your answer here?
I realize that all of the mention software products can block only some of the kernel exploits, not all.
Is there a difference in saying kernel exploits and OS kernel exploits, or both types of these exploits use OS (OS=operational system) vulnerabilities/holes?

If the answer is yes, I'm not sure to ever step on the net ever again, I mean right now when I'm writing this, someone could use that kernel exploits against my Windows XP PRO Service Pack 3 OS (OS=operational system) and the game is over-now I'm freaking hyper-paranoid!

However. why I'm so sure in my opinion that tight configuration can protect against everything-if there is a possibility to configure protection for everything inside SBIE, here's why:
After all I saw this thread where you have tested Comodo, OA SBIE and etc. and SBIE4 came on top-again.

Also, another reason I'm so stubborn in my opinions is because when I saw this:
http://www.sandboxie.com/phpbb/viewtopic.php?p=88252

This is how Sandboxie was able to protect against this exploit, there is always a workaround-this is a real world example, on which my opinion is actually based on, if you have possibility to configure everything from the lowest/kernel to the highest level, than you can block/protect even against these OS kernel exploits as well and this link above actually proves it.

I also always recommend to test tightly configured both SBIE and tightly configured Google Chrome as well, however SBIE is just far more configurable than Google Chrome on what I've seen so far.

 

i was hoping that someone will explain if there is a difference between kernel exploits and OS kernel exploits-since it specifically says OS kernel exploits, it doesn't say kernel exploits?
Is this what Bromium labs says: that kernel exploits are actually OS kernel exploits, than my argument sucks-or there really is a difference in saying and describing on what kernel exploits are and what OS kernel exploits are?

Are OS kernel exploits and only saying kernel exploits-exactly the same thing or there is a key difference, I'd like to know the answer to this question, I'll leave to the experts to answer this.
Do kernel exploits actually mean OS kernel exploits or there are other kernel exploits that are not connected and have absolutely nothing common with OS, because they are something else?
I truly hope someone can explain this a bit more detailed than usual.

 

They are the same thing. The kernel is a piece of the operating system. I've never heard anyone make a distinction but, if there were one, it would be what GJ said - third party kernel modules.

 

@CWS,

what you're doing currently is probably - but no guarantees! - perfectly fine for now and the foreseeable future, unless exploits evolve well beyond the typical stuff that's floating around like the Cryptolocker and fake AV crap that counts mostly on social engineering for success, but even utilizing driveby trigger mechanisms, your setup and those of other highly skilled XP users like yourself in these forums should not be affected by them, unless due to a mental slip and you click the wrong attachment. Hopefully the kernel exploits GJones and some others mention don't evolve into mainstream stuff any time soon. You guys are taking a calculated risk for sure, but I get the feeling it's a pretty low risk. For less skilled, non-security-aware XP users, a much bigger risk. That's all.

Whatever browser you use you might want to utilize scripting control (yeah, I'm a big fan of it these days) so Firefox with NoScript (the best extension of it's type) or Chrome with one of the available extensions (HTTP switchboard) is looking really good is an approach you might want to consider if you haven't already.

This has been a good thread - HM and GJ definitely harbor some deep knowledge on the kernel issues that simply can not be ignored - and I feel you held your own pretty good, in spite of some stubborness but you brought up many good points.

 

You should not worry about those exploits as they are rarely used in common attacks.
Only time I came across kernel exploit IRL was when Sasser hit computers on net. After MS patched OS and introduced firewall with SP2 I have never met anything similar.
As wat0114 said - just practise safe computing and you should be fine.

 

Thanks for the support, I thought I started to have a status of cyber-heretic.
I still think that this Metasploit can be blocked by SBIE4's tight restrictions, nonetheless, because SBIE is always used on default level for testing-so we will see what will Gullible Jones say.
According to Peter's words, kernel exploits are not the same as OS kernel exploits, obviously there are other kinds of kernel exploits than just OS kernel exploits
After all I saw this thread where Gullible Jones has tested them and SBIE came on top again.

Also, the reason I'm so stubborn in my opinions is because when I saw this:
http://www.sandboxie.com/phpbb/viewtopic.php?p=88252

This is how Sandboxie was able to protect against this exploit, there is always a workaround-this is a real world example, on which my opinion is actually based on, if you have possibility to configure everything from the lowest/kernel to the highest level, than you can block/protect even against these OS kernel exploits as well and this link above actually proves it.

I also always recommend to test tightly configured both SBIE and tightly configured Google Chrome as well, however SBIE is just far more configurable than Google Chrome on what I've seen so far.
I will listen to your advice and use NoScript for firefox, and HTTP Switchboard for Google Chrome.
Your advices are always very helpful and big thanks for all of them.

 

Thanks, but they're only suggestions. The approach may not be to your liking. Whatever works best for you in terms of the balance between security without giving up too much convenience. Script control can involve a lot of time, especially in the early going until you build up a considerable whitelist/blacklist, and even more work if you surf many different sites. Just something to keep in mind. As is always usual with anyone, your mileage may vary

 

Script blocking etc stuff is out of this theoretical thread.
They are very important to our privacy though.

 

If I am not mistaken, is Rafal Wojtczuk the one and same whom previously worked with Joanna Rutkowska at Invisiblethingslab.com where he co-authored several papers with her, and worked on earlier versions of the Qubes Security OS?

-- Tom

 

I have had take a look on Google Chrome and it's hardening options, and it's faaar, faaar less on what SBIE does with its configuration, actually it's very, very limited compared to SBIE's options.
I ignore plugin/script blocking since it's very much unuseful when i want to enter my hotmail account for example.
HTTP Authentication is not a big deal either, SBIE by itself without need of all of these add-ons takes care much better than Google Chrome when properly configured.
Also, using properly configured SBIE alone I still do much, much more than what you do with Windows Firewall with inbound/outbound control, group policies like Applocker or SRP and tightly configured Google Chrome which is btw, still very, very limited when it comes to its configuration options-that's why Google Chrome needs help from Windows Firewall with inbound/outbound control, group policies like Applocker or SRP.
Cheers.

 

I don't think that you can compare SBIE with Win FW, SRP, Applocker and others. Windows built in restrictions can be applied system-wide while SBIE's controls are usually applied for specific applications. There are other differences also. One example: You can't set SBIE to allow only some network traffic (specific ports, protocols and IP addresses) but you can do that with Windows FW.
OTOH I do agree that when it comes to protecting specific app, SBIE gives you more options than Windows built-in restrictions.

 

Yes, that seems to be the case:
https://www.blackhat.com/usa/speakers/Rafal-Wojtczuk.html
http://invisiblethingslab.com/itl/About.html

 

Well, you can create enough sandboxes for the entire system and everything regarding system and configure them, however my point here is also that hardening Google Chrome with tight configuration does not beat hardening SBIE with tight configuration, SBIE easily beats Google Chrome in this category.

Maybe, by default Google Chrome truly is superior to SBIE, but SBIE easily overpowers Google Chrome thanks to its incredible configuration abilities, and that's why SBIE (not on default, but on tight configuration level) is far more secure than Google Chrome.

If we talk about protocols, network traffic, IP address, eveything inbound is blocked on my computer with router firewall with SPI with maximum protection and also Windows XP firewall with maximum protection.
SBIE takes care of the outbound protection (start/run restrictions, block access restrictions, internet access restrictions).

Hey one question, I see you are using Malware Defender-I'd like to try to use it, but how do you know what is safe and what is not safe?
This is more like for real hard professional to use than for others like me.
Sure I do know enough about system and configuration, but Malware Defender is bit above my knowledge how to deal with it.

 

If you like to have control over almost everything that's happening on your system then that's a tool you've been looking for.
Here is a nice thread that describes one way of configuring MD: https://www.wilderssecurity.com/showthread.php?t=252773
I do it the other way, but there is no right way or wrong way...
I would suggest you to put MD in Learning mode and let it create rules automatically. Then you can check them up and sort apps in different groups that you can create. After some time you can disable Learning mode and use MD in Normal mode (popup mode) or Silent mode (default deny).
You can try it and see if you like it. If you will play with it long enough you will learn a lot about your system and applications that you are using.