EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption

--WplhKdTI2c8ulnbP
Content-Type: text/plain; charset=windows-1251
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 11, 2004 at 09:16:40AM +1100, Tim Eddy wrote:
> Marc,
>=20
> If we remove the default exemptions for Kerberos & RSVP from IPSEC with
> the "NoDefaultExempt" registry key, this still passes IKE. Therefore is
> IKE vulnerable to the ASN bug?

It would appear that it is indeed. The Internet Key Exchange protocol
is defined in RFC 2409, and section 5.2, "Phase 1 Authentication With
Public Key Encryption", states that "RSA encryption MUST be encoded in
PKCS #1 format". The PKCS #1 standard always uses ASN.1 to encode
the keys and signature schemes used.

G'luck,
Peter

--=20
Peter Pentchev roam@ringlet.net roam@sbnd.net roam@FreeBSD.org
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
If this sentence didn't exist, somebody would have invented it.

--WplhKdTI2c8ulnbP
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)

iD8DBQFAKhkb7Ri2jRYZRVMRAoopAJ0YMxmvS3M9JuuO9V66ry Dd9I/9LwCgnFDo
8yFPvNp3uO/EFl5rM+epCzA=
=0s8d
-----END PGP SIGNATURE-----

--WplhKdTI2c8ulnbP--

On 10.Feb.2004, Marc Maiffret wrote :

> Systems Affected:
> Microsoft Windows NT 4.0 (all versions)
> Microsoft Windows 2000 (SP3 and earlier)
> crosoft Windows XP (all versions)
>
> Software Affected:
> Microsoft Internet Explorer
> Microsoft Outlook
> Microsoft Outlook Express
> Third-party applications that use certificates

At the risk of boring everyone with thoughts of "obsolete" technology, I
note that Win98SE systems with Internet Explorer 6 SP1 and all current fixes
contain the library MSASN1.DLL :

location: {system drive}\WINDOWS\SYSTEM
version: 4.4.3388
size: 51,984 bytes
date: 23rd.October.2000

Since the library is apparently used by IE to process webserver SSL
certificates, can anyone comment on the likely vulnerability of Win98SE
systems to this flaw (as presented by malicious websites with suitably
crafted server certificates) ? As is noted here regularly, there are a lot
of Win98 systems still out there.

The file versions for MSASN1.DLL listed in
http://www.microsoft.com/technet/sec...n/MS04-007.asp are all of
the form 5.m.nnnn.x, so it may be that the Win98 version is so much older
that it doesn't contain the vulnerable code ...

Nick Boyce
EDS, Bristol, UK

sschinke@myrealbox.com (Sam Schinke) wrote in message news:<c0ivbu$j84$1@FreeBSD.csie.NCTU.edu.tw>...

> Yes, a remote, packet-based exploit is about as bad as it gets (unless
> the vulnerability also doesn't require a TCP handshake.

the first exploit for Windows ASN.1 was published on k-otik lol

http://www.k-otik.com/exploits/02.14.MS04-007-dos.c.php

it looks very good ..

On Wed, Feb 11, 2004 at 10:10:32AM +0100, Rainer Gerhards wrote:
>
> 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

That's not actually correct. Most network protocols use the
"Distinguished Encoding Rules" (DER) not the "Basic Encoding Rules"
(BER). BER is an abomination and should never, ever have been in
the standard; the only protocol commonly used over IP that uses BER
is LDAP, because it descends from DAP, which used BER.

So you can't reasonably assume that if it uses ASN.1, it uses
BER. That's presumably why Microsoft left certain ASN.1-using
network services turned on.

Thor

....
> 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 have read a good number of the posts here regarding this vulnerability and
have seen references to NTLM etc. as a pathway for attack. What about SNMP?,
it certainly uses ASN.1. Does MS's SNMP stack not use this DLL? - Must
check.

> 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.
>
> 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?
>
> thanks for more info -- tbird
>

Like the others, SNMP should never pass the perimeter defences, but we are
talking about the same internet that got hit by blaster, SQL-Slammer etc.
I'm still occasionally finding it difficult to get some admins to operate a
'default deny' stance on inbound ports, let alone outbound.

----- Original Message -----
Sent: Wednesday, February 11, 2004 2:04 PM
Subject: RE: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption

> At the risk of boring everyone with thoughts of "obsolete" technology, I
> note that Win98SE systems with Internet Explorer 6 SP1 and all current
fixes
> contain the library MSASN1.DLL :
>
> location: {system drive}\WINDOWS\SYSTEM
> version: 4.4.3388
> size: 51,984 bytes
> date: 23rd.October.2000

I asked my TAM this very question. Microsoft's response was "This is under
investigation by PSS security. If it is affected, per our support policy, a
patch should be issued. More to come..." So if there is a problem then
expect a patch. Remember that the Windows 98 support was extended a few
years so it no longer expired last month. I was rather pleased with
Microsoft that they were actively looking in to this, and that a patch would
come if it was needed.

--
Joshua Levitsky, MCSE, CISSP
System Engineer
Time Inc. Information Technology
[5957 F27C 9C71 E9A7 274A 0447 C9B9 75A4 9B41 D4D1]

> That's not actually correct. Most network protocols use the
> "Distinguished Encoding Rules" (DER) not the "Basic Encoding Rules"
> (BER). BER is an abomination and should never, ever have been in
> the standard; the only protocol commonly used over IP that uses BER
> is LDAP, because it descends from DAP, which used BER.
>
> So you can't reasonably assume that if it uses ASN.1, it uses
> BER. That's presumably why Microsoft left certain ASN.1-using
> network services turned on.

DER is not a transfer encoding syntax. It's purpose is to give the same
sequence of octets for a given abstract value (as does CER - Canonical
Encoding Rules). LDAP, OSI, SNMP etc. all use BER, albeit with
restriction in some cases (e.g. no use of indefinite length encoding).
The cryptographic message syntax (RFC 3369) requires DER for some
elements, but specifically allows BER overall. [OSI can use PER - Packed
Encoding Rules - but that is a whole different ballgame]. DER is used
for signing, not for transfer. I.e. if you get an ASN.1 value in
protocol (whatever transfer syntax) you need to re-encode the value
(paying attention to the ASN.1 type) as DER to generate the hash.

In any case DER is a subset of BER (as is CER). The particular
vulnerability in question arises in the encoding of primitive elements,
where DER and BER are the basically the same (except that with DER you
are required to specify the length field in the minimum amount of space,
which is not the case for BER).

The bottom line is: given a PDU or object encoded in DER, you would use
a BER decoder on it. I'm not sure what the issue is which causes BER to
be an "abomination" while DER is OK.

cheers

--
David Wilson <David.Wilson@isode.com>
Isode Limited

On Fri, Feb 13, 2004 at 01:04:31AM -0500, Thor Lancelot Simon wrote:

> So you can't reasonably assume that if it uses ASN.1, it uses
> BER. That's presumably why Microsoft left certain ASN.1-using
> network services turned on.

perhaps it doesn't emit BER on the sending side, but on the receiving
end, it probably just hands DER off to a generalized BER decoder, given
that DER is a subset of BER. i'm very probably wrong (and i apologize in
advance and ask that you not flame too intensely in rebuttal), but in
OpenSSL, say, it seems that the decoding functions accept either DER or
more generalized BER. this certainly doesn't prove anything, but

