RE: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption
> > And that the server is more likely to be attacked is just
> an assumption
> > - in the days of class A vuln sweeps and random worm scans, I don't
> > think that servers are at most risk. In fact, I think the
> unprotected
> > home machines are...
> >
> Yes, but...
>
> In order to trigger the ASN.1 vulnerabilities an attacker has
> to be able
> to get the target machine to invoke its BER decoding capabilities. I
> certainly don't know the details -- maybe someone here does?
> -- but it's
> gotta be a little difficult to send a random network packet to get a
> desktop machine (that is, not a domain controller or an AD server or
> something) and get it to invoke MSASN1.
As of my understanding (I haven't tried to reproduce, just theory here),
ASN.1 is not only used for AD, but also for NTLM authentication. Even if
that is not the case, there are several cases where ASN.1 is used. And
"invoking BER decoding capabilities" (from the MS Advisory) may sound
like something seldomly done... In fact, if you receive ASN.1 on the
wire, you need to decode BER because this is the way you get hold of the
message content. It is the same thing as "decoding the SMTP message" is
a bare necessity for any mail server because it otherwise can not talk
SMTP ;)
As someone else pointed out, there is also a potential large multitude
of third party apps which rely on the Microsoft lib. This alone is a
good indication an update is needed.
But I think the bottom line of all this is if a box is listening to 135,
139 OR 445, it is vulnerable. And workstations by default listen to this
ports.
[A good thing to keep in mind is that for NT4/Win2000 it was just a
registry switch that told the software if it is a server or workstation
os. In essence, almost all services are still the same. AD is an
exception, but there are still an awful lot of server services running
on the workstation - they must, e.g. for peer-to-peer file and printer
sharing...].
>
> I can imagine lots of attacks that require user intervention
> to hit this
> one (like opening a hostile SSL-based web site) -- but can this be
> triggered without user intervention?
I am pretty sure it can.
Rainer