The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

The SecuriTeam alerts list - Free, Accurate, Independent.

Get your security news from a reliable source.

- - - - - - - - -



While investigating the Microsoft Server Service Mailslot heap overflow
vulnerability reported in Microsoft Security Bulletin MS06-035 [1], Core
Security Technologies researcher Gerardo Richarte discovered a second bug
in the server service.

This new vulnerability affects Windows systems with and without the
MS06-035 and any subsequent patches up to the date of publication of this

Proof-of-concept code to exploit the vulnerability was made publicly
available in or around July 19th, 2006 and at least one third party
security vendor published a security advisory describing the bug.

Further analysis of the vulnerability seems to indicate that exploitation
is limited to a remote denial of service attack without the need of user

The vendor was notified of the finding on July 14th, 2006 and has
indicated that issuance of a fix is tentatively scheduled for the November
patch release. [see "Vendors contacted" section below]


Vulnerable Systems:
* Windows 2000 SP0-Sp4
* Windows NT4 SP6a
* Windows XP SP0-SP2
* Windows 2003 SP0-SP1

Immune Systems:
* Windows Vista beta 2 build 5381

The vulnerability can be triggered by sending a malformed
SMB_COM_TRANSACTION SMB message (0x25) that includes a string that is not
properly null terminated.

The crash was originally triggered by sending a SMB_COM_TRANSACTION
message using the string "\\MAILSLOT\LANMAN" (without NUL termination) in
an attempt to reproduce the MS06-035 bug(s).

The observed crash was actually inside __imp___wcsnicmp, when the string
"\\MAILSLOT" is compared to a NULL pointer. The following code, from
ExecuteTransaction(), is where wcsnicmp() is called from.

SRV.SYS:0002f487: push 9
SRV.SYS:0002f489: push "\\MAILSLOT"
SRV.SYS:0002f48f: push dword ptr [eax+24h] <-- [eax+24] is NULL
SRV.SYS:0002f492: call ds:__imp___wcsnicmp <-- Crash Inside (tm)
SRV.SYS:0002f498: add esp, 0ch
SRV.SYS:0002f49b: test eax, eax
SRV.SYS:0002f49d: jnz loc_2f4aa
SRV.SYS:0002f49f: push esi
SRV.SYS:0002f4a0: call _MailslotTransaction@4 <- execution flow does
not reach this point
SRV.SYS:0002f4a5: jmp loc_20bf6

Since the call to MailslotTransaction() is never reached and the crash is
triggered before that call we conclude that the bug is not specifically
related to MAILSLOT functionality. Upon further investigation it became
apparent that any SMB_COM_TRANSACTION message with a string that is not
null terminated will trigger a crash.

CVE Information:

Vendors contacted:
* Microsoft
2006-07-12: Microsoft Security Bulletin MS06-035[1]
2006-07-12: Core releases exploit for MS06-035 to customers
2006-07-14: Customers report that exploit works against fully patched
2006-07-14: Core's initial notification to vendor of new bug discovery
2006-07-14: Vendor acknowledges notification, requests details/PoC
2006-07-14: Core provides sample PoC code to vendor
2006-07-14: Vendor acknowledgment, case opened
2006-07-19: Proof-of-concept becomes publicly available
2006-07-27: Vendor confirms as new issue and repro
2006-07-28: IDS/IPS security vendor (ISS) advisory discloses
vulnerability in the MS06-035 detection module[2]
2006-07-28: Vendor discloses vulnerability on MSRC blog[3]
2006-07-28: ISS security advisory about publicly available "misconstrued
Mailslot vulnerability" proof-of-concept exploit[4]
2006-08-11: Vendor communicates tentative plan for a fix in November,
2006-08-14: Advisory CORE-2006-07-14 published

References/Additional information:
[1] <http://www.microsoft.com/technet/security/bulletin/ms06-035.mspx>
[2] <http://xforce.iss.net/xforce/alerts/id/230>
[3] <http://blogs.technet.com/msrc/archive/2006/07/28/443837.aspx>
[4] <http://xforce.iss.net/xforce/alerts/id/231>


The information has been provided by Core Security Technologies
The original article can be found at:


This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@xxxxxxxxxxxxxx
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@xxxxxxxxxxxxxx


The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

Relevant Pages

  • Administrivia: Response to OIS Draft on "Security Vulnerability and Response Process"
    ... vulnerability or not. ... to see what they can expect, at each Vendor, or for each Coordinator, ... and possibly a lot longer if the Finder doesn't pester ... security of users, critical infrastructures, and the Internet"...and ...
  • Re: [Full-Disclosure] Vulnerability Disclosure Debate
    ... You see, with a lock, the primary purpose of it is ... or of other requirements than personal security. ... there is only one vendor that I'm aware of that can do that -- Microsoft ... code for every vulnerability eliminates the notion of difficulty to exploit, ...
  • Re: [Full-Disclosure] Vulnerability Disclosure Debate
    ... You see, with a lock, the primary purpose of it is ... or of other requirements than personal security. ... there is only one vendor that I'm aware of that can do that -- Microsoft ... code for every vulnerability eliminates the notion of difficulty to exploit, ...
  • Re: Using 0days as part of pen-test?
    ... the client the option to determine how the vendor gets notified. ... vulnerability information you discover during ... The legal issue isn't the disclosure process, you can act as "legal entity" ... security threats until the vendor release a patch. ...
  • Re: Call to arms - INFORMATION ANARCHY
    ... Its one thing to prove to a Vendor they have a problem in their code. ... and its not resolved by keeping "Full Disclosure" alive. ... > the Vendor for a vulnerability without accepting responsibility for your ... > feed the feature versus security mentality of many Vendors. ...