Is Google Chrome truly that vulnerable?

Oh mai gawd don't you young people ever take some rest? I can't keep up with the discussion.

I personally won't pay attention much on test comparisons anymore these days, especially if they're done by the product vendors. Remember that they all are for-profit companies, so they'll try their best to sell their products to you.

Rasheed and I defined the word "exploit" differently, thus created argumentations. But now that I know what he really meant, I agree with him. Let's put it this way, a full version of an intrusion is carried from point A to point Z. When it comes to stopping an attack right at point A, there is nothing better than EMET. AG's Memory Guard + some other of its features can stop the intrusion chain at somewhere around point N, although with some hardening tweaks it can go up to around point F. But IMO the essential part is how to prevent it to reach point Z, it doesn't really matter where it's stopped.

Now if you are seeking for 100% protection, you've already failed to begin with.

 

I find most testing to be irrelevant if it doesn't reveal inner workings of the product.

I don't think they would hoot process monitor. They can set callbacks in filter drivers as well as windows kernel event notifications. That'll get you a lot of power right there.

 

Yes correct, I´m talking about stopping the attack at point A. That´s why I never used Sandboxie as my main protection tool, because (with standard configuration) it doesn´t really stop exploits/payloads from running. Of course, it will contain the malware, but I rather have the malware not running at all. About EMET, some exploits are able to bypass it, so that´s why MBAE and HMPA have implemented an extra "anti-exe" layer.

 

To clarify, it was a simple comparison (not a test), SurfRight probably ran its own exploit test tool against EMET and MBAE, so that´s how they managed to figure out what MBAE and EMET protect against. I only posted the test results to show that strangely enough MBAE still performed better, but it´s not really clear if the test was done correctly and fairly. But OK, this thread is not about that test, so let´s leave it at that.

 

I´m not following you, as you can see the comparison tells exactly what techniques are covered by all the products.
And what do you think about my assumption about the use of IAT hooks? I noticed that EMET, MBAE and HMPA all inject code into memory, so that´s why I believe they can´t do the job with drivers alone. Tools like HMPA and Trusteer can even block/alert about banking trojans who are trying to modify IAT/inline hooks.

 

Yeah, I assume they do something similar to IAT hooks but I believe they do it through the compatibility layer in EMET. I don't know the details of other products, I may have a look later.

 

Well, if that is true, then you already have your answer. Now you know which techniques they are using and how they do it.

 

To answer you question I will just explain AG's policy in the different modes of protection since it is policy based. Then you can make your own conclusion. The first question you have to ask yourself is under what circumstance will AG allow a malicious executable to install itself to the user-space. In order for this to occur the malicious file has to be digitally signed with a valid digital certificate, and AG has to be in Medium Mode of protection. Medium Mode of protection will allow signed executables to execute in the user-space, and block any executable that is not singed. The digitally signed executable will be guarded (ran with limited rights). The executable will not be allowed to inject code into other processes, will not be allowed to read/write to the memory of other process, will not be able to write to Windows Directories, will not be allowed to write to Program Files folders, will not be able to read/write to any folder defined as private in AG settings (user can define any folder they like as private), will not be allowed to write to HKLM registry hives, and will not be allowed to write to, select HKCU keys (e.g., Run, RunOnce etc..). Also any .dll belonging to this executable will be guarded. Loading of DLLs is based on digital signature and trusted publisher policy. So for instance if a DLL’s publisher is on the trusted publisher list, it will be allowed to load. The DLL will be Guarded if the process that is loading it is Guarded.

