Re: NT/W2K Source leak
From: Dragos Ruiu (dr_at_KYX.NET)
Date: 02/14/04
- Previous message: Carnegie, Martin: "Secure Channel problem"
- In reply to: Russ: "Re: NT/W2K Source leak"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 13 Feb 2004 20:28:42 -0800 To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
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 ----- NTBugtraq Editor's Note: Most viruses these days use spoofed email addresses. As such, using an Anti-Virus product which automatically notifies the perceived sender of a message it believes is infected may well cause more harm than good. Someone who did not actually send you a virus may receive the notification and scramble their support staff to find an infection which never existed in the first place. Suggest such notifications be disabled by whomever is responsible for your AV, or at least that the idea is considered. -----
- Previous message: Carnegie, Martin: "Secure Channel problem"
- In reply to: Russ: "Re: NT/W2K Source leak"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
