Catching in-progress memory management exploits?

That's interesting.
If it is still true, it will block heap over-flow, heap splaying, and use after free attack though I don't know how it defines that boundaries.
Maybe we have to ask Barb about this.

 

Better to ask Barb. Not having read the confirmation of Barb, I find it hard to believe Rasheed since he seems to mix up things as you (Yuki) also pointed out. For instance he is telling that exploit protection is about preventing "to corrupt memory from the attacked process" and not about "stop code injection from one process to another process". While the first is true the goal of currupting the allocated memory in stack or heap is to chance code outside the bounderies of its own allocated process. Changing a return address for instance in memory allocated to another process with a buffer overflown is the same as injecting code in another process memory. That is where I can't follow his logic anymore. But two members tell me Barb has confirmed this, so I guess the only thing left to say is: Rasheed you are right

 

The strange thing is that even after all those months you still don't seem to understand it. It's you who seems to be confused. It's funny that you accuse me of "knowing all the ins and outs by just reading a program's user manual". Where in AG's manual do you see that it protects against exploitation techniques like Heapspray, ROP, Stack Pivot?

Blocking code-injection from one process into another, hasn't got anything to do with blocking exploits/shellcode from running.
The goal for anti-exploit tools is to stop shellcode from running in stage 1. If you can not block shellcode from running, you must block the payload/malware from running in stage 2. If you can not block that either, you need to contain it, to prevent damage and system modification/takeover.

Why would you think so, I haven't read anything that leads me to assume that it would block memory corruption techniques.

 

Al for me left to say is: Rasheed, you are right again

regards Kees

 

To be honest, I'm not sure about interpretation of this:

I don't know what he meant by 'bounderies'(plural!), and I also can't get what the 2nd sentence exactly mean.
However, I felt it might be somewhat similar to Guard Pages in Windows8.
Now I can't find good resource to explain Guard Pages, but e.g. below link, slide 30.
https://media.blackhat.com/bh-us-12...2_Valasek_Windows_8_Heap_Internals_Slides.pdf

[EDIT: Because that link would be too techy, I'll add some to help you understand.
Guard Pages are basically areas where access is denied.
They are put among each heap blocks, and if writing occurs beyond the heap memory, the application will be terminated (but I think even w/out termination, it will at least disrupt the attack. Because basically heap attack is more tricky than stack attack, it still makes sense and will decrease possibility of successful exploit.)
Note heap attacks writes to beyond the area where originally allocated to the application.
Also in use after free attack, it prevents overwriting to released heap.]


I also don't know how AppGuard can implement such function w/out dll, but if correctly applied it can block heap over-flow, heap spray and use after free.

 

Actually, I think the examples that you gave are quite bad and confusing. If you read the quotes, you might start to think that I was actually wrong. You should keep in mind that I'm talking about code injection as is performed on a Windows OS system, mostly by malware, but also by some legit tools. The Wikipedia article is talking about other type of code injections. IMO these articles are more useful:

http://en.wikipedia.org/wiki/Shellcode
http://gamehackingadventures.blogspot.nl/2012/01/10-user-mode-methods-of-code.html

 

Yes the article was indeed a bit too technical. But if I understood correctly, it basically tries to make memory corruption a bit harder. I do not see how AppGuard does the same. Actually, it's very simple, either AppGuard protects against memory corruption techniques (like ROP and Heap-spray) or it doesn't. There's no in-between.

If it somehow DOES manage to do this, then their marketing department is doing quite a bad job, because this is something to show off and brag about. If it does NOT protect against this stuff, then I do not have a clue why some people on this forum keep insisting that it actually does, because no one has ever published info about this.

 

What?
Who said I was talking with you? Who said I was talking about code injection?
I'm replied to Kees in #26 as he posted interesting quote in #25 as a reply from ex-representative of BlueRidge. Didn't you read it?

That quote must be interesting if you know technical details of those memory exploit. It's new info at least for me, and everyone who know those details will easily imagine a kind of advanced memory write protection, regardless if he knows Guard Pages. I don't see why you regard this as the same thing as code injection protection.

