EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption

[Marc Maiffret]

Microsoft ASN.1 Library Length Overflow Heap Corruption

Release Date:
February 10, 2004

Date Reported:
July 25, 2003

Severity:
High (Remote Code Execution)

Systems Affected:
Microsoft Windows NT 4.0 (all versions)
Microsoft Windows 2000 (SP3 and earlier)
Microsoft Windows XP (all versions)

Software Affected:
Microsoft Internet Explorer
Microsoft Outlook
Microsoft Outlook Express
Third-party applications that use certificates

Services Affected:
Kerberos (UDP/88)
Microsoft IIS using SSL
NTLMv2 authentication (TCP/135, 139, 445)

Preamble:

We wanted to do another Night Before Xmas but the vendor missed the last
few release dates, so we had to resort to our MC(SE).

U Can't Trust This
By: MCSE Hammer

Blaster did ya some harm
We just say, hey, another worm
But thank you, for trusting me
To mind your site's security
It's all good, when your server's downed
Our dope PR will pass blame around
Cuz it's known as such
That this is some software, you can't trust

I told ya Homeland
U can't trust this
Yeah that's why we're giving ya the code
U can't trust this
Check out eEye, man
U can't trust this
Yo let 'em bust more funky system
U can't trust this

Give 'em a string or recvfrom
Like no sweat they got the keys to your kingdom
Now ya know
You talk about eEye, you're talking about holes
Remote and tight
Coders still sweating so someone better write
A book to learn
What it's gonna take in '04
To earn some trust
Legit, either secure or ya might as well quit

That's the word because you know
U can't trust this
U can't trust this

Breakin' in

Stop -- eEye time

Description:
eEye Digital Security has discovered a critical vulnerability in
Microsoft's ASN.1 library (MSASN1.DLL) that would allow an attacker to
overwrite heap memory on a susceptible machine and cause the execution
of arbitrary code. Because this library is widely used by Windows
security subsystems, the vulnerability is exposed through an array of
avenues, including Kerberos, NTLMv2 authentication, and applications
that make use of certificates (SSL, digitally-signed e-mail, signed
ActiveX controls, etc.).

Technical Description:
The MSASN1 library is fraught with integer overflows. In this advisory,
we'll describe a pair of arithmetic errors in a generic and low-level
part of ASN.1 BER decoding that allow a very large swath of heap memory
to be overwritten. This vulnerability affects basically any client of
MSASN1.DLL, the most interesting of which are LSASS.EXE and CRYPT32.DLL
(and therefore any application that uses CRYPT32.DLL).

Although the specifics of ASN.1 BER encoding are beyond the scope of
this advisory, the basic idea is that it's an encoding scheme for
flexibly representing binary data, and is often compared to "binary
XML." Each piece of data is encoded as a typed value, which is
constructed as a tag number that describes how to interpret the
following value data, then the length of the data, and finally, the data
itself. This length field is the subject of our advisory. By supplying
a very large value (from 0xFFFFFFFD to 0xFFFFFFFF) in this field, we can
cause an integer overflow in a heap allocation routine, and although
there are checks in place to ensure the validity of a value's length, a
separate pointer arithmetic overflow in the verification routine gives
rise to the vulnerability. Here's how:

1. When a simple value (a value that consists of atomic data, rather
than more values) is decoded by MSASN1, ASN1BERDecLength() is called to
retrieve the length of the value, then passes the reported length to the
ASN1BERDecCheck() function to make sure that that much data actually
exists.

2. ASN1BERDecCheck() verifies that (pointer_to_start_of_data +
reported_length_of_data), unsigned, is less than or equal to
(pointer_to_start_of_BER_block + total_size_of_BER_block). If not, the
function returns failure, which propagates back up the call stack and
causes decoding to stop. (As an aside, it's interesting to note that
this vulnerability was silently fixed in Windows 2000 SP4 and Windows
Server 2003, due to an additional comparison being included in
ASN1BERDecCheck().)

