Buffer Overflow Protection

[Guest]

[Mii]

Did anyone of comodo notice, that a real world buffer overflow not neccessarily has to call APIs by using the "usual" entry points.

What happens in Windows is, is the Windows API forwards the call from user mode into kernel mode with  small stubs of code that issue an interrupt that transfers into kernel mode. From there, some other code runs in kernel mode, the actual functions body.

So what any exploit can do, is simply use the existing call gates loading some registers (function id), pushing parameters on the stack and issuing an interrupt to actually call the function bypassing commodo's "protection" against buffer overflows at user mode API level.

You guys are funny. I recommend to stick with a solution like Sys-Manage BufferShield or a computer having hardware DEP properly enabled than using such a placebo security. Sorry. Failure!  

PS: I can release some proof of concept if you like...

[jay2007tech]

PS: I can release some proof of concept if you like...

It would help clarify things

can you include if your use proactive mode or not (right click on the icon will let you select the mode)

[Mii]

It would help clarify things

can you include if your use proactive mode or not (right click on the icon will let you select the mode)

Callgates explained:
http://www.geoffchappell.com/viewer.htm?doc=studies/windows/km/cpu/sep.htm

Basically all you need is a little snippet of code to invoke the callgate, as shown in this article for example. I tried it already with your protection enabled.

The following behaviour will be exposed:
-API Call directly failed (because used-mode stub is hooked and redirected into commodo where it gets return address on the stack gets verified).
-Using the callgate machanism (SYSENTER) to directly call the kernel works (you do not even need addresses)
-I did not try the call method to invoke the call gate, which relies on calling into a code area that runs as  kernel in GDT/LDT causing a transition to kernel mode as SYSENTER is easier, portable and supported anyways today on most of the systems

I will upload some code later, in a few hours, if you still like...

[jay2007tech]

I will upload some code later, in a few hours, if you still like...

As a old saying goes "Let's see what you got"


Also maybe a developer can comment on this or you can PM "EricJH" or "Panic", with your P.O.C exploit code  then they can forward it to the right place if you want to keep it private.  If it's good to go and it gets fixed, you could also ASK if you can have your name status next to it in the changelog like some other person did (I think their was "MJ")  Not sure <---I think that was that persons name   Of course, some other people don't want a name to claim either.   

I think the people here will be more than happy on whatever you choose to do or even if you change your mind

[EricJH]

We like something we can click on to put it simple.

Please provide us with a Proof of Concept. Tell us what we would expect to be detected and show us that it doesn't happen. Also provide us with a clear and concise description of how D+ can be bypassed and why that is happening.

Jaytech is referring to wj32 who posted several PoC's here and got his name mentioned in the change logs.

[SS26]

...wj32 who posted several PoC's here...

IIRC wj32 calls his related programs "test tools".

...("POC" is a name I hate as well)...

...sorry for

[Tags:]