Catching in-progress memory management exploits?

Let me be clear about this. I don't believe that i ever confirmed that AG cannot stop "stage 1 attacks". I say this because I'm not sure that everyone defines "stage 1 attack" in the same way. I did confirm that AppGuard does not stop malicious code on a web site from somehow corrupting the memory of a running browser that is accessing that website, but generally the next stage of the attack (which actually accomplishes the the mission of the malicious code) will be stopped.

 

Of course it would be best to stop stage 1 attacks, but I don't believe that any tools can claim to be 100% effective in this area. So defense in depth is the way to go. Get one of these tools that claim to be effective against stage 1 attacks, get AppGuard to prevent those that get through the first stage defense and get an AV to eventually (once the virus is discovered and a signature is updated) clean up any dormant viruses that are thwarted by AppGuard but lay dormant somewhere in your user profile directory. For those that don't understand the last line of my answer, AppGuard will block these 0-day viruses from running, but they may end up dormant (i.e. ineffectual) on your PC until the AV company that missed them in the first place catches up and issues an updated signature file).

 

@Gullible Jones

If you carefully profile a program, you can limit it in many ways. But this is often going to be very finely grained - and it can change drastically in between program revisions.

It's not really viable as a protection to say something like "You can't use this much heap" because the entire *point* of dynamic arrays is that you want to not hav eto know how much data you need until after compile time. So when do you enforce this?

You could allocat eall of the memory your program will need ,then you can measure it, and then set an rlimit. OK. But what happens when you deallocate half of that - now an attacker has half of that memory to work with.

Only the ugliest of heap sprays would be affected, I would think.

edit: And @Barb_C makes an interesting point: It would be great to stop all attacks before they start, but you remove layers of abstration when you do that, and therefor you have a harder time doing so.

 

Most staged intrusions with an exploit look like

Scripted content (often javascript) + memory overflow causing code to execute + access to shell code + dropper to user space

There are many opportunities to reduce the likely hood of succesfull attack, starting with not allowing third party scripts in the browser, telling your PDF reader not to execute javascript, letting EMET block VB and JS dll's through ASR in office aps, blocking access to shells (who needs 16 bits or dos commands anyway), only allowing signed PS1 scripts, etc.

 

IF it only protects system area such as Windows or Program Files folder, then it won't block that bypass AR exploit because it drops dlls into %LocalAppData%\Temp\acrord32_sbx folder.

 

That paper is not about stopping memory corruption.
Also I don't know what do you mean by "shellcode injection".
I'm not intimate with AG, but I know it prevents memory read/write from compromised process so it'll block thread injection or process hollowing, but not sure about dll injection as there's a way not to use CreateRemoteThread to inject dlls.

While Win8 surely hardend kernel, GP is not specifically for that purpose. It just prevents most heap-based exploit i.e. heap over-flow, heap spray, and use after free. But as I said, it implemented as half-baked state since it will cause serious performance issue if fully implemented.

Memory guard will prevent some complex exploit from succeed by a kind of splitting rather than containment and any other anti-exe wouldn't. But if a program also prevents dlls or other files, it might prevent some complex exploit through different way from AG, just as an example of Adobe Reader bypass exploit.

 

I agree that 'stage 1 (or 2 or 3 or 0)' is too vague. I think we shouldn't use the word except we only talking about MBAE.
Well, most anti-exploit tool also don't protect memory from corruption.
DEP, ASLR, SEHOP, EAF, anti-ROP techniques are focused on after memory corruption occured.
What Rasheed said, 'Anti-exploit prevents shellcode from runnning' is right, but prevents memory corruption will only be achieved by some kind of memory write protection.
I'm interested in the statement of ex-representative of BlueRidge (see #25 from Windows_Security) as it seems he suggested some kind of memory write protection.
Any info about this?

 

