Is Google Chrome truly that vulnerable?

Well, it can't be like not learning things either. If I don't read those papers and ask questions to more knowledgeable people I wouldn't know how vulnerable AVs are. I'm kind of feeling ashamed for defending them (in general) in the past really. But enough with that! I'm not going to start another mad festival!

Perhaps the most fundamental question would be: what are we trying to achieve? What are you trying to achieve, CWS?

 

Actually, AppGuard reminds me more on DefenseWall (yes, policy restriction).
As far as I know your use Chrome, but you have pretty simple security setup as far as I remember.

 

SBie adds attack surface area to Chrome. If you can bypass the Chrome broker and integrity--you can likely bypass Sbie.

If on Win: use EMET and Chrome. Switch off Chrome.exe Caller ROP mitigation.

 

The key reason why I'm asking this are the following: can I use simple security setup on my Windows 8.1 or not?

The other choice I have is to have SBIE4, unsandboxed Chrome, AppGuard, NoVirusthanksexe radar pro plus windows 8.1 firewall inbound/outbound control like Malwar's, hmmm, it's hard to say what to choose.
I wonder if I can use all: SBIE4, unsandboxed Chrome, AppGuard, NoVirusthanksexe radar pro, Windows 8.1 firewall inbound/outbound control like your own, lua+uac (max)?

It's good to know that I do not have to use any other kind of software firewall (Comodo, Private, Outpost, Jetico and etc.), and that WINDOWS 7/8/8.1 FIREWALLS, even without router firewall protection are more than secure enough to protect against internet threats (I mean on closed ports and all other firewall functions).


The bigger problem is my old XP service pack 3, because it's so much vulnerable, I decided I'll use AppGuard and NoVirusthanks exe radar Pro, but I can't use Windows XP firewall with maximum settings, because it's pretty much hollow for attackers.
Google Chrome is not secure on Windows XP (because you need at least Windows Vista and above), so I think I'll go with SBIE4+Firefox.
I think this is ok setup for XP, don't you think?

I wanted to know more about exploits, so I can know what to choose on which system both Windows 8.1 and XP, that's all.
I truly apologize if I created a chaos on this thread.

And no, I was not scared by anyone by any post, I'm experienced enough with computers, that I know what to do and how to do it, I only wanted to take a simple approach and yet retain equal level of security and protection on both of my computer, one with Windows 8.1. and the other one which is old Windows XP Pro Service Pack 3, that's all.
Cheers and thanks.

 

Well, because it is policy restriction. We don't have many of those sadly, especially for 64-bit systems.

Not anymore, I switched to Pale Moon recently (with NoScript to harden it) due to page rendering problems in Chrome. But please remember that I rarely allow active web contents to be loaded and I have very strict policies of what I will install. So what works for me might be not enough for you.

Calculate your attack vectors, then determine your actions based on that calculation. That way you wouldn't end up overloading security tools while still having decent protection.

What chaos?

 

OK, thanks for the answer regarding SBIE/Chrome thing and thanks for advice for security setup, that's all what I wanted to know.

 

Understood, but I have to admit XP is the real problem to me, not sure what to do with it, my parents are using far more than I do, and I do not know what's the best securty approach and yet simple to set it up without annoying questions from firewalls, HIPS and etc.

 

Well, since now we know your main goal is to gain as much security as possible while keeping it as quite as possible, policy restriction (AppGuard or DefenseWall) or sandbox (Sandboxie) seem to be the most rational choice.

 

Perhaps a good solution (because your parents are using it) is to install Shadow defender or Toolwiz time freeze and set it up to Enter Shadow mode on boot. One of my computers is an XP, for me using Sandboxie with the Windows firewall and Firefox with NoScript has been enough but I am not your parents. Check SD and TTF, that type of program can be good for them. Easy to use and work well.

Bo

 

You are welcome anytime!!

 

Yes, especially poorly coded software.

Agreed, except I would add that hardening the OS and browser using their built-in options is recommended as well.

maybe 3rd party software can provide better security, maybe not, but whatever's available from built-in should be utilized as much as possible, even if it's only running as lua/sua, the OS' firewall, service disabling, etc... MS' EMET is designed by Microsoft to work with Microsoft Windows, so that also looks to be a nice option to consider.

 

Well I agree with safeguy's pizza philosophy (lol) he posted somewhere. Buiilt-in security should be the base and additional tools are the toppings. But as an example, IMO SRP is so weak and third party tools might offer stronger applications. No, AppLocker is still not as easily available as SRP. Microsoft just loves to troll the users by only allowing us to create the rules and yet we can't enforce it, while presenting a documentation which appears as if AppLocker is available in 8.1 generally and then there's a small footnote in the far bottom which states "Applicable to 8.1 Enterprise". Seriously WTH, why didn't they say that earlier around the beginning of the article?

 

