Digest

SecuriTeam Digest

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:

sub
{
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,
ge@beyondsecurity.com.