lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 11 Feb 2004 10:10:32 +0100
From: "Rainer Gerhards" <rgerhards@...adiscon.com>
To: "Tina Bird" <tbird@...cision-guesswork.com>
Cc: <BUGTRAQ@...urityfocus.com>
Subject: 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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