Which is why I stick with my Win7x64 Ultimate setup. Microsoft has made it virtually impossible for the home user to acquire 8.x with Applocker

 

You still miss my point. When it comes to purely blocking exploits/payloads (from running at all), it´s using "anti-exe". So it´s not relevant that it also has other features.

 

Great posts here for getting some more knowledge on computer security

 

I don't actively follow AG's threads, so can you please tell me which post that verifies this? Kees explained how AG works here:
https://www.wilderssecurity.com/threads/appguard-3-x-32-64-bit.294876/page-97#post-2226367

I know it's old but it should still be relevant for the most part. I have no clue about MBR Guard in the recent versions, but since we are talking about the first line of defence, it shouldn't matter.

 

@ Hungry Man and Gullible Jones

Check out these posts about HMPA.

https://www.wilderssecurity.com/thre...discussion-thread.324841/page-78#post-2393982
https://www.wilderssecurity.com/thre...discussion-thread.324841/page-81#post-2396028
https://www.wilderssecurity.com/thre...discussion-thread.324841/page-83#post-2398152

 

AppGuard should be able to stop the payload from running at all. It can achieve this by simply blocking execution of apps. It´s comparable to EXE Radar, if some app is not on the whitelist, it won´t run. So this means that AppGuard can´t stop or disrupt exploits, but it can stop the payload.

About point #1, I believe Windows_Security is wrong about that, I already explained it to him, the Memory Guard feature can´t stop exploits, it can only stop malware from injecting code into other processes.

 

A general question about Sandboxie v4:

So far I figured out that it runs all processes in "Untrusted mode" and of course it virtualizes access to file system, registry and IPC. But apps running as "Untrusted" will normally not be able to function correctly, so how does SBIE solve this problem?

 

No AG does not do whitelisting. And uh... aren't exploits mostly work by manipulating memory activities of other programs through the holes found in the software? From my limited knowledge, while tools like EMET stops the exploits by disallowing the methods commonly used by exploits, AG's Memory Guard stops exploits by preventing the exploits to be able to alter the operations of the targeted programs. So in the end, the exploits still fail.

 

OMG, not this stuff again.

I know that AG is not like EXE Radar, but at the end of the day they are both using the "Anti-exe" method to stop exploits/payloads. And exploits (not payloads, yes there is a difference) can only be stopped by techniques used by EMET, MBAE and HMPA. Memory Guard is NOTHING like EMET, so there you have your answer.

 

I know dropped-payload executions and first-blood exploit attempts are not the same, thank you very much. What I was saying, is AG's Memory Guard should be able to block exploit attempts. While uses different methods than EMET, AG's Memory Guard can still block those exploit attempts because AFAIK exploits require to alter the processes of attacked programs. It's a "there is more than one way to skin a cat" philosophy.

 

MemoryGuard will stop Firefox from reading/writing to the memory of other processes but it will not stop an attacker from executing code in Firefox's memory, hence it will not stop an attacker from compromising Firefox; it will only stop the attacker from compromising the system through Firefox. Unless the attacker uses his control over Firefox to make system calls and exploit the kernel, then it's game over of course. Nothing "revolutionary" in my opinion.

Let's look at Chrome: AppGuard adds nothing to Chrome as well. Chrome slave processes can't alter the memory of other applications (or can they?) or write to protected system resources. Hell, they can't even write to user-space nor can they read it, same goes for the registry.

 

@ GrafZeppelin

I´m about to give up. You seem to have completely ignored post #121.

I said: "The ONLY way to stop/disrupt exploits is by methods used by EMET". This is a fact by the way. So this automatically means that AG's Memory Guard can´t stop exploits, but it can stop or contain payloads (payload = malware).

EDIT: FleischmannTV has explained it nicely. But it does make me wonder why AG's Memory Guard is misunderstood by so many people, at least it seems this way.

 

Yes, and that is what I've been saying. The system is still not compromised in the end no matter which method one is using.

As I always say, protecting the kernel is futile. There's the limit of what we as the users can do to secure the system, even with EMET.

Sigh...

I'll get some coffee. You guys want some coffee?

I said AG's Memory Guard can prevent the system from being compromised in the end (and Fleischmann confirmed this). EMET does offer stronger protection I admit, it can protect the targeted apps from being compromised since the first place. But since they both can prevent a system compromise through an exploit attempt, I disagree with your statement. You see, the exploit being stopped on different levels. It's a chained event.

EDIT: Lol I see where my mistake is. I previously thought we were talking about exploits as a whole process.

EDIT#2: Dammit I keep write it wrong that it sounded different than what I was intended. >_<