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 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,