I think GJ focus more on detection than prevention, especially by 3rd party software such as AV, than victim process itself.
I don't know any AV or anti-exploit already implemented such things, but now I'm learning HMPA as erikloman posted interesting explanation in #12.

 

@142395

I think you've misunderstood. AppGuard blocks write access to Windows and Program Files folders and blocks launches of executables and dlls from so called user-space folders, like AppData.

 

Thanks for clarifying!
Then, AG will prevent the AR bypass exploit, and some other complex exploit from even occuring.
Sorry I really did't know how exactly AG works, but okay I'll search more before I speak next about AG.

 

When I say "stage 1", I'm referring to post #16. So you did confirm that, actually, you have now done this twice.

Yes I agree, actually I'm not even sure how much risk is involved when you can not stop the attack in stage 1. Most exploits try to download and execute malware in stage 2, and this will be stopped by AG and other tools with Anti-EXE capabilities. So in theory, AG (and other tools) will probably stop most, if not all current attacks. Tools like HMPA and MBAE have the slight advantage of being able to stop the attacks in an earlier fase, and because they don't lock the whole system down, they can also be used by "novice users", at least in theory.

Yes, AG and Sandboxie have the advantage of stage 3 protection, so even if malware is running, it can't do much, because it's running restricted. I believe a HIPS like SpyShelter also offers this with the "Restricted Token" feature. BTW, shouldn't AG be able to block "calc.exe" from running, if configured correctly?

 

I already told you what I mean with "memory corruption". I'm talking about techniques that are used to block the results from memory corruption, that is exactly what the paper is about, and this type of stuff is used by EMET/MBAE/HMPA. And like I said before, this discussion is not about AG vs others, it's about people misunderstanding what "Memory Guard" is all about.

Memory Guard is a standard HIPS feature that is not used to block malware from running or to disrupt exploits in stage 1. And this is what I mean with "shellcode injection": Code that is used to exploit some vulnerability (buffer overflow). This code is injected into the attacked process, so it's not jumping from one process to another. Memory Guard is not designed to stop this, but some members seemed to believe that it did, for some reason.

Would be nice to know what that Eirik guy meant, perhaps Windows_Security simply misunderstood?

 

One of the key differences between AppGuard and an anti-executable such as NVT ERP is that with AppGuard, the decision to allow or deny execution isn't based on a user-controlled whitelist. AppGuard's anti-execution features apply only to user-space and there is no whitelist. All system-space applications (e.g. calc.exe) are automatically allowed to run, but can be configured to run guarded (restricted) or unguarded, which is different from whitelisting.

 

@ pegr

OK so that's why calc.exe isn't blocked. BTW, how does AG react with the "Hollow Process" test? Memory Guard should be able to stop that.

 

Fair chance I understood Eirik better than you thought to understand Barb's confirmation

I have more problems understanding your definitions, preventing memory corruptions is implying that it would prevent buffer overflows of heap and stack. Did you for instance know that ROP stands for return oriented programming and EMET is talking about mitigation, because it also tries to mitigate post-overflow conditions

Say what, I say you are right either way, so I will ask Microsoft to change the definitions because Rasheed said so, unless you decide otherwise that is

 

I don't think so, the only reason why this ended up being a lengthy discussion is because you did not understand what was meant with "code-injection". And you must have missed post #61, she has confirmed it twice, according to my definition of "stage 1".

I already explained it in post #62 what I meant, and people with your knowledge should be able to easily understand me, so that's why I was a bit surprised that you're so confused. And yes I know all the definitions, the thing is, blocking buffer overflow with software/hardware based solutions is not good enough because of techniques as ROP. But anyway, no need to get all personal, we're not talking world politics, so don't feel bad.

 

When I ran the tests, AppGuard didn't stop the "Hollow Process" test from launching and exploiting calc.exe, even though the HMP Alert test tool was run as a guarded application. This doesn't necessarily imply that AppGuard's ability to protect the system would be compromised in a real situation though, as any process started by a guarded application is also guarded.

