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.
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.
Microsoft kills what made it great (Score:4, Informative)
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.
Re: (Score:1)
VueScan (https://www.hamrick.com) will let you use any scanner on any OS, regardless of driver support. I use it to use an old SCSI scanner form the windows 95 days on my 64-bit Win10 setup.
Re: (Score:3)
SCSI scanners actually use a standard protocol and shouldn't need drivers...
Re: (Score:2)
VueScan (https://www.hamrick.com) will let you use any scanner on any OS, regardless of driver support.
Second this. When I saw how easy VueScan made scanning from old hardware, I bought a professional license 10+ years ago. Still getting free updates. Software runs on Windows, Mac and Linux.
Re: Microsoft kills what made it great (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
To their defense, SMBv1 support isn't remotely as annoying as Clippy, most likely most people never noticed its existence.
Re: (Score:2)
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.
Re: Microsoft kills what made it great (Score:2)
SMB1 is a disaster - don't use it (Score:2)
I have discussed all of this in another place [linuxjournal.com]. Microsoft is unambiguous on this issue, and for good reason.
Re: (Score:2)
Problem is not the age of the protocol (Score:5, Interesting)
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)
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.
Re: (Score:2)
>it is a distributor choice
So its on by default. Thank you for your valid and long argument
Re: Problem is not the age of the protocol (Score:1)
Re: (Score:2)
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.
Re: (Score:3)
Re: (Score:3)
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.
Re: (Score:1)
But I agree that it should have been turned off much sooner.
Almost everything on windows should be turned off by default
Re: (Score:2)
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.
Old protocols are a huge problem (Score:5, Insightful)
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).
Re: (Score:3)
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
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:1)
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
Re: (Score:2)
So in other words you could not be assed to update the security of your printers for years until it finally broke connectivity?
Just so I know what I should avoid like the plague, what copier manufacturer are you working for?
Re: (Score:2)
So in other words you could not be assed to update the security of your printers for years until it finally broke connectivity?
Printer security is a can of worms. If you think that is bad, try finding and removing Windows-based medical devices from the general VLAN.
Re: (Score:2)
I know. Try, just TRY to get a printer 802.1X compliant.
That doesn't mean you can throw your hands up and just be done with it.
Is there a reason not to disable it on home (Score:3)
Re: (Score:1)
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.
Re: (Score:2)
while you are at it (Score:4, Insightful)
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
Re:while you are at it (Score:4, Insightful)
And ENable by default showing file extensions and showing "hidden" files while you're at it!
Protect vs. WanaCry easily 2 ways (Score:2, Informative)
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
Idiots arguing over who is smartest (Score:2)
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
How to disable SMBv1 .. (Score:3, Funny)
Re: (Score:3)
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.
Caveat emptor (Score:2)
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.