3. If the function that called ASN1BERDecLength() then attempts to
allocate memory and make a copy of the data (e.g.,
ASN1BERDecOctetString(), but not the ASN1BERDecOctetString2() variant),
it will then pass the decoded length to DecMemAlloc(), which rounds the
length up to a DWORD multiple and then attempts to allocate the result.
The operation of this function can be represented as
"LocalAlloc(LMEM_ZEROINIT, (length + 3) & ~3)."

4. If DecMemAlloc() succeeds, the calling function then memcpy()'s the
value data into the allocated heap buffer, using the original decoded
length of the value as the byte count.

If a very large length is decoded by ASN1BERDecLength() in step 1, then
there will be an integer overflow when ASN1BERDecCheck() adds the length
to the current data pointer in step 2, essentially causing the resulting
pointer to "wrap around" the 32-bit address space and therefore have an
address that is numerically less than the pointer to the end of the
buffer.

Now, to be more specific, if a length in the range 0xFFFFFFFD through
0xFFFFFFFF is given, it will pass through ASN1BERDecCheck() with no
problem, and then something really bad happens. Because of the
round-off in DecMemAlloc(), the three lengths in this range will all
round "up" to zero. LocalAlloc() successfully allocates a zero-length
heap block whose address gets returned to the caller, but then the
original, very large length is handed to memcpy(). The result is a
classic, complete heap overwrite, where all contiguous heap memory
following the zero-length block is wiped out by arbitrary data.

The simplest way to manifest this condition is to encode a simple octet
string (tag 04h) with a length-of-length set to 4 and a length of
0xFFFFFFFF, which corresponds to the bytes 04h/84h/FFh/FFh/FFh/FFh.
Depending on which decoder functions the MSASN1 client uses, it is also
possible to leverage this vulnerability through OIDs and character
strings as well. The following is a sampling of vulnerable decoder
functions:

ASN1BerDecCharString
ASN1BERDecChar16String
ASN1BERDecChar32String
ASN1BERDecEoid
ASN1BERDecGeneralizedTime
ASN1BERDecMultibyteString
ASN1BERDecOctetString
ASN1BERDecOpenType
ASN1BERDecSXVal
ASN1BERDecUTCTime
ASN1BERDecUTF8String
ASN1BERDecZeroCharString
ASN1BERDecZeroChar16String
ASN1BERDecZeroChar32String
ASN1BERDecZeroMultibyteString

Note: Due to the technical nature of the vulnerability described above,
this advisory may contain disassembly and/or hexadecimal byte codes.
This information is in no way related to "exploit code", "payloads", or
"shell code".

Protection:
Retina Network Security Scanner has been updated to identify this
vulnerability:
http://www.eeye.com/html/Products/Retina/index.html

Vendor Status:
Microsoft has released a patch for this vulnerability. The patch is
available at:
http://www.microsoft.com/technet/security/bulletin/MS04-007.asp

Credit:
Discovery: Derek Soeder
Additional Research: Yuji Ukai

Very Special Thanks:
Yuji Ukai, again, for the majority of "The Menu"
Steve Peters and Shawn O'Donnell for extreme ASN.1 (BER!) and
certificate lore

Greetings:
DDDDDD; GM-TX, BMNN-FL, JKP-FL, NV-TX; Heather & Heather; all the coffee
shop folks; 214; and always, every last one of the eEye crew

Copyright (c) 1998-2004 eEye Digital Security
Permission is hereby granted for the redistribution of this alert
electronically. It is not to be edited in any way without express
consent of eEye. If you wish to reprint the whole or any part of this
alert in any other medium excluding electronic medium, please e-mail
alert@eEye.com for permission.

Disclaimer
The information within this paper may change without notice. Use of this
information constitutes acceptance for use in an AS IS condition. There
are NO warranties with regard to this information. In no event shall the
author be liable for any damages whatsoever arising out of or in
connection with the use or spread of this information. Any use of this
information is at the user's own risk.

Feedback
Please send suggestions, updates, and comments to:

eEye Digital Security
http://www.eEye.com
info@eEye.com

[Joe Blatz]

In the security bulletin published by MS it states,
"In the most likely exploitable scenario, an attacker
would have to have direct access to the user's
network."

