Vulnerable test application: Simple Web Server (SWS)

every once in a while (last time a few months ago) someone emails one of the mailing lists about searching for an example binary, mostly for:

- reverse engineering for vulnerabilities, as a study tool.
- testing fuzzers

some of these exist, but i asked my employer, beyond security, to release our test application, specific for testing fuzzing (built for the bestorm fuzzer). they agreed to release the http version, following their agreement to release our ani xml specification.

the gui allows you to choose what port your want to run it on, as well as which vulnerabilities should be “active”.

it is called simple web server or sws, and has the following vulnerabilities:

1. off-by-one in content-length (integer overflow/malloc issue)
2. overflow in user-agent
3. overflow in method
4. overflow in uri
5. overflow in host
6. overflow in version
7. overflow in complete packet
8. off by one in receive function (linefeed/carriage return issue)
9. overflow in authorization type
10. overflow in base64 decoded
11. overflow in username of authorization
12. overflow in password of authorization
13. overflow in body
14. cross site scripting

it can be found on beyond security’s website, here:

gadi evron,


ZERT’s latest patch – Science or Art?

I would like to leave the 0day behind for now and just stare! The patch is
just beautiful.

Active patching in memory, no static address… rather generic patching in
memory, searching for several signatures.

Beautiful work from Gil Dabah. Take a look:


ZERT Patches ANI 0day

ZERT patched the ANI 0day April 1st, for more information on the ZERT patch visit ZERT’s web page:

1. Technical information.
2. Why this patch was released when eeye already released a third party patch.

The newly discovered zero-day vulnerability in the parsing of animated cursors is very similar to the one previously discovered by eEye that was patched by Microsoft in MS05-002. Basically an “anih” chunk in an animated cursor RIFF file is read into a stack buffer of a fixed size (36 bytes) but the actual memory copy operation uses the length field provided inside the “anih” chunk—giving an attacker an easy route to overflow the stack and gain control of the execution of the process.

With the MS05-002 patch, Microsoft added a check for the length of the chunk before copying it to the buffer. However, they neglected to audit the rest of the code for any other instances of the vulnerable copy routine. As it turns out, if there are two “anih” chunks in the file, the second chunk will be handled by a separate piece of code which Microsoft did not fix. This is what the authors of the zero-day discovered.

Although eEye has released a third-party patch that will prevent the latest exploit from working, it doesn’t fix the flawed copy routine. It simply requires that any cursors loaded must reside within the Windows directory (typically C:\WINDOWS\ or C:\WINNT\). This approach should successfully mitigate most “drive-by’s,” but might be bypassed by an attacker with access to this directory.

For this reason, ZERT is releasing a patch which addresses the core of the vulnerability, by ensuring that no more than 36 bytes of an “anih” chunk will be copied to the stack buffer, thus eliminating all potential exploit paths while maintaining compatibility with well-formatted animated cursor files.


Solaris telnet vuln solutions digest and network risks

a couple of updates and a summary digest of useful information shared from all around on this vulnerability, for those of us trying to make sense of what it means to our networks:

1. sun released a patch (although it is not a final one). it can be found on their site
( – thanks to casper dik of sun, for those who have been following the discussion).

to quote: “the simplest possible fix on such short notice”:
open solaris source diff

2. if you haven’t already, i strongly recommend checking your network for machines running telnet, and more specifcially, vulnerable to this particular issue.

several folks are speaking of third-party appliances running on solaris, as well as some back-end voip devices that have been confirmed as vulnerable.

apparently, telnet returns a different answer when this vulnerability is used. we are not sure yet, but noam rathaus brought up the option that it looks like the client responds with a “won’t authentication option” to the server’s “do authentication option”. this could perhaps be used to actively detect the “attack”.

3. if this solution is viable for you and you haven’t already, acling 23/tcp at the border or from your user space may not be a bad idea, if it won’t kill anything. at least for now.

