Bug#771056: [hardening-discuss] Bug#771056: ICC stack protection false negative

2014-12-08 Thread Cornea, Alexandru
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 +, 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



Bug#771056: ICC stack protection false negative

2014-11-26 Thread Cornea, Alexandru
Package: hardening-includes
Version: 2.7
X-Debbugs-CC: costel.ma...@intel.com

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.

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'}) ||
 (!$elf  defined($functions-{'__stack_chk_fail_local'}))) {
 good($name, yes)
 }

Regards,
   Alex


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org