The bulletin published by eEye states "...applications
that make use of certificates (SSL, digitally-signed
e-mail, signed ActiveX controls, etc.) [are
affected]".

I see a big disconnect there. Can you address this?
Also, how would this potentially affect sites that are
using an MS VPN solution?


> -----Original Message-----
> From: Marc Maiffret [mailto:mmaiffret@eeye.com]
> Sent: Tuesday, February 10, 2004 10:20 AM
> To: BUGTRAQ@securityfocus.com
> Subject: EEYE: Microsoft ASN.1 Library Length
> Overflow Heap Corruption
>
> Microsoft ASN.1 Library Length Overflow Heap
> Corruption
>
> Release Date:
> February 10, 2004
>
> Date Reported:
> July 25, 2003
>
> Severity:
> High (Remote Code Execution)
>
> Systems Affected:
> Microsoft Windows NT 4.0 (all versions)
> Microsoft Windows 2000 (SP3 and earlier)
> Microsoft Windows XP (all versions)
>
> Software Affected:
> Microsoft Internet Explorer
> Microsoft Outlook
> Microsoft Outlook Express
> Third-party applications that use certificates
>
> Services Affected:
> Kerberos (UDP/88)
> Microsoft IIS using SSL
> NTLMv2 authentication (TCP/135, 139, 445)

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

[Marc Maiffret]

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.

Signed,
Marc Maiffret
Chief Hacking Officer
eEye Digital Security
T.949.349.9062
F.949.349.9538
http://eEye.com/Retina - Network Security Scanner
http://eEye.com/Iris - Network Traffic Analyzer
http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities=20

Important Notice: This email is confidential, may be legally privileged,
and is for the intended recipient only. Access, disclosure, copying,
distribution, or reliance on any of it by anyone else is prohibited and
may be a criminal offense. Please delete if obtained in error and email
confirmation to the sender.=20

| -----Original Message-----
| From: Joe Blatz [mailto:sd_wireless@yahoo.com]=20
| Sent: Tuesday, February 10, 2004 11:36 AM
| To: Marc Maiffret; BUGTRAQ@securityfocus.com
| Subject: RE: EEYE: Microsoft ASN.1 Library Length Overflow=20
| Heap Corruption
|=20
| In the security bulletin published by MS it states, "In the=20
| most likely exploitable scenario, an attacker would have to=20
| have direct access to the user's network."
|=20
| The bulletin published by eEye states "...applications that=20
| make use of certificates (SSL, digitally-signed e-mail,=20
| signed ActiveX controls, etc.) [are affected]".
|=20
| I see a big disconnect there. Can you address this?
| Also, how would this potentially affect sites that are using=20
| an MS VPN solution?
|=20
|=20
| > -----Original Message-----
| > From: Marc Maiffret [mailto:mmaiffret@eeye.com]
| > Sent: Tuesday, February 10, 2004 10:20 AM
| > To: BUGTRAQ@securityfocus.com
| > Subject: EEYE: Microsoft ASN.1 Library Length Overflow Heap=20
| Corruption
| >=20
| > Microsoft ASN.1 Library Length Overflow Heap Corruption
| >=20
| > Release Date:
| > February 10, 2004
| >=20
| > Date Reported:
| > July 25, 2003
| >=20
| > Severity:
| > High (Remote Code Execution)
| >=20
| > Systems Affected:
| > Microsoft Windows NT 4.0 (all versions) Microsoft Windows 2000 (SP3=20
| > and earlier) Microsoft Windows XP (all versions)
| >=20
| > Software Affected:
| > Microsoft Internet Explorer
| > Microsoft Outlook
| > Microsoft Outlook Express
| > Third-party applications that use certificates
| >=20
| > Services Affected:
| > Kerberos (UDP/88)
| > Microsoft IIS using SSL
| > NTLMv2 authentication (TCP/135, 139, 445)
|=20
| __________________________________
| Do you Yahoo!?
| Yahoo! Finance: Get your refund fast by filing online.
| http://taxes.yahoo.com/filing.html
|=20

[Rainer Gerhards]

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=20

