mailing list archives
RE: NGSEC's response to Idefense overflow protections whitepaper.
From: "Richard Johnson" <rjohnson () iDefense com>
Date: Thu, 12 Aug 2004 12:36:20 -0400
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 --
unsigned char shellcode_1 = "\x83\xEC\x54\xeb\x70\x56\x33\xc0\x64\x8b\x40\x30\x85\xc0\x78\x0c"
-- 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.
Senior Security Engineer
From: contributor [mailto:contributor () idefense 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 called "A
Comparison of Buffer Overflow Prevention Implementations and
Having reviewed this whitepaper we want to say it makes an inappropiated
comparison on the windows protections, especially with our product
StackDefender that implements PAX on WIN32 platforms.
We will try to argument our reasons, so every reader can make their
* 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"
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 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
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 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
Based on our tests: StackDefender prevents the execution of code in STACK,
HEAP, and every user writable memory region.
[Mon Jul 26 17:53:18 2004] ATTACK: Shellcode Execution Attempt from
[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
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