From: lists at www.ngsec.com (lists@...EC)
Subject: NGSEC's response to Idefense overflow protections whitepaper.


Recently Idefense has made public the whitepaper[1] called "A 
Comparison of Buffer Overflow Prevention Implementations and
Weaknesses".

Having reviewed this whitepaper we want to say it makes an inappropiated
comparison on the windows protections, especially with our product
StackDefender[2] that implements PAX on WIN32 platforms. 

We will try to argument our reasons, so every reader can make their  
own opinions:

* Their test-bed code places shellcode on a read-only PAGE as shown here
  in the code.

  --- line 74 --- GLOBAL VAR shellcode at a READ-ONLY section/PAGE.
  unsigned char shellcode[] = "\xeb\x70\x56\x33\xc0\x64\x8b\x40\x30\x85\xc0\x78\x0c"
  "\x8b\x40\x0c\x8b\x70\x1c\xad\x8b\x40\x08\xeb\x09\x8b\x40\x34\x8d\x40\x7c\x8b\x40"
  "\x3c\x5e\xc3\x60\x8b\x6c\x24\x24\x8b\x45\x3c\x8b\x54\x05\x78\x03\xd5\x8b\x4a\x18"
  "\x8b\x5a\x20\x03\xdd\xe3\x34\x49\x8b\x34\x8b\x03\xf5\x33\xff\x33\xc0\xfc\xac\x84"
  [...]
  --- 

  Among other lines they overflow pointers with the address of this shellcode: 
  
  --- line 288 --- The overflowed pointer points to shellcode (READ-ONLY PAGE).
  overflow_buffer[overflow/4-1] = (long)&shellcode;
  ---

  This address points to a read only section/PAGE because it is a pointer to a 
  initialized, at compile time, char array. Executing a shellcode in read-only
  memory is for sure 99% uncommon in wild. Testing this against PAX-like 
  solutions implies some misinformation about what PAX[3] is and how it works.

  
* At our webpage we can read:

  "StackDefender is an IPS (Intrusion Prevention System), for WIN32, that will
   deny shellcodes from executing in User Stack and Writable memory regions. 
   StackDefender uses PAX technology for this purpose."

  Testing if we can overflow a buffer in order to overwrite a pointer pointing 
  to a READONLY region... and then saying StackDefender is not working, is just
  unsuitable.

  It is like testing a firewall by not sending packets to it, and claiming it is
  not blocking any packet.


* We have disclosed sd_tester.c source code[4] as a better testbed for PAX like
  comparisons. Peter Silberman told us he will include these tests in his 
  presentation, finally hi did not. We think it is a good idea full security 
  information.

  Based on our tests: StackDefender prevents the execution of code in STACK,
  HEAP, and every user writable memory region. 

  Sample logs:

  [Mon Jul 26 17:53:18 2004] ATTACK: Shellcode Execution Attempt from 
  "SD_tester.exe" at0x001441C0
  
  Memory Dump:
  [0x001441C0]    0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90
  [0x001441C8]    0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90
  [0x001441D0]    0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90
  [0x001441D8]    0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90
  [0x001441E0]    0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90
  [0x001441E8]    0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90
  [0x001441F0]    0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90
  [0x001441F8]    0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90
  [0x00144200]    0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90  
  [..]


References:

[1] http://www.idefense.com/application/poi/researchreports/display
[2] http://www.ngsec.com/ngproducts/stackdefender/
[3] http://pax.grsecurity.net/
[4] http://www.ngsec.com/downloads/misc/sd_tester.c

Best Regards,

---
NEXT GENERATION SECURITY, S.L. [NGSEC]
C\ O'donnell 46, 3º B
28009 - Madrid, SPAIN
Tel: +34 91 435 56 27
Fax: +34 91 577 84 45

http://www.ngsec.com

Powered by blists - more mailing lists