> -----Original Message-----
> From: Tina Bird [mailto:tbird@precision-guesswork.com]=20
> Sent: Tuesday, February 10, 2004 9:41 PM
> To: Marc Maiffret
> Cc: Joe Blatz; BUGTRAQ@securityfocus.com
> Subject: RE: EEYE: Microsoft ASN.1 Library Length Overflow=20
> Heap Corruption
>=20
>=20
> On Tue, 10 Feb 2004, Marc Maiffret wrote:
>=20
> > This attack can be performed through various encryption=20
> systems such as
> > Kerberos and almost anything using CERTs... I am not sure about
> > Microsofts wording in their advisory.
>=20
> Microsoft also states that servers are likelier to be=20
> attacked using this
> vulnerability than clients are, because they're likelier to=20
> 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?
>=20
> thanks for any info -- tbird
>=20
> --
> It doesn't have to be our fault to be our responsibility.
>=20
> -- Paul Robertson
>=20
> 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
>=20

[Tina Bird]

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

[Marc Maiffret]

Yes, I am not sure what Microsoft did with the wording there that seems
to be misleading to at least a few people so far.

There is just as much, if not more, chance of people using this
vulnerability on server side applications as there is on client-side
applications.

For example we setup a totally IPSEC secured network and we broke into
that network via our ASN bug which is called by the Kerberos. We also
have written exploits that take advantage of ASN via NTLMv2
authentication. And the list goes on... How about evil ASN SSL CERTs?
Client or server? There is a menu a mile long for the avenues of attacks
that this thing can be used for.

If your running, Windows NT 4.0, Windows 2000, Windows XP, or Windows
2003, you are 99.9999% positive to be vulnerable, regardless of what
your configuration might be. Don't try to guess if you have any of the
affected protocols or applications (lets not forget third party apps
using the MS ASN library), just install the patch.=20

Client side, server side, world wide.

Signed,
Marc Maiffret
Chief Hacking Officer
eEye Digital Security
T.949.349.9062
F.949.349.9538
http://eEye.com/Retina - Network Security Scanner
http://eEye.com/Iris - Network Traffic Analyzer
http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities=20

Important Notice: This email is confidential, may be legally privileged,
and is for the intended recipient only. Access, disclosure, copying,
distribution, or reliance on any of it by anyone else is prohibited and
may be a criminal offense. Please delete if obtained in error and email
confirmation to the sender.=20

| -----Original Message-----
| From: Tina Bird [mailto:tbird@precision-guesswork.com]=20
| Sent: Tuesday, February 10, 2004 12:41 PM
| To: Marc Maiffret
| Cc: Joe Blatz; BUGTRAQ@securityfocus.com
| Subject: RE: EEYE: Microsoft ASN.1 Library Length Overflow=20
| Heap Corruption
|=20
|=20
| On Tue, 10 Feb 2004, Marc Maiffret wrote:
|=20
| > This attack can be performed through various encryption=20
| systems such=20
| > as Kerberos and almost anything using CERTs... I am not sure about=20
| > Microsofts wording in their advisory.
|=20
| Microsoft also states that servers are likelier to be=20
| attacked using this vulnerability than clients are, because=20
| they're likelier to be decoding
| ASN.1 data. But if the vulnerable code can be accessed via=20
| LSASS.exe, doesn't that mean all systems are at risk?
|=20
| thanks for any info -- tbird
|=20
| --
| It doesn't have to be our fault to be our responsibility.
|=20
| -- Paul Robertson
|=20
| 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
|=20

[Tim Eddy]

Marc,

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?

Thanks,
Tim



>>> "Marc Maiffret" <mmaiffret@eeye.com> 11/02/2004 7:47:29 am >>>
Yes, I am not sure what Microsoft did with the wording there that
seems
to be misleading to at least a few people so far.

There is just as much, if not more, chance of people using this
vulnerability on server side applications as there is on client-side
applications.

For example we setup a totally IPSEC secured network and we broke into
that network via our ASN bug which is called by the Kerberos. We also
have written exploits that take advantage of ASN via NTLMv2
authentication. And the list goes on... How about evil ASN SSL CERTs?
Client or server? There is a menu a mile long for the avenues of
attacks
that this thing can be used for.