4. bleeding edge (ex bleeding snort) released snort signatures for this:
bleeding threats snort signature

chris byrd has submitted an accurate signature for the exploit.
# submitted 2007-02-12 by chris byrd
alert tcp $external_net any -> $home_net 23 (msg:.bleeding-edge exploit
solaris telnet user environment
vuln.; flow:to_server,established; content: .|ff fa 27 00 00 55 53 45 52
01 2d
66|.; rawbytes; classtype:attempted-user; reference:url,; sid:2003411; rev:1;)

4. an analysis of how this vulnerability works can be found here:

and blogs by sun on how this happened and was fixed (thanks to georg oppenberg):

and a fine explanation by casper dik on bugtraq:

a bit of background:

and some on how corporations responded as we saw from our own client base:


whatever my thoughts are on how silly, sad or funny this vulnerability is (quaint really), how they use telnet (?!) and how sun should be smacked on the back of the head for it, i have to honestly admit sun’s response and the level they were open to the community and industry on this without too many pr/legal blocks getting in their way are very encouraging, releasing information on the vulnerability, how it happened and why, a quick beta patch and even discussing openly on mailing lists.
i am in awe. now it is time for others to follow their example.

this one, despite its simplicity and age, is going to be with us for a while.

gadi evron,


More CCC Presentations and Videos

other presentations i enjoyed, which i just noticed online:
pdf george danezis, introducing traffic analysis

wmv georg wicherski, automated botnet detection and mitigation

wmv gadi evron, fuzzing in the corporate world (yes, mine)

wmv ilja van sprundel, unusual bugs

pdf ilja van sprundel, unusual bugs

wmv michael steil, inside vmware

more here [mirror]. all mirrors, etc. can be found here. i hope everything becomes available soon.

gadi evron,


23C3 (CCC) lectures on Google Video

not too many yet…

from those available, i’d especially recommend:

23c3 – lawrence lessig – on free, and the differences between culture and code
23c3 – automated exploit detection in binaries (by luis miras)

gadi evron,


IE5 *was* pre-patched to VML vulnerability

As I was researching for ZERT to patch the VML vulnerability back in september, I found an interesting issue.
All ZERT members tried to get as many as possible VGX.DLL file versions (the affected DLL) from different Windows versions, so eventually I could write a generic binary signature (which will find the vulnerability point and later on patch it).

My signature worked for all DLLs I had, approximately 20 files. It didn’t work on 2 different DLLs for IE 7, which were pre-patched from June already (according to the compilation time, that is we assume the build machine is accurate).
You can read about it at:, a blog post “Zero Daze” written by Joe Stewart, also a member of ZERT.

There was only one DLL from IE5, that my signature didn’t “catch”. Back then, when I was writing the patcher, I didn’t have all DLLs in existence (this is the reason why I made it a generic signature). Some of them I got later, and my generic signature still worked well. Eventually, I realized that this DLL was already pre-patched.

Speaking technically: It had a size test in the beginning of the function. It checked whether the input buffer (fill method) isn’t longer than 0×100 bytes, if so it returned null. So in contrast with IE7 pre-patched DLLs, MS lets the fill method buffer be copied to the destination buffer (on stack), but stopped at 0xfe WCHARs. Same was done for the patched DLLs, which as you can see, is more permissive than that IE5 pre-patch.
Examining the compilation date of that IE5 file (specifically version:5.0.3014.1003) results in timestamp of Nov 30, 1999. Which makes sense, since IE5 came out when Win2000 came out too, take or give.

After all, it is clear that some source code was thrown out from the repository. The reasons behind I can’t tell, but it’s a solid proof that we were secure for a short period 7 years ago!
More than that, can researchers find vulnerabilities by going over on older versions of Windows’ DLLs to track bugs? (ala bindiff) you bet.
So what do you think really happened?

Enjoy the weekend,
Gil Dabah


perl segfault?

