bufferover flow cont. ?
Posted: Sun May 30, 2010 1:20 pm
Ok , I have been reading about the compiler security /GS switch
http://msdn.microsoft.com/library/aa290051.aspx <-(if you are interested this is an excellent description of how it works)
I get how it works it basically uses 4 extra bytes on the stack for a cookie.
If the cookie is changes (i.e overwritten by a buffer overflow ) then the security exception method is called which displays a error message ,....etc and cancels the program before the buffer overflow exploit can occur
But what I am concerned about is what happens if you just overflowed the security exception method with your shellcode?
Then when the cookie is detected corrupt by XOR the jump to the report/security functions would start the execution of the shellcode thus getting around the whole security thing?
The only thing I can thing of to make it completely safe (i.e 100% buffer overflow secure) is to put the security/report handleing functions in a section that is read only , and execute only but not writeable to it if that is possible?
If not then this security checking is only to make it more difficult but not impossible for overflows to be still exploited.
Also with this security /gs thing it also takes up more of the stack and makes your code bigger, and slower in some cases if your not careful about knowing what functions to use it with. (And if you know this then chances are you could just fix the damn code in the first place.)
Also correct me if I am wrong this security checking /gs feature is only good for detecting/stopping stack based overflows.
It can't stop heap or other types of non-stack overflows.
http://msdn.microsoft.com/library/aa290051.aspx <-(if you are interested this is an excellent description of how it works)
I get how it works it basically uses 4 extra bytes on the stack for a cookie.
If the cookie is changes (i.e overwritten by a buffer overflow ) then the security exception method is called which displays a error message ,....etc and cancels the program before the buffer overflow exploit can occur
But what I am concerned about is what happens if you just overflowed the security exception method with your shellcode?
Then when the cookie is detected corrupt by XOR the jump to the report/security functions would start the execution of the shellcode thus getting around the whole security thing?
The only thing I can thing of to make it completely safe (i.e 100% buffer overflow secure) is to put the security/report handleing functions in a section that is read only , and execute only but not writeable to it if that is possible?
If not then this security checking is only to make it more difficult but not impossible for overflows to be still exploited.
Also with this security /gs thing it also takes up more of the stack and makes your code bigger, and slower in some cases if your not careful about knowing what functions to use it with. (And if you know this then chances are you could just fix the damn code in the first place.)
Also correct me if I am wrong this security checking /gs feature is only good for detecting/stopping stack based overflows.
It can't stop heap or other types of non-stack overflows.
. Seriously though, most of the stuff in data and bss sections is of a static size. If you do overflow, you'll trash the contents of another variable - you can't trash anything important such as code or kernel hooks, as they're read-only.