If your running, Windows NT 4.0, Windows 2000, Windows XP, or Windows
2003, you are 99.9999% positive to be vulnerable, regardless of what
your configuration might be. Don't try to guess if you have any of the
affected protocols or applications (lets not forget third party apps
using the MS ASN library), just install the patch.

Client side, server side, world wide.

Signed,
Marc Maiffret
Chief Hacking Officer
eEye Digital Security
T.949.349.9062
F.949.349.9538
http://eEye.com/Retina - Network Security Scanner
http://eEye.com/Iris - Network Traffic Analyzer
http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities


Important Notice: This email is confidential, may be legally
privileged,
and is for the intended recipient only. Access, disclosure, copying,
distribution, or reliance on any of it by anyone else is prohibited
and
may be a criminal offense. Please delete if obtained in error and
email
confirmation to the sender.

| -----Original Message-----
| From: Tina Bird [mailto:tbird@precision-guesswork.com]
| Sent: Tuesday, February 10, 2004 12:41 PM
| To: Marc Maiffret
| Cc: Joe Blatz; BUGTRAQ@securityfocus.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
|


************************************************** ********************
***** IMPORTANT INFORMATION *****
This document should be read only by those persons to whom
it is addressed and its content is not intended for use by
any other persons. If you have received this message in
error, please notify us immediately. Please also destroy and
delete the message from your computer. Any unauthorised form
of reproduction of this message is strictly prohibited.
St.George is not liable for the proper and complete transmission
of the information contained in this communication, nor for any
delay in its receipt.
************************************************** ********************

[James Riden]

"Marc Maiffret" <mmaiffret@eeye.com> writes:

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

I think they use the ominous phrase "many possible vectors"; if
anything kicks off, containing it may not be anything like as easy as
blocking 135/tcp. How easy does it look to exploit it?

Regardless, this one is going to get patched ASAP here.

--
James Riden / j.riden@massey.ac.nz / Systems Security Engineer
GPG public key available at: http://www.massey.ac.nz/~jriden/
This post does not necessarily represent the views of my employer.

[Rainer Gerhards]

> > And that the server is more likely to be attacked is just=20
> 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=20
> unprotected
> > home machines are...
> >
> Yes, but...
>=20
> In order to trigger the ASN.1 vulnerabilities an attacker has=20
> 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?=20
> -- 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...].

>=20
> I can imagine lots of attacks that require user intervention=20
> 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

[Alun Jones]

> -----Original Message-----
> From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]
> Sent: Tuesday, February 10, 2004 3:36 PM
>
> I think Microsoft is using wording to keep the typical end user in a
> warm and cozy state.

How so, exactly? It _is_ marked as a Critical Security Update. What are
you looking for, "no, really, we mean it this time"?

Alun.
~~~~
--
Texas Imperial Software | Find us at http://www.wftpd.com or email
1602 Harvest Moon Place | alun@texis.com.
Cedar Park TX 78613-1419 | WFTPD, WFTPD Pro are Windows FTP servers.
Fax/Voice +1(512)258-9858 | Try our NEW client software, WFTPD Explorer.

[Drew Copley]

=20

> -----Original Message-----
> From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20
> Sent: Wednesday, February 11, 2004 1:11 AM
> To: Tina Bird
> Cc: BUGTRAQ@securityfocus.com
> Subject: RE: EEYE: Microsoft ASN.1 Library Length Overflow=20
> Heap Corruption
>=20
<snip>

> But I think the bottom line of all this is if a box is=20
> listening to 135,
> 139 OR 445, it is vulnerable. And workstations by default=20
> listen to this ports.

If you use Outlook, you are vulnerable.

If you use Internet Explorer, you are vulnerable.

If you use Outlook Express, you are vulnerable.

"Software Affected:
Microsoft Internet Explorer
Microsoft Outlook
Microsoft Outlook Express
Third-party applications that use certificates"

Ref: http://www.eeye.com/html/Research/Advisories/AD20040210.html

Speaking of this bug.