In Locked Down Mode the only applications allowed to launch from the user-space are those on the guarded apps list, and they will be guarded. In Locked Down Mode AG does no even allow applications on the trusted publisher's list. Applications on the Guarded apps list are internet facing Apps such as Browsers, Mail Clients, MSOffice, Adobe reader, Flash Player, Java, Media Players (Windows Media Player, VLC Player), Instant Messengers, etc.. Any application can be added to the guarded apps list if the user has others internet facing apps that are not on the list by default. I added Tixati torrent client, and Jitsi instant messenger to the guarded apps list myself along with a few others. The applications that are on the guarded apps list that are allowed to launch in Locked Down Mode will be guarded with all the following measures mentioned above just like the signed executable that was allowed to run in Medium Mode of protection. The executable will not be allowed to inject code into other processes, will not be allowed to read/write to the memory of other process, will not be able to write to Windows Directories, will not be allowed to write to Program Files folders, will not be able to read/write to any folder defined as private in AG settings (user can define any folder they like as private), will not be allowed to write to HKLM registry hives, and will not be allowed to write to, select HKCU keys (e.g., Run, RunOnce etc..). Also any .dll belonging to this executable will be guarded. Loading of DLLs is based on digital signature and trusted publisher policy. So for instance if a DLL’s publisher is on the trusted publisher list, it will be allowed to load. The DLL will be Guarded if the process that is loading it is Guarded.

I hope this was of some help. You can draw your own conclusion from the policies AG presently uses. In the case of kernel exploit, afaik AG would not block these types of exploits since they are able to bypass the API all together. I don't know if AG uses a KMD (kernel mode driver), or some other method. I don't think AG uses user-mode hooks, but I could be wrong. That would be a good question for me to bring up to BRN. I've been using AG since 2007 if my memory serves me correctly. I don't play video games so maybe it's the gamers that are having the most trouble. I have not experienced any of the problems that some say AG causes here at Wilders. The three people I know of that says AG causes problems, and is poorly designed have admitted to not even trying AG so how can you take any information from them for granite. I don't deny that it can interfere with some applications, but AG allows the user to make exceptions for applications that do not function correctly with the default settings. Sometimes it just takes a little configuring on the user's part. I might add that AppLocker will take a hell of a lot more configuring than AG. All these people are really doing are spreading misinformation, and killing sales for AG. Then users like me stand the chance of loosing a key component in their security setup due to lack of funding to continue development. So many great security product have gone bust due to lack of funding. AG is not for everyone, but those that choose not to use it should not try to damage the reputation of a great product for no good reason. If you don't feel AG meets your needs then just find something that does. Find a security product that does meet your needs that you strongly believe in, and work with the developers like I have over the years to do whatever you can to continually improve that product. The last part of this post was not directed at you in any way. Instead it is directed at those here at Wilder's that have been trying to damage the reputation of AG for no valid reason. I'm sure they will read this post. I have said my peace on this matter, and have to get back to my studies. Have a great day!

 

Thanks @Cutting_Edgetech for this detailed information

 

Actually, I believe that our Chief Software Developer did a nice job of explaining the differences in this post: https://www.wilderssecurity.com/threads/appguard-4-x-32-64-bit.355206/page-78#post-2397777.

 

I'd really appreciate it if you would stop making unfounded statements about AppGuard. You've stated in a previous post that you haven't tried AppGuard so unless you have something to base your opinion on other than speculation, I think that you should refrain from making false statements about our product. We have thousands of customers that run AppGuard and AppGuard does not screw up legitimate operation of the programs that are included in our default policy. In fact we do extensive testing to ensure that AppGuard doesn't interfere with normal operation.

MemoryGuard serves the purpose of containing malware.

 

No it doesn't. An exploit/malware doesn't need to do anything to another process' memory, period.

Therefore, it serves basically no purpose (did you see "near-useless?" So it can't access other program memory. OK fine, that's stopped. I say, "Who cares? Makes no difference.")

And also therefore, any legitimate operation that it screws up, especially by default, is unacceptable. I'm going by the several posts I've seen over the years (here and elsewhere) that explain needing to change MemoryGuard settings. They shouldn't exist for the most part...

 

Perhaps I should have put it differently, but what I meant is: why compare "Memory Guard" with "exploit mitigations" in the first place? They are both trying to achieve two different things. Also, he made it sound like "Memory Guard" is some revolutionary new feature while it´s not. It has been offered by virtually all "advanced HIPS" since 2004.

Like I said earlier in the thread, security tools that claim to protect against drive-by attacks, should stop the malware from running at all. And the thing that stops exploits/malware from running is AG´s "anti-exe" policies, not the "Memory Guard" function. You can do the same with any other white-listing tool.

 

