SecuriTeam Digest

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
( http://sunsolve.sun.com/tpatches – 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,riosec.com/solaris-telnet-0-day; 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,


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: http://www.secureworks.com/researchcenter/weblog.html, 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 0x100 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,