$ perl -ne 'print pack "C", hex $_' | openssl asn1parse -inform DER
0x33 # printable string, constructed encoding--this isn't legal DER
0x80 # indefinite length--illegal DER also, for a printable-string, anyway
0x13 # printable string, primitive encoding
0x81 # 1 length byte follows--this isn't legal DER either, i don't think
0x03 # length: 3 bytes
0x66 # 'f'
0x6f # 'o'
0x6f # 'o'
0x13 # printable string, primitive encoding--this is the distinguished form
0x01 # length: 1 byte
0x10 # '\n'
0x00 # eoc
0x00 # indicator
0:d=0 hl=2 l=inf cons: PRINTABLESTRING
2:d=1 hl=3 l= 3 prim: PRINTABLESTRING :foo
8:d=1 hl=2 l= 1 prim: PRINTABLESTRING :
11:d=1 hl=2 l= 0 prim: EOC

which says nothing about how Microsoft does it, but i wouldn't assume
they have separate DER and BER parsing routines

Timothy J.Miller wrote:

> Is anyone else wondering why MS didn't fix this with the last round of
> ASN.1 decoding overflow vulnerabilities (remember the SNMP hole)? It's
> basically the same problem.

Not really. AFAIK, they haven't fixed an equivalent to the xdr_array()
integer overflow in the NSVC run-time library, either. (I was rather
surprised to see an HP-UX advisory on this issue a couple of weeks ago,
though.)

--zOr5JpMIiGv/Oaxu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Feb 11, 2004 at 07:04:31PM -0000, Boyce, Nick wrote:
> version: 4.4.3388
[snip]
> The file versions for MSASN1.DLL listed in
> http://www.microsoft.com/technet/sec...n/MS04-007.asp
> are all of the form 5.m.nnnn.x, so it may be that the Win98
> version is so much older that it doesn't contain the vulnerable
> code ...

If reference implementation is flawed, then "may be" seems not.
And it's reported as such.

If Microsoft were to support "legacy users", they'd put out a
public update for that; else at least considerable part of those
are left with something like zlib-related headache: buried deep
down there and unsupported thus not fixed, but you never know if
someone really needs to get in.

--
---- WBR, Michael Shigorin <mike@altlinux.ru>
------ Linux.Kiev http://www.linux.kiev.ua/

--zOr5JpMIiGv/Oaxu
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFALgLObsPDprYMm3IRAjOQAJ0cjsXQoQUwqWH68E/04KhVJc8QLQCfbp/r
btV93x+eLw3xALSaEnepGbo=
=Qm1U
-----END PGP SIGNATURE-----

--zOr5JpMIiGv/Oaxu--

Hi,

Is anyone else having trouble compiling MS04-007-dos. Everytime i
try, i receive a link error. Does anyone know what the problem is?


-John