It is well possible they dropped this advanced write protection for sake of compatibility, as it can cause problems for apps―though we firstly have to clarify what exactly he meant in that quote.

I never talked about code injection in this thread, it's off topic (see #11 also), I replied you only because you quoted and questioned me.
And I added explanation for Guard Pages with layman's words because it seems you don't know details of those exploits and mitigation techniques (there're much more techniques & implementation than you know. Major compiler have various mitigation options, and either Windows or Linux have many implementations which I suppose most of them haven't been picked up in this forum. I already said same thing in another thread.).

But you ignored it and even say bad & confusing because it's not what you expected? What confusing is you in this case. Frankly, I feel bad about was offended by this.
I now understand why Kees said you mixing things up, confusing payload with malware is not big matter, but in this case confusing memory write with code injection is fatal.

And you can't compare usefulness with those links as they're talking different things.

[EDIT: corrected wrong English]

 

What do you mean by 'memory corruption'? What do you mean by 'a bit harder'?
Guard Pages has nothing to do with stack over-flow. Is heap spraying memory corruption? Do you know how to bypass Guard Pages?
I suppose AppGuard uses kernel driver, and while i don't know Windows' internals, at least read/write memory of every user process or inject thread is no problem, no need for dll (as long as AG has proper privilege). How can you assume AppGuard can't do that?

And the fact is not so simple. There's in-btwn such as just lowering probability of successful exploitation.

 

I found good sources.
http://blogs.technet.com/b/srd/arch...tigation-heap-corruption-vulnerabilities.aspx
https://buildsecurityin.us-cert.gov/articles/knowledge/coding-practices/guard-pages

 

Well you can be pretty convincing, so I might have started thinking you were.

I now understand you meant DLL injection (a regular windows mechanism) when talking about code injection (an exploit technique). I requested an adoption for "code injection" with as reason "Rasheed said so".
- http://en.wikipedia.org/wiki/DLL_injection
- http://en.wikipedia.org/wiki/Code_injection


You may notice that "code injection" explanation now very clearly says it has issues, so Wiki accepts your authority on this matter. Maybe you can help merge those pages. Considering the fact they both contain injection in their title, you were 70% right anyway

 

I haven't read all articles of your links (I don't have such time now), however the above link seems to focus more on those injections such as SQL injection or OS command injection. While everyone who learned security systematically (I'm not the one) must know those, I don't think he know those injection as they don't affect most home user (HTTP header injection affects, but I don't regard it as code injection. If it is, even XSS will be said as code injection).
I also don't like that it defines code injection as if it is based on malicious intent―though I know they focuses on such injection.

I suppose when he(Rasheed) says 'code injection,' he don't distinguish dll injection from thread injection or process hollowing. While most dll injection uses CreateRemoteThread with any of LoadLibrary, yes it is different from rest of them.

 

You need to calm down, and try to read better in the future, because then you will see that post #31 was not directed at you. And talking about "code injection" is not off topic at all, because what I'm trying to explain is that blocking "shellcode" from running, and blocking of "code injection" are two different things. So I'm not the one who is mixing up things.

When I say "memory corruption", I'm talking about the things that anti-exploit tools protect against. What you refer to is protection that is already built into the Windows OS, so not that interesting, because this discussion is about the probability that AG does protect against "memory corruption/buffer overflow" or not. Based on what Windows_Security said, I do not see why you would think that it all of sudden does. Yes the name "Memory Guard" does sound kinda cool, but that doesn't mean that it protects against all kinds of attacks related to memory, like buffer overflow.

Why would you think so, and besides it's not even relevant to this discussion.

 

I tried to edit, but it seems he replied so I post what I wrote as new post, but will prolong reply to him as now I don't have enough time.