shlomi fish discussed on his blog how he discovered a segfault in perl. looks interesting, but we haven’t verified it:

i discovered a segfault in the perl-5.8.x compilation stage. i discovered it by accident: i was refactoring some code, and added a function, and then it segfaulted. after reducing the code to a minimal form that still exhibited the problem, i found it had a syntax error which triggered the segfault.

the following code when run by perl-5.8.x triggers the segfault:

my ($i, $j) = @_;
sub { [ $i->f(); ] };

it doesn’t segfault perl-5.6.2. since it is also no longer exhibited in bleadperl, it was closed as “resolved”. however, i wrote the following on what should still be done:

1. add this as a test-case to the perl 5 test-suite.
2. write a patch for the perl-5.8.x line. (which is still heavily used).
3. investigate the crash, and see if it poses security risks. (other than the obvious dos that is caused by the segfault of evaluating such code.)

gadi evron,


When Ax1024 isn’t enough

Recently, h07 published a vulnerability in Easy File Sharing FTP Server. Apparently a simple buffer overflow in the PASS command. This vulnerability is a nice example where fuzzing won’t cut it.

But the catch in the vulnerability is a comma. Only passwords starting with a comma (0x2c) can be overflowed. Why is this so important?

A fuzzer will usually take a legal FTP session, and will try to overflow interesting sections. The password field is a prime candidate, but the problem is, if you test for a simple overflow you’ll just send many ‘A’ characters or something similar. This is because fuzzers tend to look for the coin under the street-light.

Fuzzers today are sophisticated enough to look for many different types of programmer errors, but will usually look for the poster-child of each. For example, to find a format string, just send many %x. This is not done due to programmer lazyness, this is due to the sheer amount of possibilities to check. FTP is a relatively simple protocol, but with vendor extensions it has dozens of commands. Checking every command for vulnerabilities could take a long time, and with network considirations we’re talking weeks and months of continous bombardment on the target server.



Joanna Rutkowska’s blue pill and Vista RC2

joanna just published a blog entry on this issue, and how her poc doesn’t work on the new vista release.

why, etc.

“it quickly turned out that our exploit doesn’t work anymore! the
reason: vista rc2 now blocks write-access to raw disk sectors for user
mode applications, even if they are executed with elevated administrative


(hat tip to elad efrat)


Tiny PE – Rel0ad3d (304 bytes!)

Another long night, :sigh:

Creativeness is the name of the game,
in the end if you shave another byte or two, it’s not a big deal, (as much fun as it is, don’t get me wrong) you have to come up with better ideas. Sometimes, you are sure that what you got something good, but then you have to push your limits, and come up with something better.

I wish to thank Peter Ferrie, Nicolas Brulez and Jamz Yaneza for encouraging me and providing some information, about that downloader virus which is known to be around 330 bytes…

I haven’t got any sample of it, nor I know the real size, but to be sure my Tiny PE is smaller, my latest version stands at 304 bytes. If you read carefully my first blog post about this Tiny PE, I said that I was playing with Optional Header Size. So this time I cut a big part of it, and managed to crunch my code even more and put the Import Module Descriptor inside the header itself :) Though, now I think I broke compatibility with other versions of Windows…

Who is going to get it to below 300 bytes? hehe.

You can find the latest Tiny PE here: tiny3.exe.

If you like Assembly, or you just happen to remember hex code by heart,
even something easy like: EB 02 13 37 33 C0 40 C3 (LOL – sad but true), then you should subscribe to our new code crunchers mailing list at !

Have a beautiful weekend,
Gil Dabah


Code crunching, crazy asm tricks? – code crunchers mailing list

The Code-Crunchers mailing list has just been established.

Got an asm trick? Got a cool code crunching thingie going? Want to help crunch things further with others?

Just saw the most amazing exploit?

This is the place.

Open to anyone, not directly security related. To subscribe:

