Fwd: Re: NT/W2K Source leak

[Dragos Ruiu <dr () kyx net>]

This was sent to ntbugtraq but it might have some usefulness for bugtraq 
readers too.

-- 
Top security experts.  Cutting edge tools, techniques and information.
Vancouver, Canada       April 21-23 2004  http://cansecwest.com
pgpkey http://dragos.com/ kyxpgp
> --- Begin Message ---
>
>
> From: Dragos Ruiu <dr () kyx net>
>
> Date: Fri, 13 Feb 2004 20:28:42 -0800
>
> On February 13, 2004 02:27 pm, Russ wrote:
> > Couple of corrections.
> >
> > 1. There were 27,142 NT 4.0 SP3 files totaling 338MB.
> > 2. There were 28,782 W2K SP1 files totaling 658MB.
>
> odd... the copies I found of the win2k unzip to 30,915 files. Some 
> are 0 length though and there are some files prefixed by . (if the file 
> count was done on unix). The expanded size is correct though.
>
> Also the NT4 zip I have expands to 956Mb and contains 95,188 files
> (241Mb zipped)
>
> > 3. It does appear that all of both versions are present, minus IIS.
> > 4. 10,425 of the 27k NT files are actually source totaling 193MB
> > uncompressed. 5. 8,367 of the 28k W2K files are actually source totaling
> > 217MB uncompressed.
> >
> > Sorry for any confusion. I still contend that the risk is relatively low
> > consider the age of the packages. Both are copies from before the MS
> > security push, and both have had 3 service pack releases since.
>
> Well trying to prioritize, the components that would seem to be risky
> are those that are either network accessible or very widely used and
> unlikely to have changed a huge amount since 2ksp1 that are in the 
> leak.
>
> (IMHO the nt4 folks should think about upgrading even more so now 
> if at all possible as the NT4 sources look rather more substantially
> complete than the 2k stuff.)
>
> As a swag from the file list, the highest risk components in there 
> (the 2k zip) might be:
>
> rpc
> snmp
> software update bits
> command shell
> xml and html core
> winsock2
> the ntos kernel bits
> registry stuff and regedit
> comctl32 
> eventlog 
> pkitrust stuff
>
> And of course the all critical MS-Paint component (just a joke).
> Now I wonder if people who are auditing this stuff will start submitting 
> patches to Microsoft like other open source projects :).
> Some people have also humorously suggested that this leak is
> highly beneficial to Microsoft because it gives their customers another
> incentive to upgrade to newer more robust components. :-)
>
> I know Microsoft has really come about strongly in the last little while
> on security, improving by leaps and bounds, and as well they 
> have been intensively auditing their code as a part ot their secured 
> server initiative (Hi WIndow :-). (Kudos to them, Microsoft has always
> had an amazing capability to turn on a dime and adapt for an 
> organization that large.)
>
> Let me now suggest publicly what I have pointed out privately to
> folks there: The reasonable course of action given this leak is to make
> sure that the leaked components get priority ranking in MS's on going
> source code audits - if they haven't been audited already. Because you 
> _know_ all the armchair exploit writers are now going over these bits 
> with all their favorite static analyzers.
>
> Some analysis should also be done to see if any of the code in the 
> NT4 files have survived on to more modern variants, imho. Those should
> also be added to the audit priority hit-list. 
>
> I haven't done this yet but a rough grep -r for bcopy, strcpy, and printf 
> (poor man's static analyzer :-) over all the files might also be in 
> order to identify in the case of buffer/heap overflows and format 
> strings errors where the potentially riskier bits might lie. There are
> automated analysis techniques for integer overflows (see Halvar's 
> paper last year at CanSecWest), but those are more involved and 
> typically take more skill/effort to identify.
>
> BTW I have heard rumors of trojaned copies of Notepad, and possibly
> apocryphal stories of a notepad exploits resulting from this already.
>
> In any case, panic is certainly not called for, because static analysis 
> works on binaries just as much as source code. Trojans can be created 
> from binaries as well as compiled from source code. The risk of
> vulnerabilities exists in the software with or without the source code 
> leak. It may be mildly easier to spot some errors in C rather than ASM, 
> and this event might mean that a few more eyeballs are pointed at the 
> analysis (in the long run a good thing), but if there are software flaws 
> that are vulnerabilities, they will exist for exploitation with or without 
> the source code available. If anything all this might just be beneficial to 
> improving the software quality, as MS just got a whole bunch of 
> free auditing help with all the furor over this.
>
> The other unexpected benefit of all this is that the furor seems to
> have distracted all the exploit folks who would otherwise have been 
> working on Checkpoint exploits for duke's whopper, and the small
> planet sized hole in ASN that Marc and the folks at Eeye discovered.
> Not that this should justify people to slack in patching those critical
> items....
>
> cheers,
> --dr
>
> -- 
> Top security experts.  Cutting edge tools, techniques and information.
> Vancouver, Canada       April 21-23 2004  http://cansecwest.com
> pgpkey http://dragos.com/ kyxpgp
>
> --- End Message ---