bugtraq - RE: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption

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: Tue, 10 Feb 2004 22:36:07 +0100
From: "Rainer Gerhards" <rgerhards@...adiscon.com>
To: "Tina Bird" <tbird@...cision-guesswork.com>,
	"Marc Maiffret" <mmaiffret@...e.com>
Cc: "Joe Blatz" <sd_wireless@...oo.com>, <BUGTRAQ@...urityfocus.com>
Subject: RE: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption


I think Microsoft is using wording to keep the typical end user in a
warm and cozy state. Technically, except for AD services, each client
has a full server implementation and as such should be vulnerable. I
assume that many of those DSL-connected, non-firewalled home machines
are easy targets.

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...

Rainer 

> -----Original Message-----
> From: Tina Bird [mailto:tbird@...cision-guesswork.com] 
> Sent: Tuesday, February 10, 2004 9:41 PM
> To: Marc Maiffret
> Cc: Joe Blatz; BUGTRAQ@...urityfocus.com
> Subject: RE: EEYE: Microsoft ASN.1 Library Length Overflow 
> Heap Corruption
> 
> 
> On Tue, 10 Feb 2004, Marc Maiffret wrote:
> 
> > This attack can be performed through various encryption 
> systems such as
> > Kerberos and almost anything using CERTs... I am not sure about
> > Microsofts wording in their advisory.
> 
> Microsoft also states that servers are likelier to be 
> attacked using this
> vulnerability than clients are, because they're likelier to 
> be decoding
> ASN.1 data.  But if the vulnerable code can be accessed via LSASS.exe,
> doesn't that mean all systems are at risk?
> 
> thanks for any info -- tbird
> 
> --
> It doesn't have to be our fault to be our responsibility.
> 
>                                  -- Paul Robertson
> 
> http://www.precision-guesswork.com
> Log Analysis http://www.loganalysis.org
> VPN http://vpn.shmoo.com
> tbird's Security Alerts http://securecomputing.stanford.edu/alert.html
>