[It's originally a edit for #37]
If he knew, he would be more careful about using word 'exploit'. He no more can say "blocking code injection has nothing to do with blocking exploit", but I know when he says exploit, it always means remote code execution exploit (only a part of exploit).

I also hope he realize that there're multiple sub-stages and many paths in so-called stage 1. The statement "The goal for anti-exploit tools is to stop shellcode from running in stage 1." is only generally and partly true.

 

Ahhhhhhhh! Really sorry, I misread #31!!
It's definitely my bad!

 

To avoid confusion: I am right. Like already pointed out, Barb_c has confirmed that AG does not protect against buffer overflow, and memory corruption techniques.

Yes exactly, was that really so hard to figure out? Why would I talk about SQL and other type of injections? And there's nothing wrong with the article, so nothing has to be changed on my behalf, but it's just not what this discussion was about.

 

Let's try to not get caught up in semantics. To me it's most important that the "big picture" is clear.

EDIT: I now understand what you mean, and yes you're right.

 

I have informed them that Rasheed has decided otherwise . . .

 

Actually, you should leave me out of it, and give up a new reason, namely: "Kees was highly confused, so never mind". Just promise to never bring this discussion up again.

 

Well, apart from all aside...(but really thanks for your kindness!)
Please remember this thread is about "Catching in-progress memory management exploits". (of course it is not only toward you, and to be honest I'm not much interested in ongoing discussion)
So actually, even some of anti-exploit techniques can be off topic, as I said about heap-spraying by EMET.

Well, GP is implemented in Win8, so all user of Xp, Vista, or 7 will get benefit if AG implemented such function. And it's not all of sudden, but more likely it is abandoned as it will cause problems...even in GP on Win8, it is implemented as half-baked state to minimize performance issue. So while I'm not sure if my assumption is really correct, I'll be very appreciated if anyone can ask it in AG thread as I haven't used and won't use (at least for a time) AG.

But about memory-guard which we knows, well, it don't stop shellcode running, however because current exploits becoming more and more complicated and also because more and more applications trying to adopt sandbox, it will block some real exploit (not just contain).
What I mean is, current exploit often combine some exploits to penetrate the system so AG's isolation including AE-like feature can prevents such collaboration, and also it is common attacker migrates to another process to after escape sandbox, so in general, AG will disrupt some exploits to succeed. [EDIT: Well, latter case can be said containment.]

[EDIT: BTW, Does AG blocks any new dlls to be loaded? If so, it will prevents the notorious Adobe Reader bypass exploit from occurring. I know SecureAPlus does.]

 

Sorry, that's not based on facts. I shouldn't speak based on feelings.

 

Yes, but this discussion started because of the paper that MrBrian posted, which described techniques to stop "memory corruption". But I now see why Windows_Security was confused, for some reason he seemed to think that AG's Memory Guard was able to stop "shellcode injection", while in reality it's designed to stop "DLL/code injection".

Like I said before, Barb_C already confirmed that AG does not protect against buffer overflow techniques, so no need to think it does. And even if she didn't confirm it, it's highly unlikely that it actually does. BTW, isn't that "Guarded pages" stuff more geared to protecting the Windows OS from kernel exploits?

 

Yes I'm well aware of this, the discussion was never about if AG was effective or not. But most people seem to forget that AG is actually blocking exploits from running at all with the "anti-exe" feature, and not with Memory Guard. With other AE's like EXE Radar and VoodooShield you can achieve the same. Same goes for the "restrictions" feature in Sandboxie.

But blocking the exploit in stage 1 is better, because this way you won't have any malicious shellcode running at all (less chance of HIPS/sandbox being bypassed in stage 2 and 3), and you can also stop advanced "in-memory" payloads who don't drop any files on disk. Early versions of MBAE/ExploitShield got criticized about this limitation (no stage 1 protection), see links.

http://blog.trailofbits.com/2012/10/29/ending-the-love-affair-with-exploitshield/
http://news.saferbytes.it/approfond...ctive-approaches-to-mitigate-exploit-attacks/

 

I've run the HMP Alert test tool with just AppGuard protecting the system and, as expected, MemoryGuard didn't block a single exploit in the test set from running. AppGuard's policy restriction though has a wider scope than anti-exploit software and is very effective at preventing all kinds of threats (not just memory-based exploits) from compromising the system or accessing private data.

I am in agreement with the points you have raised regarding the relationship between anti-exploit software and AppGuard, and the differences between them. As they operate differently, anti-exploit software and AppGuard shouldn't conflict; and should therefore work well together to create a layered security strategy.