We have noted, perhaps outside of the advisory, that we could send a
malformed, digitally signed email and it could be the exploit point --
further, the email would not even have to be viewed.=20

That is just one potential avenue of attack.




<snip>

> I am pretty sure it can.
>=20
> Rainer
>=20
>=20

[Timothy J.Miller]

On Feb 10, 2004, at 4:16 PM, Tim Eddy wrote:

> Marc,
>
> 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?

Very likely, as IKE data is marshaled into ASN.1 format. The fun part
about ASN.1 is it's so damn useful you tend to use it *everywhere*.

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.

-- Cerebus

[Steve Friedl]

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

I wrote a small dependency-checker, and on my win2000 system it showed
that 232 DLLs depended directly or indirectly on the MSASN1.DLL. It's a
pretty wide range of programs that have this in their address space.

It's a lot harder to find which programs actually *use* it, but checking
Process Explorer shows quite a few applications that have it loaded;

Quicken 2003
Yahoo! IM
AOL IM
SecureCRT
Adobe Acrobat
MusicMatch Jukebox
Turbo Tax 2003
JASC PaintShop Pro
Altova XML Spy

NOTE: this does NOT mean that these applications are vulnerable to
anything (even "potentially"). But it suggests a lot of places to
look for stuff.

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

kerberos is a prime suspect too: 88/tcp and 88/ucp.

Steve

--
Stephen J Friedl | Software Consultant | Tustin, CA | +1 714 544-6561
www.unixwiz.net | I speak for me only | KA8CMY | steve@unixwiz.net

From the MS04-07 bulletin, Windows 9x is not mentioned. Someone has asked
whether Windows 98 is vulnerable to this attack or not. It could be that
Windows 98/ME are vulnerable to this attack through the installation of
Office suite.

The following link refers to the msasn1.dll on Windows ME. But, Windows ME
is not included in the security bulletin on Microsoft website. Then, the
question is whether Windows ME is vulnerable to this attack?
http://216.239.41.104/search?q=cache:bi0p-l5diJ4J:24.229.94.2/crypt32_import
s.html+ASN1BERDecOctetString&hl=en&ie=UTF-8

Below are a snapshot for usage of MSASN1.DLL. What a "monoculture
vulnerability" as far as the DLL base address is concerned!

========================
On Windows NT:
30 Module: 6af00000: C:\WINNT\System32\MSAsn1.DLL for E:\PROGRAM
FILES\MICROSOFT OFFICE\OFFICE\OUTLOOK.EXE

On Windows 2K:
30 Module: 77430000: F:\WIN2K\system32\MSASN1.DLL for
\??\F:\WIN2K\SYSTEM32\WINLOGON.EXE
58 Module: 77430000: F:\WIN2K\system32\MSASN1.DLL for
F:\WIN2K\SYSTEM32\SERVICES.EXE
16 Module: 77430000: F:\WIN2K\system32\MSASN1.DLL for
F:\WIN2K\SYSTEM32\LSASS.EXE
47 Module: 77430000: F:\WIN2K\system32\MSASN1.DLL for
F:\WIN2K\SYSTEM32\SPOOLSV.EXE
56 Module: 77430000: f:\win2k\system32\MSASN1.DLL for
F:\WIN2K\SYSTEM32\SVCHOST.EXE
40 Module: 77430000: F:\WIN2K\system32\MSASN1.DLL for
F:\PROGRA~1\MICROS~3\MSSQL\BINN\SQLSERVR.EXE
26 Module: 77430000: F:\WIN2K\system32\MSASN1.DLL for
F:\WIN2K\SYSTEM32\INETSRV\INETINFO.EXE
11 Module: 77430000: F:\WIN2K\System32\MSASN1.DLL for
F:\WIN2K\SYSTEM32\MQSVC.EXE