I don´t have enough knowledge about exploits, but I suppose it depends on the payload. If it´s running inside the memory of the attacked process, then AG probably won´t be able to protect you. For example, banking trojans often try to modify browser memory to hijack SSL connections, they don´t have to manipulate other processes.

But let´s say some exploit-kit is trying to install a rootkit who tries to inject code into running processes, then AG should stop the attack in theory. On the other hand, a rootkit will most likely also install a driver, I´m not sure if AG protects against that.

 

Loading drivers is a privileged operation, any HIPS should block that.

I think DR_LaRRY_PEpPeR is saying that access to the compromised program's resources is enough to do a lot of damage. Which is true, especially if it's a browser (since we use browsers for everything).

 

Over the years AppGuard has evolved and I don't believe that you will find recent postings (since AppGuard 4.0 was release last October timeframe) of requiring a change in MemoryGuard settings. And as I stated above, AppGuard does not screw up any legitimate operation of our default Guarded Applications (which consists of the most popular and most targeted software products). Sure AppGuard may interfere with some poorly written obscure program, but then if is obscure and poorly written, then most likely it is not a high-value target for malware writers and wouldn't require Guarding.

 

I believe that the term "revolutionary" on our web site applies to the entire product, AppGuard, and not just the MemoryGuard feature. And I do believe that AppGuard is revolutionary. In fact so much so that when we first started marketing it, there wasn't even a marketing category for it (now considered to be isolation and containment).

Also, AppGuard uses patented technologies (patented by Blue Ridge), so it should be unique protection (unless someone is violating our patents).

 

Somewhat related, the latest version of Chrome fixes a sandbox escape/bypass:

http://googlechromereleases.blogspot.nl/2014/08/stable-channel-update_26.html

 

Finally a post related to this thread in a long time. Don't know if 64 bit version brought any new protections to the table?

 

Finally, on 64-bit, our defense in depth security mitigations such as Partition Alloc are able to far more effectively defend against vulnerabilities that rely on controlling the memory layout of objects. From: http://thenextweb.com/google/2014/08/26/google-chrome-64-bit-arrives-windows-7-windows-8/

EDIT: Also, for anyone who didn't know yet, 64-bit Chrome just went Stable with 37.0.2062.94 unknown-m (64-bit). Keep in mind that 32-bit plugins like QuickTime and so on do not work.

 

I'll hold my tongue on this, I think, except to say that it deserves another discussion (which I will start).

Edit: never mind, I'll just be direct on this...

From what I've seen of how HIPS software works, I would not be surprised if 9/10 of such software was in "violation" of some other vendor's patents. There are only so many ways one can contain attacks on Windows given its design, and only so many MAC models that are theoretically possible to implement on Windows.

 

If you want to call it revolutionary that´s fine with me. And don´t get me wrong, AG can be a very powerful tool if you know how to use it. Yes it´s not for me, but I´m very picky, I´m also not into Comodo, Outpost and so on. But anyway, my response was based on this qoute from AG´s "Chief Software Architect":

This is simply false. Like I said before, almost all HIPS offer this feature. There´s absolutely nothing ground breaking about this type of protection. Also, if exploits are stopped at "point A", you don´t even need features like "Memory Guard" because the malware can´t run anyway. So a standard white-listing tool will probably perform just as good as AG when it comes to stopping exploits.

 

Yes correct, but it depends on how advanced the exploit/payload is. AFAIK, nowadays exploit-kits are trying to infect people mostly with banking trojans and ransomware, I wonder how many of them are able to evade protection offered by HIPS/anti-exploit.

And BTW, in this article it is explained nicely: https://news.saferbytes.it/approfon...ctive-approaches-to-mitigate-exploit-attacks/

Apps with "preventive approach": EMET
Apps with "reactive approach": AppGuard and EXE Radar
Apps with "preventive and reactive approach": MBAE and HMPA

 

Thank you Rasheed187 for the link. It explains the exploit mitigation techniques it very well.

Back to Google Chrome, I am still using it, although not as often. This question might be asked and answered before at Wilders, but if not yet, anyone would explain other than the built-in sandbox, is there other anti-exploit techniques being implemented in Google Chrome?