I imagine that Blue Ridge Networks will want to take a look at this and perform their own testing to see how much of a risk this poses. We will have to wait and see what they say.

 

That is the problem according to your definition you are always right. It does not seem to sink in that you are mixing up code injection, command injection and dll injection.

Really, I thought that ROP meant overwriting a return address (often) as a result of a buffer overrun (aka buffer overflow). But then I seem to understand it all wrong

 

If that is your def, then basically you're right but then I have to say it's not intuitive and bad def.
Usually "memory corruption" means memory overwrite by e.g. buffer over-flow or use after free. It is completely different from it's result and most memory corruption end up just an app crash.
But malicious attacker contrive to execute malicious code, and it is now that most anti-exploit's techniques comes in. DEP is a kind of containment or anti-exe, it's don't stop memory corruption at all but just stop execution, what different from other anti-exe program is DEP works in memory, not on disk. Nearly same goes for many other anti-exploit technique. However, preventing memory corruption is possible and some OS implementation and compiler option actually do this.

I think 'shellcode injection' is not a common word, and here it is clear why we have to distinguish shellcode from exploit code. A code that is used to exploit vulnerability is not shellcode. Shellcode is a (usually malicious) code that is used as a payload of exploitation and it doesn't exploit the vulnerable software.

And BTW,

It's not correct or at least misleading. As I explained, anti-exploit don't block buffer over-flow but some other implementation actually block this and, ROP is a techniques which is aimed for bypassing DEP. There's still other technique to bypass DEP. One more thing, old classic stack-based buffer over-flow is no more popular (almost died). Also heap-based over-flow seems to be not so popular (but still used) now, and the most popular attack now is use after free.

I think Kees already understand what you mean but he just kidding you because those your defs has problems. I hope both of you stop such game.

 

Not just overwriting a return address. Once attacker gets arbitrary code execution, he reverse-assemble and look for small code snipets which ends in 'ret'(means 'return' in x86-assembly) in library, and combine those snipets to perform malicious action (they "happened to" be there). This is why it is called ROP and yes, ROP 'returns' more than once. Usually those ROP gadget have to include 'pop'(draw the last data from stack) and attacker use this to perform malicious action, by substitute value in stack for register or even by command like mov [ecx], eax; ret (write eax register value to the address set by ecx register then return).

 

1) Correct
2) Promised

EDIT: Microsoft did not accept "Rasheed said so" as a reason to change defs anyway

 

@Hungry Man thanks for the reply, but please note the date of the OP. I knew a lot less back then.

 

Yes, but that's why I refer to them as "memory corruption techniques". I'm not sure why you guys are all of a sudden obsessed with the EXACT definition of things like ROP/shellcode/buffer overflow etc. Let's focus on the big picture.

Shellcode injection can have different meanings. Some people even use this word when related to DLL injection or infecting executable files. Just do a Google search to see what I mean. So I don't think there is a problem with my definitions, it's a problem with you guys putting it in the right context. But OK, let's agree to disagree about this subject. I have a trick question for you, when I open up my desktop, and smash up my RAM modules, is that also called memory corruption? Just kidding.

 

Now you're just being silly, I'm not the one who is mixing up things. The point is that when I'm talking about code injection offered by HIPS you should have already known that I was talking about DLL/Code-injection. This is a standard feature in HIPS since 2004, remember Process Guard?

http://download.cnet.com/ProcessGuard/3000-2239_4-10333974.html

What I meant is that back in the days you had apps who claimed to offer protection against buffer overflow, like Prevx, OSsurance Desktop and Comodo Memory Firewall. I'm not sure what techniques they were using, but I don't think they would be able to defend against attacks were ROP is being used.

 

Well, this is a bit weird, another member claimed that AG did protect against malware using the "process hollowing" method. But if so, it should have stopped the testing tool. Perhaps this technique isn't covered yet by AG's Memory Guard?