[conspire] OT (somewhat) Linux perspective on "Zotob's" target

[Rick Moen]

I'm going to go to Hell for this, I know, but I'm succumbing to the
temptation to post about the latest Windows virus, here -- sort of.  But
this won't be your standard "update your $WHATEVER" MS malware advisory,
I hope:  I have in mind some points within spitting distance of being
topical for a Linux user group.

Here's a summary of the current one-day wonder.  Feel free to compare &
contrast it against mass-news coverage:


Yesterday's worm, called Zotob, is an automated remote exploit against
insufficiently paranoid input routines in a Win2k (& some WinXP) "Plug and
Play" network daemon (in msdss.dll[1]) reachable over TCP port 445 (the
"Microsoft Naked CIFS" port).  This weakness in the daemon's input
validation routines was discovered and disclosed four days before, in 
MS Security Bulletin MS05-039, which was accompanied by a binary patch
to close the hole.

The exploit feeds the msdss.dll network interface aberrant data to cause
a -- yes, you guessed it -- stack-based buffer overflow (failing to check 
the length of the network message[2] before passing it on to some
buffer), found recently by Neel Mehta of ISS[3], which somehow permits the
remote attacker to locally escalate privilege on the vulnerable machine
and then carry out assorted mischief and attacks on additional hosts.


The news stories and "virus advisories" tell people gruesome tales about
the aforementioned mischief, argue over which Win$FOO releases are and
are not vulnerable, and warn to install $WHATEVER without delay,
but what's _invariably missing_ is coverage of such stuff as:

1.  Why the frell are all Win2k-and-later Microsoft machines offering 
    open network access from anywhere at all to a Plug and Play
    "service" (daemon) -- even on Aunt Marge's desktop box?  Who 
    exactly thought that adding network-aware capabilities to Plug 
    and Play was a good idea?  (Note that this isn't the same as 
    Microsoft's equally worrisome but distinct "Universal PnP" 
    architecture.)

2.  Why aren't machine admins/owners made _aware_ that they're
    running such network daemons and exposing them to the entire 
    world as attack targets?  What does each of them do?  How would
    one turn each of them off, or limit one of them to be reachable
    from (say) localhost only, or from just one's local IP subnet?
    What would be the _consequences_ of disabling each of them?
    (I might point out that there's a frightening forest of network
    daemons enabled by default on such boxes, not just this one
    Plug and Play daemon on 445/tcp -- and Windows users are told
    nearly nothing about what, why, and how.)

3.  Given the eyebrow-raising assumption that such a daemon has to be
    left running by default and accessible outside localhost, why
    can't Microsoft manage to make it validate its input correctly?
    I mean, this isn't brain surgery, guys.

4.  And given that such a thing must be running, etc., why is the 
    library allowed such an apparently trivial access to escalate 
    privilege.  Why should it be able to escalate privilege _at all_?
    Haven't the Microsoft guys ever heard of role separation and
    dropping privilege in a process?


Linux relevance:  Please note the difference in coverage and emphasis,
compared to *ix vulnerabilities:  

99% of the news coverage -- even in the allegedly technical press -- of
this "virus" (worm) included basically _none_ of the relevant technical
details about the attack mechanism, and what is being attacked, and what
that is, and why that software is running in the first place... let
alone what would happen if you were to turn that software off, how you
would do so, etc.  And my _finding_ that information was like pulling
teeth.  (I eventually found most of it at SANS.)

If this were a remotely exploitable buffer overflow and privilege
escalation in the *ix world -- say, in NFS's rpc.statd -- there would be
copious information easily findable about all of the above matters.
In fact, there _is_ such information routinely available, when such
things emerge.



[1] The filename suggests that the library probably is primarily
concerned with the Microsoft Directory Synchronization Services, which
are an external interface for Active Directory.  But it's really rather
disturbing and shocking that searching Google on this filename turns up
zero hits.  The file's not provided by the OS itself, but rather
silently installed and activated when you install this-or-that
additional software.

[2] There's something about SMB/NetBIOS "NULL session" information being
used in this exploit.  If curious, see this coverage:
http://www.brown.edu/Facilities/CIS/CIRT/help/netbiosnull.html
http://www.windowsitpro.com/Windows/Article/ArticleID/44413/44413.html

[3] http://xforce.iss.net/xforce/alerts/id/202   Interesting quotation:
"The Plug and Play service is a Windows DCE-RPC service that is designed 
to handle device installation, configuration, and notification of new 
devices. It starts automatically on modern versions of the Windows 
operating system, and runs in default configurations. On Windows 2000, 
this service is reachable via named pipes and a NULL session. It is 
not possible to disable this service without adversely affecting system 
operation.

This Plug and Play service contains a remotely exploitable stack-based 
overflow. It has been proven to be trivially exploitable...."