OpenRCE: Blog

MS06-022

Wed, 14 Jun 2006 14:30:33 -0500

The MS06-022 .art patch is a pretty good example to use if you want to test the waters in running some binary patch analysis.

The replaced files ( jgpl400.dll & jgdw400.dll ) are both tiny, and you can follow the code flow pretty easily. The guts of the patch is in jgpl400.dll, as the functions with the two versions of jgdw400.dll haven't actually changed.

I've got a comparison of the JgpStartUp code from jgpl400.dll where you can see the calls to JgAStartUp,
JgMDStartUP and sub_65B93190 have been dropped.

As .art is effectively a compression algorithm, I'd expect the flaw to exist as a basic stack overflow, probably occuring through manipulation of an int read from the file used to allocate a buffer into which decompressed data is written. There is also a good deal of conditional _CxxThrowException calls that are now included. It looks like VERY old code, and there's little need for it to remain in use. I could only find two example .art files and very sparse documentation on this AOL format.

Microsoft has seen the passing of .art's time too, if you apply the MS06-021 patch as well, .art support is removed from IE completely.

I've also been looking at Malbolge, the programming language from hell lately. Hopefully there will be an article out of it that delves into Malbolge, and announces some tools.

Reverse Eng in .au & In memory patching

Mon, 12 Jun 2006 02:50:24 -0500

I've been looking recently at the way reverse engineering is treated by Statute Law here in Australia. It's covered within the Copyright Act 1968 (with a few recent amendments) down in Division 4A. You can get links to the text of the Copyright Act 1968 from ComLaw if you're interested, it's fairly readable by non-lawyers.

While a vendor can set out one of those EULAs with the usual "you must not reverse engineer etc" provisions in the contract, the actual treatment of reverse engineering (IDA dumps etc are considered a reproduction in .au) and then adaptation on copyright is pretty interesting.

Amongst other things, it's considered fine to:
- "Reproduce computer programs to make interoperable products" (s. 47D),

- "Reproducing computer programs for security testing" (s. 47F)

- "Reproducing computer programs to correct errors" (s. 47E)

(1) Subject to this Division, the copyright in a literary work that is a computer program is not infringed by the making of a reproduction or adaptation of the work if:



(a) the reproduction or adaptation is made by, or on behalf of, 

the owner or licensee of the copy of the program (the

original copy) used for making the reproduction or

adaptation; and



(b) the reproduction or adaptation is made for the purpose of:

(i) testing in good faith the security of the original copy, or

of a computer system or network of which the original

copy is a part; or

(ii) investigating, or correcting, in good faith a security flaw

in, or the vulnerability to unauthorised access of, the

original copy, or of a computer system or network of

which the original copy is a part; and



(c) the reproduction or adaptation is made only to the extent

reasonably necessary to achieve a purpose referred to in

paragraph (b); and



(d) the information resulting from the making of the

reproduction or adaptation is not readily available to the

owner or licensee from another source when the reproduction

or adaptation is made.

As a 'general' rule you can read the above statements with Reproduction == Reverse Engineered.

The last section governing reproduction to correct errors interests me the most, as it's where I'm planning on doing a bit of digging over the next few weeks. Determina's 3rd party mshtml.dll in memory patch for the createTextRange vulnerability is another source you might like to look to for the work being done in this area.

I haven't looked at the specifics of reverse engineering in other countries, but if you've got some reliable sources, or some experience in the legal side of things PM me and I'll update this with more info.

IE createTextRange() Vulnerability

Fri, 24 Mar 2006 14:48:00 -0600

The .JS flavour of the moment:

<input type="checkbox" id='c'>
<script>
        r=document.getElementById("c");
        a=r.createTextRange();
</script>

Spent some time looking into this bug, which has apparently been going around the traps for a couple of days. It really hit the big time when Stelian Ene reported it to Bugtraq ( http://seclists.org/lists/bugtraq/2006/Mar/0410.html ) and then Andreas Sandblad of Secunia came public that they had independently found the same bug ( http://secunia.com/advisories/18680/ ).

It's a sign of the times that bugs are demonstratably being co-discovered by multiples parties. As Dave Aitel said as early  as Jan 05:

Multiple independent discoveries are more the rule than the exception - Dave Aitel

That is, other researchers who've never looked at the vulnerability before can get stable code execution in under 24 hours. Why assume it's always the "whitehats" who find these and report them? Rumours are the .WMF bug from late 2005 was sold for $4000 to install spyware and popups by one of the unknown original discoverers.

Hrmm, interesting concept, when we also look at the rapidly dropping time between public vulnerability announcement, and  3rd party exploit code.

- Compare SQL Slammer (Bulletin on July 24 2002 and exploit mass released on Jan 25 2003 - ~185 days)
- To Sasser (Bulletin on March 13 2004 and exploit mass released on April 1 2004 - ~17 days)

But sure, this topic has been covered before ( for details see http://www.trendmicro.com/NR/rdonlyres/5D55A679-5B64-485C-8B35-13F6A8026CE3/17118/Vulnerability_Record.pdf ) so where does the latest IE exploit leave us? It's not just exploit code development thats improved rapidly with better documentation, examples and tools such the excellent Metasploit ( [url]www.metasploit.com[/url] ), but the actual vulnerabilities themselves are being found by a wider group of people, in more and more applications. For more info on this http://www.google.com.au/search?hl=en&safe=off&q=code+fuzzers&btnG=Search&meta=

Once your code is running reliably through a exploit, there's also much greater emphasise on IDS evasion and "sliding windows" of attack.

I started looking at software vulnerabilities and code execution when I first saw spyware install itself automatically. Pretty suprising stuff to see. Initially, I thought the Symantec et. al idea of "use antivirus, antispyware, antimalware, antiphishing" products would provide protection. But what the hell, lets get your hands down and dirty, and figure out how remote code execution really works. Read a few BlackHat .pdf presentations by Aleph1, FX, HDMoore, Halvar Flake, Mike Lynn, or anything by any member of the Litchfield family :) . It'll teach you how x86/PPC works on a low-level, and it takes the voodoo mystery out of  much of the malware-crud that's out there.

By the way, it's not just <input type="checkbox"> that causes this memory corruption. :/

It's going to be a big April MS Patch Tuesday.

Maybe another blog article after this is patched might give me a chance to walk through some of the technical details of this vulnerability.