Reference, Tiny PE:


Tiny PE – The Frenzy Ends! (or not, now at 304 bytes!)

For an update on how I got it smaller, check:

Hi everyone,

As I promised to get the tiny.exe less than 400 bytes, I sat last night and did it. Now with a new record size of 384 bytes and still supposed to run on all Windows versions. :)

You can find my original blog post with further technical details on this challenge here:

Here’s a snippet of the conversation between me and a good friend.
This is one of the ways to develop new tricks for code crunching:

Arkon: The problem with that URLDownloadToFileA is that it creates another thread,
Arkon: and that thread never terminates for some unknown reason to me.
Arkon: So I HAD to call ExitProcess and finish it, otherwise my process will hang. :(
Arkon: But now what I’m going to do is raising a silent exception :x
Matthew: Just blow away the SEH chain and trigger an INT3.
Arkon: It will eliminate the string “ExitProcess” and the GetProcAddress code for it as well.
Matthew: BAM! :) Instant process death…
Arkon: This is too long.
POP FS:[0]
Arkon: Nah
Matthew: XOR ESP, ESP might also do the trick :-)
Arkon: LOL!!!
Arkon: Wait I’m stupid, push 0 is 2 bytes long.
Arkon: 2 bytes ExitProcess OMFG
Matthew: You’re a maniac

Thanks to my idea and to Matthew Murphy, I got the new .EXE size to merely 384 bytes.
It seems to be 99% usage of all spared room in the file…
If you even dare looking at this .EXE, you are crazier than me,
well – I wrote it, but you will have to understand it. :)
This is only one trick, there are way more undocumented tricks to explore and to learn from!

Check it out here:

Gil Dabah


Code Crunching – Tiny PE (challenge) [update #2: now with 304 bytes!]

[ Update: tiny PE is now at 384 bytes. The follow-up post and one of the techniques used to achieve this can be found here.
Update #2: tiny PE is now at 304 bytes: ]

Or shall I dare saying the Tiniest?

It all began a few days ago, a few friends challenged me to write a smaller PE executable than theirs.

Ground rules

It might sound fairly easy at first, but it’s not, and there is merely one simple goal:
Grab a file from the Internet and execute it.

With the following rules:
1) Only Imports section is allowed for kernel32.dll to get LoadLibraryA and GetProcAddress.
2) All strings must not be viewable (except rule 1), so we xor… :)

After working dozens of hours I came up with something extremely crazy, 411 bytes.

Most of the debuggers will hate this file and it has anti-disassemblers effect. I couldn’t check it on many systems, just my WinXP and it works nicely.

Here’s the hex:

Hex of Tiny PE


ZERT Technical Analysis of the Vulnerability and Patch

zert just released a technical analysis of both the vulnerability and the zert patch. there is also a section explaining what the microsoft patch does.

you can find the paper on the zert web page, or linked directly here.

gadi evron,


Heap Spraying: Exploiting Internet Explorer VML 0-day XP SP2

Credits: Niega

At the first time, I decide the release the article at Oct 10. But there is someone already publish the exploit, so there is no means to still keep it private.

Last article, I had described that my method can’t be used to exploit XP SP2. But things change because Niega give me some information that he could produce some error that different from the old one.

This exception may be expected and handled.
eax=0013be58 ebx=001cc564 ecx=0013be4c edx=00000041 esi=000020d4 edi=00140000
eip=6f9eed1e esp=0013be34 ebp=0013c05c iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Program\Delade filer\Microsoft Shared\VGX\vgx.dll -
6f9eed1e 668917 mov word ptr [edi],dx ds:0023:00140000=6341

IE crashes, but not with the security cookie checking failure. This is the interesting one, may be I can made the code execution from this (the reason why I’m give up to find the way to made the exploit work on XP SP2 because there is others can do it). Niega said that he produce the error by overwrite the stack massively. I reproduce the error by create the attack vector like this: