X-Debbugs-CC: kevin.b.sm...@intel.com Hello Kees, I am not part of the ICC team, I just observed the reported behavior. However, I got in touch with Kevin (CC'ed) from the ICC team, and he informed me that it uses a GCC style stack protection, so there should not be concerns of a weak stack protector scheme. Regarding the stack canary, it is obtained by xor'ing with the esp register value.
Here is the transcript of Kevin's reply: """ using the option --fstack-protector or --fstack-protector-all will use a gcc style stack protection mechanism, and calls to __stack_chk_fail will be generated (and executed) if the check fails. Using the option --fstack-security-check will generate code that uses __intel_security_cookie, and which will xor that value with the current %esp to produce the stack canary value. The routine __intel_security_check_cookie will be called to check the security cookie on the stack. __intel_security_cookie variable and __intel_security_check_cookie are defined in the libirc.a that is shipped with the Intel compiler. """ If you need additional information, I hope Kevin can helps us with it. Regards, Alex -----Original Message----- From: Kees Cook [mailto:k...@debian.org] Sent: Wednesday, November 26, 2014 6:05 PM To: Cornea, Alexandru; 771...@bugs.debian.org Cc: Maxim, Costel Subject: Re: [hardening-discuss] Bug#771056: ICC stack protection false negative Tags: moreinfo Hi, On Wed, Nov 26, 2014 at 11:30:42AM +0000, Cornea, Alexandru wrote: > The script hardening-check can give a false negative result if the binary > analyzed was compiled with ICC (with stack protection). > Hardening-check looks for __stack_chk_fail, but in ICC compiled binaries the > correct functions to be searched for should be __intel_security_cookie or > __intel_security_check_cookie. Thanks for the report! Can you point me to documentation on ICC's stack protection implementation? If the ICC-compiled binaries are using something other than __stack_chk_fail, then they may not be using glibc's canary, which I would view as a regression. (As in, I would like to be convinced that this is actually a false negative -- this may be reporting a weak stack protector scheme instead.) > Below is a naive patch: > > diff --git a/usr/bin/hardening-check b/hardening-check-intel index > 799943c..f40eda7 100755 > --- a/usr/bin/hardening-check > +++ b/hardening-check-intel > @@ -302,6 +302,7 @@ foreach my $file (@ARGV) { > # Stack-protected > $name = " Stack protected"; > if (defined($functions->{'__stack_chk_fail'}) || > + defined($functions->{'__intel_security_cookie'}) || You mentioned __intel_security_check_cookie as well. I assume this is the canary? How is it chosen, what is its value? > (!$elf && defined($functions->{'__stack_chk_fail_local'}))) { > good($name, "yes") > } > > Regards, > Alex Thanks! -Kees -- Kees Cook @debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
