Application Sandboxes: A pen-tester’s perspective

The problem is not about what Chrome can't do. The problem is if AppGuard will interrupt Chrome to be fully functional in making use of its own security mechanism. See the links about RunSafer here:

 

I am confused are we talking about Appguard or OA. Runsafer=Online Armor. Like Peter2150 said they are different things.

 

Aaaarrgh... is my grammar so broken which makes people keep misunderstanding what I'm saying?

I'm not comparing AppGuard with RunSafer. I just pointed out that RunSafer could break some programs from making use of their built-in security mechanism properly. Thus, I wonder if AppGuard will break Chrome or other software as well. The reason why I included links about RunSafer is because they're the most valid examples I could find. The key is if the security products will break Chrome or IE or Adobe Reader or whatever from doing their jobs to protect the users' computers.

EDIT: Anyway, this is getting OT. I'll just try to get myself some info about AppGuard so I can decide if it will be redundant when used in conjunction with Chrome's sandbox and just weakens it instead.

 

O I see now. You could ask on the appguard 4 forum here. I don't know the answer. I don't think it does IMO.

 

But I think Pete wants us to get back on topic if you have more questions about it post on the appguard 4 forum. https://www.wilderssecurity.com/showthread.php?t=355206

 

Can an additional security software layer stop kernel exploits of the OS which the security software itself is also using as foundation. Answer is simple no, that is impossible!

Can security software reduce the exploitability of an kernel bug (meaning the bug can be used in a predictable manner): Yes putting extra locks and bolts on the chain/flow of event of the average intrusion and reducing attack surface complicates the predictability of a kernel bug used by malware.

So the answer this statement

To stop kernel exploits: NO
To stop java exploits: YES
To reduce the chance of predictable outcome (exploitability of a kernel bug): Possibly yes, with a downfall. Adding code also adds complexity and increases the chance of two security mechanisms reducing each others effectiveness.

The pen-tester's perspective claim that an out of the box configuration of Dell, BufferZone and Sandboxie indicate that the latter is the case (reducing Chrome's sandbox effectiveness when it comes down to kernel exploits).

No one of us can proof that a well configured' "security program A" is able to stop kernel exploits as well no one can proof with a "real life exploit" that using two sandboxes reduces security. As said earlier: when it feels better to use software A on top of a build-in sandbox, feel free nobody has proven your wrong with real life exploits yet.

But please don't claim that "a properly configured bla bla" can stop kernel exploits: this is simply impossible for any software running on the same OS instance of which the kernel is exploited.

 

This makes me think: securing Windows is really not sensible at all. All we can do is creating barriers on the user space level. But once the core of Windows itself has been compromised by a direct attack, all your plans are failed in an instant. It's like wearing a suite of thick armor while leaving your head exposed.

 

Which is why you have to keep updating the kernel.

In all seriousness though, the situation is IMO not that bad on modern, supported OSes. I was doing some penetration testing on an up to date Windows 7 VM earlier, and damned if I could get any exploits to work at all. Even on the XP VM I posted about, I was mostly relying on exploits in out of date userspace applications. If I'd updated the VM I might not have gotten anywhere.

Updates are not the be all and end all of kernel security. (If you need proof of that, look up the number of exploits found per year in Linux vs. FreeBSD.) But they are really, really important.

 

Remember that, while you can't really do much *yourself* for Windows kernel vulnerabilities, there are people at Microsoft doing a lot of work to make the Windows kernel more secure. That's why it's important to move from a system like XP where *no one* is doing work to make the kernel secure.

 

Good explanation, no security is 100%, but when attacked with arrows I prefer to have an armor suite over adam's costume, I could allways roll in a curl (head down) to minimise the attack surface

In another thread I could 'proof' with a calculation that by allowing only javascript from NL and COM domains, using Chrome's safe browsing and a third pary URL/reputation filter (e.g. Avast or Bitdefender), the chances of getting infected were lower than dying within a year (I am 55) using Dutch mortality tables. Same with driving a car, taking an airplane. Risks are part of our life.

 

This. If your running XP then upgrade to at least 7 which is still being working on and getting security patches.

 

I'm using a Windows XP from the very first day, and I have never ever seen my computer being hijacked by any kernel exploit just for the note.
What I think is that you and WS are making an hyper-over-hype; no offense, but after such great experience with windows xp in my hands there is no way anyone would ever convince me to move towards to windows 7 or 8, exactly because of the above mentioned reasons.
And all that time I've been using SBIE (and many times even without SBIE) and my router firewall tweaked on maximum level plus windows xp firewall tweaked on maximum level, sure I was infected a several times-but that was when I was a rookie, after gaining some experience there is no way anyone could be making a fun of me and my computer.
I even visited websites that are considered dangerous for visiting, and yet nothing happened-if you know what to do and what NOT to do.

I've been using Chrome on windows xp as well-nothing was ever breached-again where are the real-world evidences of the hyper-over-hype statements?
Sorry, there are no evidences in my backyard-I'm a windows xp veteran, so I know exactly what I'm talking about.
Also, most people inside their homes and on their jobs (almost every single one of them) in my country still use windows xp on their jobs and inside their homes-and why should they mitigate to windows 7 or windows 8?

 

But every time new exploit/vulnerability comes out, it can't be configured to block access to that vulnerability, hacker would again have to look for the new loophole in Windows.
And also it has to be mentioned these are POCs, how many of them each year become real in the real-world scenario?
None, a very few...?
Question what url filter uses BitDefender?

 

Actually, I remember several times when something wanted to download on my computer without me even knowing it, since you have to use Public fox with a password it asked me password to download it, since I have never seen what exactly was trying to download itself, I clicked cancel and than the download was blocked-so Public Fox is a very useful extension.

 

What part of the statement is incorrect, exactly?
The one where I mention that with enough tight configuration you can protect yourself from every hole/vulnerability, if you vlock access to all those operation system holes/vulnerabilities?

And those API vulnerabilities; couldn't they just be configured to block access to all API who are vulnerable and where the holes are?

Of all the 3 security software-AppGuard, Sandboxie, DefenseWall, AppGuard seems to be the most effective and the most universal and the strongest of everything I've seen so far.
And this is my answer why I don't consider worth mitigating into windows 7 or 8:
https://www.wilderssecurity.com/showpost.php?p=2304344&postcount=213

 

Than what is the issue between Google Chrome and AppGuard?
And how exactly strong is AppGuard according to your experience and knowledge?
To me it seems to be the strongest and the most effective, the most detailed and the most universal application on the market today.

 

What exactly is AppGuard? If it's what I think (i.e. executable whitelisting) then no, it's not nearly as strong as Sandboxie. Or any properly configured HIPS for that matter.

Edit: N/M, Appguard is a sandbox of some sort. Oh. Must test.

 

I wonder if the reason are their politics?
Bad experience with Google Chrome?

 

But how do you know that's the case, and the key problem is this is all POC-it's merely hypothetical. This is like abstract mathematics which I study. There is barely (less than 1%) in abstract mathematics that can be used in a real world and in experiments.

How it's not possible to enable all of this you mentioned you still need configuration to enable all this with API, and if you can configure to do all this, than you can configure it to block access or to close the hole as well-if you know what to configure.

 

Why so few mention the virtues of scripting control astounds me.

 

Like I said the POC exists only in hypothesis/theory, it is not real, that did not answer my question.