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@xxxxxxxxxxxx]
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