NIST gave CVE-2011-0654 the highest severity rank (10) on February 16th — complete loss of confidentiality and integrity from a trivial remote exploit. They assigned it the following Common Weakness Enumeration
CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer
Microsoft apparently failed to follow their own design specification. Section 2.2.3 or “RequestElection Browser Frame” of the Common Internet File System (CIFS) Browser Protocol has the following requirement.
ServerName (variable): MUST be a null-terminated ASCII server name and MUST be less than or equal to 16 bytes in length, including the null terminator.
It seems unusually clear and with heavy emphasis. They “MUST” be less. Is that meant to be a hint or a challenge?
It obviously is not difficult to craft a ServerName variable that violates the 16 byte null-terminated ASCII rule in an SMB response, and it is not hard to push a user into accessing a server. So the attack difficulty is rated as low. Section 3.3.5.8 or “Receiving a RequestElection Frame from CIFS” also makes a good point about elections and forcing a response.
The RequestElectionframe (as specified in section 2.2.3) MUST be sent whenever a browser client or server is unable to retrieve information that is maintained by the local master browser server. It also MUST be issued when a local master browser server receives a frame that indicates that another machine on the machine group also believes it is a local master browser server.
In other words, there are plenty of vectors to send a large ServerName that violates section 2.2.3 of the Microsoft Windows Browser Protocol to compromise a system.
Microsoft gave their response on April 12th to this boundary error, almost two months after disclosure:
Security Bulletin MS11-019 – Critical
Vulnerabilities in SMB Client Could Allow Remote Code Execution (2511455)…these vulnerabilities could allow remote code execution if an attacker sent a specially crafted SMB response to a client-initiated SMB request. To exploit the vulnerability, an attacker must convince the user to initiate an SMB connection to a specially crafted SMB server.
Their patch is nothing fancy. It basically follows the section 2.2.3 requirement.
The security update addresses the vulnerabilities by correcting the manner in which the CIFS Browser handles specially crafted Browser messages, and correcting the manner in which the SMB client validates specially crafted SMB responses
That could be the start and end of the story, except for the fact that Microsoft is not really new to this game.
Microsoft Security Bulletin MS10-020 – Critical
Vulnerabilities in SMB Client Could Allow Remote Code Execution (980232)Microsoft Security Bulletin MS10-006 – Critical
Vulnerabilities in SMB Client Could Allow Remote Code Execution (978251)Microsoft Security Bulletin MS09-001 – Critical
Vulnerabilities in SMB Could Allow Remote Code Execution (958687)Microsoft Security Bulletin MS08-068 – Important
Vulnerability in SMB Could Allow Remote Code Execution (957097)Microsoft Security Bulletin MS06-030
Vulnerability in Server Message Block Could Allow Elevation of Privilege (914389)Microsoft Security Bulletin MS05-027
Vulnerability in Server Message Block Could Allow Remote Code Execution (896422)Microsoft Security Bulletin MS05-011
Vulnerability in Server Message Block Could Allow Remote Code Execution (885250)
Note the exploit details from February 8, 2005:
The Server Message Block (SMB) implementation for Windows NT 4.0, 2000, XP, and Server 2003 does not properly validate certain SMB packets, which allows remote attackers to execute arbitrary code via Transaction responses containing (1) Trans or (2) Trans2 commands, aka the “Server Message Block Vulnerability,” and as demonstrated using Trans2 FIND_FIRST2 responses with large file name length fields
How strangely familiar that sounds, despite being six years ago…and last but not least (I’ve omitted many others, such as MS02-070)
Microsoft Security Bulletin MS03-024
Buffer Overrun in Windows Could Lead to Data Corruption (817606)
I am reminded of a January 1997 paper by Hobbit (hobbit@avian.org) called “CIFS: Common Insecurities Fail Scrutiny”
By now the reader may be thinking twice before replacing all those Unix servers with NT, and considering the significant risks in yielding to all that marketing rah-rah. In general we now see, in what is hoped to be a clearer way than previously, both how and why to check networks for these additional vulnerabilities. Unix may have its own problems, but overall it is still easier to secure and verify for correctness, and is largely free with all sources included. There are many good people out there proactively finding and fixing Unix problems on a daily basis. And as detailed in this document, Unix still has plenty of fight in it to help kick the NT monster in the ass.
Ah, look how far we have come.