On Windows XP:
11 Module: 762a0000: C:\WINDOWS\system32\MSASN1.dll for
\??\C:\WINDOWS\SYSTEM32\WINLOGON.EXE
15 Module: 762a0000: C:\WINDOWS\system32\MSASN1.dll for
C:\WINDOWS\SYSTEM32\LSASS.EXE
39 Module: 762a0000: C:\WINDOWS\system32\MSASN1.dll for
C:\WINDOWS\SYSTEM32\SVCHOST.EXE
20 Module: 762a0000: C:\WINDOWS\system32\MSASN1.dll for
C:\WINDOWS\SYSTEM32\SVCHOST.EXE
24 Module: 762a0000: C:\WINDOWS\system32\MSASN1.dll for
C:\WINDOWS\SYSTEM32\SPOOLSV.EXE
40 Module: 762a0000: C:\WINDOWS\system32\MSASN1.dll for
C:\WINDOWS\EXPLORER.EXE
34 Module: 762a0000: C:\WINDOWS\system32\MSASN1.dll for C:\PROGRAM
FILES\MICROSOFT OFFICE\OFFICE\OUTLOOK.EXE
29 Module: 762a0000: C:\WINDOWS\system32\MSASN1.dll for C:\WINDOWS\HH.EXE
67 Module: 762a0000: C:\WINDOWS\system32\MSASN1.dll for C:\PROGRAM
FILES\ADOBE\ACROBAT 4.0\ACROBAT\ACROBAT.EXE
========================

So, it seems that potential exploit of this vulnerability can be direct like
DCOM-RPC or through emails or even PDF files?

Peter Huang
http://www.ossecurity.ca/
MyDoom, YourDoom, are we all doomed?

> -----Original Message-----
> From: Marc Maiffret [mailto:mmaiffret@eeye.com]
> Sent: Tuesday, February 10, 2004 3:47 PM
> To: Tina Bird
> Cc: Joe Blatz; BUGTRAQ@securityfocus.com
> Subject: RE: EEYE: Microsoft ASN.1 Library Length Overflow Heap
> Corruption
>
>
> Yes, I am not sure what Microsoft did with the wording there that seems
> to be misleading to at least a few people so far.

[Sam Schinke]

Hello Marc,

Tuesday, February 10, 2004, 12:47:29 PM, you wrote:
MM> For example we setup a totally IPSEC secured network and we broke
MM> into that network via our ASN bug which is called by the Kerberos.
MM> We also have written exploits that take advantage of ASN via
MM> NTLMv2 authentication. And the list goes on... How about evil ASN
MM> SSL CERTs? Client or server? There is a menu a mile long for the
MM> avenues of attacks that this thing can be used for.

I think some of the advisories (not yours) relating to this issue are
a very opaque to end users since they only mention "SSL" (US-CERT gets
to this level of detail, MS limits itself to platforms). SSL is just
YATA (Yet Another Tech Acronym) to most users.

Further to that, I believe Microsoft is verging on negligence (and
it's not the first time, IMO) by neglecting to mention these
particular vulnerability details.

In particular their asserting that a "server" is more likely to be
"vulnerable". A server is certainly more likely to be vulnerable to
unsolicited network traffic, but there are a number of ways for client
systems to be impacted by this (eg, all of the client software you
mention in your advisory).

Yes, a remote, packet-based exploit is about as bad as it gets (unless
the vulnerability also doesn't require a TCP handshake), but as your
release mentions, Outlook Express is also vulnerable (So much for
previewing signed email!). If MS is serious about getting people to
patch, people need to be able to tell, at a glance, whether anything
they actually USE is vulnerable. Listing the OS is great, but
excluding very vulnerable client software is shoddy and implying that
systems used as clients aren't "likely" to be vulnerable (in any way)
is a lie.

I guess we'll see yet another revised MS KB. Does anyone have a count
on how many of their security KB's have been (ahem) "revised" in the
past year or two? I seem to recall at least two or three that severely
understated the impact of various issues (like this one), or that
later required revised severity levels.

--
Best regards,
Sam mailto:sschinke@myrealbox.com

[Peter Pentchev]

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

[Boyce, Nick]

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/security/bulletin/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

[Patrice]

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

[Thor Lancelot Simon]

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

[Bill Gallagher]

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

[Joshua Levitsky]

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

[David Wilson]

> 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

[Buck Huppmann]

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

[Florian Weimer]

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

[Michael Shigorin]

--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/security/bulletin/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--

[John]

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