📚 OpenRCE is preserved as a read-only archive. Launched at RECon Montreal in 2005. Registration and posting are disabled.








Flag: Tornado! Hurricane!

 Forums >>  Target Specific - General  >>  defeating /GS option in VC++7.1

Topic created on: August 16, 2005 21:51 CDT by dwarkeeper .

Hi,

I have been trying to research how it is possible to defeat the /GS compiler option in vc++ 7.1.

I read the article by Litchfield, however, i also read the article here http://www.developer.com/net/cplus/article.php/3417861. This article seems to be more recent and i was wondering if the claim in this article that stack overflows would technically be impossible to use SEH to write stack overflow exploits.

Could you guys comment on it?

Thanks

  Gerry     August 17, 2005 17:35.52 CDT
Because of the placement on the stack of the exception registration structures in applications compiled in VS 7.1, and the dependency of Litchfield's techniques on controlling the exception handler, both of his techniques will fail.

I have not looked into bypassing the new 'enhanced' protection methods of VS 7.1, but will start looking into it, and I would love to hear of others progress.

--gerry

  alirahbar     August 24, 2005 15:40.53 CDT
Hi

Defeating the cookie protection (/GS) is still possible in some circumstance. As shown by Litchfield when an exception happen the pointer to the exception handler is checked against the address of the stack and every loaded module (by your program) before jumping to it. The point is if the address is out of these ranges (not on the stack and not on any loaded modules) it will jump to it. If a data file is mapped to the memory space of your target like the unicode.nls (in Litchfield paper) and this file contain an instruction like CALL DWORD PTR[ebp+0x30]  (other useful sequences of instructions are on Litchfield paper). By overwriting the pointer to the EH by the address of this sequence (CALL DWORD PTR[ebp+0x30]  ) in the unicode.nls file your EH will pass the test and the program will jump to it. After the CALL DWORD PTR[ebp+0x30]  you will land at the pointer to the next SEH in the exception structure you have modified. So if you replace the pointer to the next SEH by a jmp to the beginning of your shellcode you have successfully bypassed the cookie protection.
I hope you will understand it now. Don

  Gerry     August 24, 2005 16:36.39 CDT
What you are saying is correct for VS 7.0, but not for VS 7.1. The stack layout is diffrent and using a stack overflow it is not possible to gain control of the pointer to the SEH.

  alirahbar     August 25, 2005 03:44.53 CDT
Hi,

I have tested this method with visual studio 2003 (VS 7.1.3088) and it is working perfectly. I will post the article I have written on this subject today. You should overwrite the stack and pass the current stackframe, after this you will find an EXEPTION REGISTRATION structure. This should be modified and you will be able to exploit your stack overflow. Wait until I post my article (with source) and you will see it in your favorite debugger.


Ali Rahbar


  Gerry     August 25, 2005 09:46.58 CDT
I would be very interested to see it, Thanks.

  alirahbar     August 26, 2005 08:10.52 CDT
Hi,

Sorry for my late reply. Here is the link to the paper : http://www.sysdream.com/stack_overflow_win_XP_sp2.pdf
Please tell me if this approach doesn't work for you.

Thanks

Ali Rahbar

  Gerry     August 26, 2005 09:55.02 CDT
I read your paper and the attack is identical to Litchfield's attack. This intrests me because of the article that dwarkeeper mentioned, it says that the SEH frames are now moved below the stack buffers. Now if that WAS the case, this attack would not be possible, but it looks like I have made a big mistake, I belived what I read with out testing. I have to look into this more to see if the SEH frames are actually moved in a newer version.

Has anyone actually SEEN the SEH frames moved?

/gerry

Note: Registration is required to post to the forums.

There are 31,328 total registered users.


Recently Created Topics
[help] Unpacking VMP...
Mar/12
Reverse Engineering ...
Jul/06
let 'IDAPython' impo...
Sep/24
set 'IDAPython' as t...
Sep/24
GuessType return une...
Sep/20
About retrieving the...
Sep/07
How to find specific...
Aug/15
How to get data depe...
Jul/07
Identify RVA data in...
May/06
Question about memor...
Dec/12


Recent Forum Posts
Finding the procedur...
rolEYder
Question about debbu...
rolEYder
Identify RVA data in...
sohlow
let 'IDAPython' impo...
sohlow
How to find specific...
hackgreti
Problem with ollydbg
sh3dow
How can I write olly...
sh3dow
New LoadMAP plugin v...
mefisto...
Intel pin in loaded ...
djnemo
OOP_RE tool available?
Bl4ckm4n


Recent Blog Entries
halsten
Mar/14
Breaking IonCUBE VM

oleavr
Oct/24
Anatomy of a code tracer

hasherezade
Sep/24
IAT Patcher - new tool for ...

oleavr
Aug/27
CryptoShark: code tracer ba...

oleavr
Jun/25
Build a debugger in 5 minutes

More ...


Recent Blog Comments
nieo on:
Mar/22
IAT Patcher - new tool for ...

djnemo on:
Nov/17
Kernel debugger vs user mod...

acel on:
Nov/14
Kernel debugger vs user mod...

pedram on:
Dec/21
frida.github.io: scriptable...

capadleman on:
Jun/19
Using NtCreateThreadEx for ...

More ...


Imagery
SoySauce Blueprint
Jun 6, 2008

[+] expand

View Gallery (11) / Submit