/GS and _set_security_error_handler() not working as expected on VS7.1

  • Thread starter Thread starter Pieter
  • Start date Start date
P

Pieter

I synthetically create an overrun by copying more data than a buffer can
hold:
int buffer[128];
int i = 0;
for (i = 0; i < sizeof(buffer) / sizeof(buffer[0]) + 1; i ++)
{
buffer = i;
}

In debug builds the /RTC option is enabled and catches the overrun.
In release builds the /GS option is enabled, and instead of a security
warning dialog, I get an access violation.

Ultimately I want to use _set_security_handler() to point to my custom
function,
but if I can not get the security dialog to display, I can not test my code.


Any ideas on why the default _security_handler is not called?


Pieter
 
Hi Pieter,

Thank you for using Microsoft MSDN managed newsgroup.

I am sorry if there is any misunderstanding. As I understand, your concern
is the /GS option does not work as expected in VC.NET 2003. I am not sure
about what is the expected behavior you want. Based on my reserch and
experience, I believe that the following article is useful to you. Please
refer to it carefully.

Compiler Security Checks In Depth
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechar
t/html/vctchcompilersecuritychecksindepth.asp
"...
This paper discusses buffer overruns and the complete picture of the
Microsoft? Visual C++? .NET security checks feature provided by the /GS
compile-time flag.
..."

There are some examples in the above article. Would you please test them
and tell me how to reproduce your problem step by step in these examples?

If I have misunderstood your conern, please feel free to let me know.

Best regards,

Jacob Yang
Microsoft Online Partner Support
Get Secure! ¨C www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
 
I synthetically create an overrun by copying more data than a buffer can
hold:
int buffer[128];
int i = 0;
for (i = 0; i < sizeof(buffer) / sizeof(buffer[0]) + 1; i ++)
{
buffer = i;
}

In debug builds the /RTC option is enabled and catches the overrun.
In release builds the /GS option is enabled, and instead of a security
warning dialog, I get an access violation.

Ultimately I want to use _set_security_handler() to point to my custom
function,
but if I can not get the security dialog to display, I can not test my code.


Any ideas on why the default _security_handler is not called?
Click to expand...


Interesting. I pasted your code into a default AppWizard skeleton
program and indeed, in a release build I do not get the security
warning. At first I figured it was because you were just overrunning
the buffer by a single integer, but changing the "+ 1" to a "* 2" made
no difference.

However, changing the type of your array from "int" to "char" made the
security warning dialog appear right away. I am guessing that the
compiler only inserts the buffer overrun check code when it sees
character arrays allocated on the stack.

By the way, I do the same thing here - when the security handler
function is called I set the priority of the current thread to time
critical (in an attempt to prevent other threads from confusing the
situation further), then use the imagehlp.dll functions to write a stack
dump for the current thread to a text file. Then we tell the user to
send the stack dump to us. I wouldn't take much more work to extend
this code so that it is similar to Microsoft's "do you want to send this
information back to Microsoft automatically?" facility.

Jon
 
However, changing the type of your array from "int" to "char" made the
security warning dialog appear right away. I am guessing that the
compiler only inserts the buffer overrun check code when it sees
character arrays allocated on the stack.
Click to expand...

Following-up to my own post here...the article that Jacob Yang posted a
link to in the dotnet.languages.vc newsgroup confirmed my guess. Here
is a quote from the "Performance" section of that article:

"The most important factor behind keeping the performance impact from
being an issue is that only functions that are vulnerable to attack are
targeted. Currently, the definition of a vulnerable function is one that
allocates a type of string buffer on the stack. A string buffer that is
considered vulnerable allocates more than four bytes of storage and
where each element of the buffer is either one or two bytes. Small
buffers are unlikely to be the target of an attack, and limiting the
number of functions that have security checks limits the code growth."

....so the fact that you were allocating an integer buffer means that
your code wasn't a target for the security feature.

Jacob - if you read this you might want to consider checking how you
reply to posts - for some reason your reply didn't make it to the other
newsgroup that the OP posted to.

Jon
 
Back
Top