Date: Thu, 12 Aug 2004 12:36:20 -0400
From: "Richard Johnson" <rjohnson@...fense.com>
To: <bugtraq@...urityfocus.com>
Cc: <fjserna@...ec.com>
Subject: RE: NGSEC's response to Idefense overflow protections whitepaper.


Mr. Serna,

We respect your wish to defend the integrity of your product, however, your comments to the list do not reflect our previous conversations nor do they speak to the proper version of the test platform which was released to the public during the conferences. I'll try to address your concerns here as completely as possible. 

As to your claim that the test platform did not place the shellcode in a proper location, we took your comment into consideration prior to the conference and modified the code as follows:

-- snip --

char shellcode[600];

unsigned char shellcode_1[] = "\x83\xEC\x54\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"

[..]

#ifndef LINUX
      memset(shellcode,0,sizeof(shellcode)); 
      strcpy(shellcode, shellcode_1);        
#endif

-- snip --

This effectively placed the shellcode on pages that were writable and executable. The test results did not vary.

Secondly, your claim that Peter Silberman agreed to include your tests in our paper is false. We would not include a vendor designed test in our research regardless, but your comment on this issue was:

"I attach our testbed source code so you can see how we locate the shellcodes in writeable memory region. Please keep it for your own as well as we will keep yours. :)"

You specifically asked us to keep your code for ourselves so it is unclear why this is an issue. It's not surprising that your own test showed positive results for your product. You test one control vector (function ptr overwrite on the stack) with the shellcode stored on the stack and heap. If you look at our test results, we showed that StackDefender 1.10 successfully detected this control vector. 

I hope this has cleared up some of your concerns with our research and that future concerns may be addressed via direct correspondence. We take great efforts to ensure that vendors are treated fairly and given due notice of our research when disclosing to the public and expect the same level of respect when clarifying misunderstandings such as these. 


Richard Johnson 
Senior Security Engineer
iDEFENSE Labs



-----Original Message-----
From: contributor [mailto:contributor@...fense.com] 
Sent: Thursday, August 12, 2004 12:15 PM
To: Richard Johnson
Subject: FW: 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