Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Microsoft Security Windows

Microsoft Will Disable WannaCry Attack Vector SMBv1 Starting This Fall (bleepingcomputer.com) 73

An anonymous reader writes: Starting this fall, with the public launch of the next major Windows 10 update — codenamed Redstone 3 -- Microsoft plans to disable SMBv1 in most versions of the Windows operating systems. SMBv1 is a three-decades-old file sharing protocol that Microsoft has continued to ship "enabled by default" with all Windows OS versions.

The protocol got a lot of attention recently as it was the main infection vector for the WannaCry ransomware. Microsoft officially confirmed Tuesday that it will not ship SMBv1 with the Fall Creators Update. This change will affect only users performing clean installs, and will not be shipped as an update. This means Microsoft decision will not affect existing Windows installations, where SMBv1 might be part of a critical system.

This discussion has been archived. No new comments can be posted.

Microsoft Will Disable WannaCry Attack Vector SMBv1 Starting This Fall

Comments Filter:
  • by klingens ( 147173 ) on Saturday June 17, 2017 @03:59PM (#54639771)

    The old Microsoft was backwards compatible to old software. Yes it was hard, yes it meant to support shitty old protocols like SMB v1, but they did it, and lots of stuff worked, just worked together, Microsoft code that actually worked!

    When they disable SMB v1, one cannot put XP or anything before it in the same network as a current Windows to share files. E.g. a XP VM for some old scanner or printer that you can still use via VM and the current host OS can access.

    • by Z00L00K ( 682162 )

      However it's way too late to disable it, and a better alternative would be to make a mod to XP to fix it.

      I had to disable SMBv1 to make my Windows 7 connect to my Samba server. Seems like Samba was ahead of the game there.

    • Then the least they could do is ship newer version with ancient protocols and support for ancient crap DISabled by default. If you need it, enable it. I think the one person out of a million that actually still needs protocols that have been read in "ancient history 101" can be bothered to click "enable" once.

    • msft will get to it when they get to it. its been this way for 35 years.
    • I have discussed all of this in another place [linuxjournal.com]. Microsoft is unambiguous on this issue, and for good reason.

    • Or they could have a security setting to turn it on/off, with it defaulting to off. And they could release it as a security update now instead of next year.
  • by 140Mandak262Jamuna ( 970587 ) on Saturday June 17, 2017 @04:07PM (#54639811) Journal
    30 year old protocols are not ipso facto bad.

    What is bad is not upgrading the security of a protocol that is ON by default for 30 years.

    Let us take something equally ancient on the unix side, like the Xwindows. Is it on by default in linux? Does it suck as much as SMBv1 in terms of security? What kind of security enhancements have gone into each protocol over these three decades?

    I don't know which one is better, but that will give us a sense of how much blame to heap on Microsoft.

    • Re: (Score:3, Interesting)

      by chipschap ( 1444407 )

      30 year old protocols are not ipso facto bad.

      What is bad is not upgrading the security of a protocol that is ON by default for 30 years.

      Let us take something equally ancient on the unix side, like the Xwindows. Is it on by default in linux? Does it suck as much as SMBv1 in terms of security? What kind of security enhancements have gone into each protocol over these three decades?

      I don't know which one is better, but that will give us a sense of how much blame to heap on Microsoft.

      No. It will give us a sense of how much blame to heap on Xwindows. The fact that there are potentially bad practices going on elsewhere doesn't excuse them.

      • I can't wait for 30 years to pass and a vulnerability in v1.0 of systemd comes out to see how measured and reasonable Slashdotters are.

    • by mccalli ( 323026 )
      Well, "what kind of security enhancements" covers the existence of SMB v3. It's not surprising that v1 might not be up to modern security - it was written for a different time.
    • What is bad is not upgrading the security of a protocol that is ON by default for 30 years.

      It HAS been upgraded to version 3. This is not a neglected protocol, this is default backwards compatibility. They are now defaulting to NOT be backwards compatible, due to lack of security.

      But I agree that it should have been turned off much sooner.

      • by Anonymous Coward

        But I agree that it should have been turned off much sooner.

        Almost everything on windows should be turned off by default

    • Let us take something equally ancient on the unix side, like the Xwindows. Is it on by default in linux?

      Yes, of course, but by default all remote connection to the X server are disabled. Red Hat also has a default iptables config that shuts off the port, too.

    • by Sycraft-fu ( 314770 ) on Saturday June 17, 2017 @06:38PM (#54640243)

      When you take something that wasn't designed with security in mind and try to expand and adapt it, you have a lot of issues. Better to start with something designed for the purpose it is being used from the start.

      HTTP is a good example. It was designed as a stateless protocol for transferring text documents with markup. We now rely on it to do stateful transactions for things like shopping carts online and this has lead to tons of security issues since you have to hack on state to a protocol that isn't designed to support it using things like cookies. It would be much more secure had it been designed from the ground up to handle stateful transactions with people.

      IP is another great example. There's all kinds of shit in IPv4 that is completely stupid from the perspective of a protocol used on the Internet. Like source routing, where you can specify the routers that a packet must go through, or the fact that you can just claim to be from any IP you want. This is a bad design for a global communications network. However it is that way because IP wasn't designed for a global communications network, it was designed for an ARPA project and it grew. IPv6 fixes a lot of this because it was designed later, around how IP is actually used these days.

      Also talking about Xwindows is funny because man you wanna talk security risk, X is a huge. If you have an X server that talks on the network any system on the network can just draw to your local display, and you have no easy way of knowing that it isn't your system. Someone can phish passwords in a very hard to detect way using it. Now of course most distros are smart enough to block remote X using the firewall, and you do something like tunnel it over SSH. However that is a hack, it is putting up barriers around something insecure. If those barriers are bypassed, the insecurity is still there. Better if it were designed secure from the ground up. Then you still put the barriers in place as well so that you aren't relying on any one level of security.

      Discontinuing the use of older protocols is a good idea for security, when possible. It isn't always possible, of course, I mean IPv4 is still far and away the most widely used IP spec. But you stop using them when you can (and indeed modern OSes will prefer IPv6 when they have both available).

      • When you take something that wasn't designed with security in mind and try to expand and adapt it, you have a lot of issues. Better to start with something designed for the purpose it is being used from the start.

        If more things were designed without security we would see much better outcomes.

        Security where possible should be treated as an aspect and simply punted to subsystems actually dedicated and capable of providing it rather than continuously (poorly) re-implemented.

        HTTP is a good example. It was designed as a stateless protocol for transferring text documents with markup. We now rely on it to do stateful transactions for things like shopping carts online and this has lead to tons of security issues since you have to hack on state to a protocol that isn't designed to support it using things like cookies.

        HTTP is the wrong layer for security. People have issues because they insist upon entering credentials into adhoc web forms in plaintext over HTTPS instead of authenticating via secure authentication protocol cryptographically bound to encrypted ch

    • No, of course not. How old is IPv4?

      What makes the protocol problematic is that it is not only ancient but also hasn't been in use by anyone in a more or less productive environment for nearly as long as it exists. The problem here is that with a lack of use, a lack of auditing comes along. An things that don't get audited because nobody really relies on them also get very little scrutiny when it comes to their security flaws.

    • Let us take something equally ancient on the unix side, like the Xwindows. Is it on by default in linux? Does it suck as much as SMBv1 in terms of security?

      Sucking as much is a loaded question. The reality is everything sucks differently. You can't bolt on security without making a mess. Security needs to be thought of from the beginning or the protocol needs to be replaced with something else. Here's a classic example from X: Not only can anything draw on the screen, it can also block other things from drawing on the screen. This has serious implications for something like a lock screen. [martin-graesslin.com]

      If something wasn't thought up when a protocol was created then adding i

    • The X Windows protocol itself does not include any security beyond a simple password check that is sent unencrypted, so running it straight up on a network that has any public connections is a bad idea. But these days people mostly run it tunneled through an SSH connection, which is encrypted, except for connections on the local host. So it has effectively gotten a security update even though the X protocol itself was not upgraded.
    • by ebvwfbw ( 864834 )

      It wasn't as if it was really on for 30 years. Microsoft didn't own networking until at least the mid 1990s, I'd argue well into the 2000s. So I'd say 10-15 years. Novell and Unix ran it before. Novel Dominated windows networking well into the 1990s. I wouldn't be surprised if Novel isn't still running some government agencies. I remember Microsoft couldn't give their networking away. Then they called it "NT", had a big fan fair and such.. and stupid managers bought it. Says NEW... New Technology! No, it wa

  • by rsilvergun ( 571051 ) on Saturday June 17, 2017 @04:14PM (#54639839)
    and small networked systems? I honestly haven't paid much attention to the underlining protocols of Windows file sharing. What, if any, advantages are there to having it on by default?
    • by Anonymous Coward

      In general, no, you can turn it off as long as you don't have any windows XP, 2003 or older machines. Network printers the big exception, they often only support SMBv1.

    • Unless you have stuff from the windows xp/windows 2003 time frame you are probably good. you will need v3 and alot of things need v2.
  • by Anonymous Coward on Saturday June 17, 2017 @05:57PM (#54640119)

    disable by default:

    * cortana
    * search
    * xbox
    * windows store updates
    * non critical updates
    * old app profiling
    * prefeching the unprefetchable
    * apps in suspended mode
    * task scheduler
    * onedrive
    * remote access
    * remote admin
    * windows media
    * shared folders

    and the list goes on and on and on

    btw do you know you can boot with a linux usb and delete all the windows store/windows apps folders? some registry cleanup after boot but hey no more ghost process in background eating cpu and memory

  • by Anonymous Coward

    From MS - SMB Ports 445/139 (TCP) & 137/138 (UDP) protection via:

    Disable SMBv1 on the SERVER, configure the following registry key:

    Registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters Registry entry: SMB1

    REG_DWORD: 0 = Disabled
    REG_DWORD: 1 = Enabled

    Default: 1 = Enabled

    Enable SMBv2 on the SERVER, configure the following registry key:

    Registry subkey:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters Registry entry: SMB2

    REG_DWORD: 0 = Disab

  • This SMB thing reminds me of people arguing over which version of SNMP is better to use. Use version 1... no version 2c that's better... no v3 with passwords and privacy passwords is much safer when the reality is no matter what version you select the outcome is still very much the same: your fucked. The only sane method for securing SNMP is restricting use to secure channels. (e.g. (D)TLS or SSH)

    My understanding SMB is no different. Even latest and greatest version 3 with somewhat modern algorithms stil

  • by najajomo ( 4890785 ) on Saturday June 17, 2017 @10:57PM (#54640975)
    At least us Windows users have a modern GUI interface to play with instead of all those text config files under Linux.
    • Give me the text config files any day. Easy to edit, easy to do version control, easy to diff, etc. Easy to add comments, for that matter. No mouse needed, just the keyboard. Fast and accurate.

      GUIs are nice for casual administration (if there is such a thing) but to do any sort of heavy lifting, text files are efficient and manageable.

  • I disabled smbv1 back when wannacry broke and while my winows boxes could still talk to each other fine, my macs and Linux boxes all started failing.

If this is a service economy, why is the service so bad?

Working...