Is Google Chrome truly that vulnerable?

Peter, please try Comodo firewall: http://help.comodo.com/topic-72-1-451-4760-.html

Edit: I see Winpatrol also support Windows x64

 

Kaspersky Internet Security

 

@Peter2150: my tests of FW/HIPS software on x86-32 showed that pretty much all of it could block memory tampering between processes, if configured to do so. x86-64 should be no different, since the system calls are exactly the same.

This is a bit of a double-bind though, IMO. Blocking memory tampering between processes on x64 should not be patentable, because it is literally the only way to provide adequate protection for programs, and it is no different than on x86 (the system calls are the same, it's still WIndows). This is the kind of thing FOSS geeks are always up in arms about.

On the other hand, this sort of feature is absolutely required for any working mandatory access control framework, which includes HIPS. That's why it's called mandatory access control - processes have mandatory restrictions on what they can do, enforced from kernel space. If an attacker (human or automated) can just jump to a different process that's not restricted, it's not a HIPS, it's a joke.

So if I'm reading this all right... Either other companies have products that work, but are violating Blue Ridge's patents; or they are providing products that are useless for intrusion prevention, and fraudulently lying to their customers.

Edit: I think Microsoft itself could be in violation of such a patent depending on what it covered. Windows integrity levels include blocking memory tampering from a lower integrity process to a higher integrity one.

 

Your belief that you don't need features like memory guard, and policy based AE is simply not true. Your assuming that the exploit will be blocked in the earliest stage of execution. That is a dangerous assumption to make. It's a tedious job to maintain a product that can block all the latest exploits in their earliest stage of execution, and it's not possible. Many exploits are not even discovered until a number of user's have already fallen victim to them. The polices AG enforces which includes memory guard will mitigate almost all exploits since the overwhelming majority of them do use an executable payload. You keep referencing to exploits that only run in the memory, and try to make it look as though MBAE, EMET, and HMPA are much better at mitigating exploits than policy & whitelisting which has not been proven. I think one would need data from verified test results going back at least 2 years to even make a comparison of AE to the products you keep mentioning. If I was someone that did not understand how exploits compromise Windows OS I would think AG, and ERP did not mitigate exploits at all after reading your post. You can't use the argument that AG does not block kernel level exploits to say that MBAE, EMET, and HMPA are better products because they don't block kernel level exploits either. They also run at the user level. Applocker, and McAfee Deep Defender are the only products i'm aware of that can block kernel level exploits. There could be others, but those are the only two that i'm aware of. Why do you keep brings up AG in all the other threads saying MBAE, EMET, and HMPA are better at blocking exploits? You have no facts to prove this. If you are referring to memory only based exploits then clearly state that in your post, and also be honest about the number of them that have actually been used in the wild. I spent about 2 hours looking for documented cases of memory only exploits that have been used in the Wild, and came up with a very small list that has been used over the past 10 years. This will be a senseless debate until professional test have been conducted over a considerable period of time so we have the data we need to make an educated decision.

Edit 8/27 @6:41: The Chief Engineer at BlueRidge Networks just confirmed that AG uses a KMD (Kernel Mode Driver). Barb just posted this info in the AG thread. In my opinion this is the next best method to actually running at the kernel level. I figured some would like to know after reading so much about AG in this thread. I hope that any further discussion about AG will be done in the AG thread. At least BRN will be aware of the post then so they can answer question about AG when needed.

 

People are still believing they can get a working kernel exploit protection all by themselves? Mind blowing!

EMET does not block particular exploits like what AVs do. EMET blocks the common methods used ITW by exploit authors. Sure, it's not invincible and it's not an once-for-all solution. But since EMET blocks the methods (be it for legitimate purpose or not) and not trying to block each exploits exclusively, it is effective. To summarise it, EMET does block the exploit (by the definition of the word "exploit" as: taking advantage of software vulnerabilities) at point A, which means the attack is blocked right when the attacker is attempting the intrusion. This is not an assumption, there are papers we all can read that explain how EMET protects the system.

OTOH, AG's Memory Guard stops the attack chain post EMET's protection scope. It prevents the successful intrusion attempt to finish the whole sequences. It will not and can not block the attack at the same level as EMET (point A). But nonetheless it stops the chain at some degree. Don't tell me you all are ignoring post #160 and the link in it. (well okay, the first half of it =V )

Now for all the innovative HIPS nonsense, you can set your classical HIPS to work like a default-deny policy restriction HIPS. So, despite I really love the concept offered by AG, calling it doing anything new and innovative is simply not true. As others have said, AG also uses the standard techniques used by your traditional classical HIPS (code injection protection, registry protection, you know the drill). What AG does, or more accurately, what policy restriction HIPS does, is predefining configurations of a classical HIPS and lock them up so they can't be re-configured.

Comparing (and similarising) EMET and AG in terms of protection level is not sensible. If one is so undetermined of what decision to make, just use both AG (or Sandboxie, or DefenseWall) and EMET together. They protect the system at different levels, so they shouldn't conflict. AG can serve as a secondary line in case if EMET was bypassed.

And of course, you all are free to correct my statements if you are certain I've made mistakes. I don't currently feel wrong though.

 

This thread seems to have gotten way off track from Google Chrome.


From http://www.chromium.org/Home/chromium-security/guts

There is mention of DEP, ASLR and SEHOP on the Chromium and EMET page here:
http://www.chromium.org/Home/chromium-security/chromium-and-emet



Also a fantastic read: http://seclab.stanford.edu/websec/chromium/chromium-security-architecture.pdf

 

Thanks WildByDesign for this very useful information.
Yeah it does look like Chrome implements quite strong security measures against common exploits.
Now only if we can have a way to mitigate Google Chrome's privacy problems

Edit: I heard of SRWare iron however I remember I tried it before but wasn't impressed somehow.

 

The barebone Chromium? Or perhaps this:
http://www.insanitybit.com/2012/06/02/the-definitive-guide-for-securing-chrome/

Or might as well go full (paid) VPN for your out>in stuff.

 

Thanks for your input. Yes Google Chrome does allow some settings to reduce the privacy exposure.

 

Actually, IMO it´s you that need to think twice. When I say that a statement is false, it doesn´t have to mean that he is lying. Perhaps he simply doesn´t have enough knowledge about the other products? In his defense, he did specifically mention the McAfee HIPS, but I highly doubt they don´t look for code-injection.

And why all this debate? It was simply about wrong/false statements being made by certain members like:

AG can not only block payloads, it can also stop/disrupt exploits ----> False
AG's Memory Guard can achieve the same as EMET ----> False
AG's Memory Guard is unique and is not found in most other HIPS ----> False

 

May I ask what did you exactly test and how? And HIPS monitoring for code-injection have been around since 2004, remember Process Guard, Pro Security, AntiHook? I must admit, I haven´t tested a whole lot of HIPS on Win 8, but Comodo and Kaspersky like others mentioned should offer this feature. And while you´re at it, perhaps you can also test SpyShelter and Zemana?

Also, there is of course a difference between protection against "code injection", and protection against "reading of process memory". The first is used by almost all advanced malware, so I´m mostly worried about that. Does anyone know of malware that can do damage by simply reading memory of another process?

 

You might want to read all of my posts again. I never said that MBAE will perform better than anti-exe tools, I said that in theory it SHOULD perform better against more advanced exploits.

 

Great post. This is the point that I was trying to make, and some people think it´s about bashing AG.

 

@ Peter2150

This is getting childish, tell me if any of my statements that I made are false. Or are you calling me a liar?

Source of my expertise: The internet and 10 years of testing HIPS.

 

To be honest, I would still choose to use an anti-exploit tool to protect Chrome, I would not trust on the sandbox alone, same goes for "Protected Mode" offered by Internet Explorer. But that´s probably because I´m paranoid.

 

The only thing I see is an AppGuard user who cannot differentiate between legitimate questions regarding the functions of a program and baseless critic. This is very disturbing coming from a moderator. I sympathize that Rasheeds attire can be mistaken as trolling but this is only because he keeps asking the same questions and makes the same remarks over and over again. And why? Because in the beginning nobody really answered his questions and when he finally got an answer it confirmed everything he said.

Exactly; and does it offer anything to make Chrome (= topic) more secure? No. The Chrome sandbox alone is already way more robust than AppGuard and it just uses the operating systems security features in combination with its multi-process architecture.

So the relevant security improvements actually came from Microsoft by introducing these features with Vista (and later) and kudos have to go to the Chromium developers for implementing them so neatly. I see nothing "revolutionary" in what most third-party software has to offer and when they say they are, they should be held accountable for their broad claims.

 

I know you will see the quote below at the Sandboxie forum but I ll put it here for people that don't go there.

http://forums.sandboxie.com/phpBB3/viewtopic.php?f=5&p=103163#p103163

Bo

 

Thanks Rasheed187 for your input.
I vaguely remember there was a conflict between the sandbox of chrome 35 and EMET, not sure if they (either chrome people or Microsoft) solved this problem yet in the new versions.. I put Firefox into EMET protection, but not yet do the same to Chrome yet.

 

Thank you Bo, very informative post. I really like posts like this, educational and based on fact.