10 ms·

Windows has a new wormable vulnerability, with no patch

250 points by vo2maxer 7y ago

christophilus 7y ago
Another buffer overflow bug. I’d love to see a running tally of the cost of buffer overflows.
- SteveNuts 7y ago
  The number of buffer overflow vulnerabilities is probably starting to overflow itself by now.
- vmchale 7y ago
  > Another buffer overflow bug. time to shill ATS
  - heartbeats 7y ago
    I don't get why ATS isn't more popular. It's a really cool language.
    - pjmlp 7y ago
      It is very cool, but the type system is quite complex.
- johnr2 7y ago
  > I’d love to see a running tally of the cost of buffer overflows. It's probably a lot lower than the cost of never implementing the software in the first place.
- ksk 7y ago
  Well if they would have written Windows in a dynamic language 26 years ago, nobody would be using it, and the cost would be zero.. :P
- pjmlp 7y ago
  Apparenltly quite a bit, https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-more-secure-code/ https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro... 70% exploits leading to a few billions in salaries to everyone involved fixing those holes.
- ThrowawayR2 7y ago
  > "I’d love to see a running tally of the cost of buffer overflows" Buffer overflows don't even show up in OWASP's list of top 10 vulnerabilities, most of which are language agnostic. Aside from that, a tally of the cost of buffer overflows is dwarfed by a tally of the cost of CPU cycles, RAM, and other system resources wasted by the inefficiency of safe languages and their ecosystems.
speedgoose 7y ago
Perhaps one day unsafe programming languages will be forbidden to use.
- johnr2 7y ago
  > Perhaps one day unsafe programming languages will be forbidden to use. That would mean ruling out a whole lot of performance-critical software (including that written in unsafe Rust). Be careful what you wish for.
  - speedgoose 7y ago
    I'm quite sure the performance hit will be fine in a few decades.
    - fl0wenol 7y ago
      That kind of thinking made sense twenty years ago where you could assume Moore's law was going to hold into the next decades.
      - speedgoose 7y ago
        You don't think we will have budget for a few safety checks?
    - jsjddbbwj 7y ago
      That's exactly the line of thinking that has made computers much less responsive than they were 20 years ago.
- msla 7y ago
  Every programming language capable of expressing arbitrary recursion or looping is unsafe. Doesn't matter what kinds of checks you put in. It might matter what kind of runtime you have, but a runtime isn't a language, is it? We're talking about the language, and any language sufficiently expressive to allow you to say "loop until you are done" instead of "loop precisely 20 times" is inherently unsafe.
okareaman 7y ago
I'm an old asm/C/C++ programmer (retired) who wanted to learn Rust but didn't make the effort because of all the stories about how hard it was to deal with the borrow checker. Then I realized that for a programmer like me that was used to managing memory in my head, the borrow checker would be a piece of cake. I wrote my first program in it and it was not hard at all. I get it that JavaScript/Python etc... programmers who always had a garbage collector might have trouble. It was so nice to have the compiler catch several stupid errors for me. If I were King of the world I would decree that all new public facing software with real world consequences had to be written in Rust. I'm pretty sure I read that Microsoft is looking at Rust to mitigate some of these issues. Edit: added "new" to make it clear I don't mean rewriting everything in Rust.
- pjmlp 7y ago
  Currently the biggest issues with the borrow checker are valid codes that it marks as invalid (polonius might fix those when it arrives), and self referencial structures like those using in UI frameworks callbacks.
- londons_explore 7y ago
  When you already have 10's of millions of lines of code written in C++, migrating to rust is no easy task... Microsoft already tried to migrate bits of userspace to C# in 2008 with windows vista, and that didn't exactly go well... They also tried to migrate UI stuff to HTML in 1998 (Windows explorer, Active desktop). Didn't work out great either. Perhaps 10 years is their corporate memory-span and we're overdue another try tho?
  - okareaman 7y ago
    I'm not suggesting re writing everything. I'm suggesting that it's irresponsible to start a new project in an unsafe language when an equally efficient safe language is available.
    - vlovich123 7y ago
      This isn't a new project. Also tooling is a thing & in bigger companies you have to deal with inertia (retraining people is hard). I think at some point the bullet has to be bitten. I also think there's some value in figuring out how to write C/C++ -> Rust translators to automate some of this process. That's the only way we can get ahead of the curve.
jra_samba 7y ago
(Copy of a comment I posted on ars): Microsoft hasn't contacted us (Samba) so this almost certainly isn't a protocol level bug (they're very good about being proactive on these), but an error in their implementation of the SMB3 compression transform. In other words, a typical buffer overrun in a compression library. Gee, wonder where I've seen these before. Currently Samba doesn't implement the SMB3 transform header, an example where being slow to implement a feature is an advantage for once :-). So most Linux-based SMB3 servers and NAS boxes (which use Samba) will not be affected by this (I believe - things may change as more information becomes available).
- kazinator 7y ago
  Are you saying that Samba would use the same compression library as the Windows file sharing implementation, and so hit the same flaw?
  - oneplane 7y ago
    If the bug was in a library supply by MS and used by SMB and Samba would use that library then the vulnerability would also be present in Samba. But that isn't the case, Samba re-implements the SMB client/server code in it's own library. A vulnerability that would transfer between different codebases would be protocol-level because all clients and servers that are to be compliant would have to implement the same protocol(s) and perhaps would easily all write identical state machines. Those kinds of errors are often range errors and logic errors as far as I know, which is a different kind of error as far was I have seen written about this compression bug.
  - jra_samba 7y ago
    No, I'm saying that these kind of bugs in compression libraries are very common. We'll pick an open source one of course (we don't want to be in the writing and maintaining compression library business, just like we don't want to be in the crypto business), but we'd also be vulnerable to bugs in upstream if the compression library we use has them. I don't know what compression library Microsoft is using - probably they wrote their own.
- 7y ago
upofadown 7y ago
>Windows users who have SMBv3 exposed on the Internet ... Is that something that ever happens on purpose?
- T-hawk 7y ago
  No, but that just means the internet isn't the attack surface. If a machine on an intranet gets compromised by some other means, this is a vector for that machine to attack anything it can reach with SMB.
- olyjohn 7y ago
  Azure Files is exactly this. https://docs.microsoft.com/en-us/azure/storage/files/storage-files-introduction https://docs.microsoft.com/en-us/azure/storage/files/storage...
ck2 7y ago
block port 445 inbound, it's more than nothing
- pixl97 7y ago
  The vast majority of desktop computers will not need 445 inbound. If you happen to have some enterprise tool that does, just add an allow rule for those particular servers. This protects you against a large number of other attacks such as ransomware over the local network too.
- gruez 7y ago
  You’d want to block 445 outbound as well, in case your computer tries to connect to an external server (eg. social engineering and/or UNC paths)
EvanAnderson 7y ago
Blocking TCP port 445 on servers and clients where file sharing isn't necessary is a good idea anyway. Windows Firewall and Group Policy are sufficient to get that rolled out. Unfortunately, Active Directory Domain Controllers must expose it to function properly, so hitting those machines with the workaround registry value is a good idea.
rfoo 7y ago
Don't worry, #itsjusttheblue.
technion 7y ago
I built an Active Directory template to deploy Microsoft's mitigation: https://github.com/technion/DisableSMBCompression https://github.com/technion/DisableSMBCompression
andrewflnr 7y ago
They just casually mention that Talos pulled their advisory without any indication of why. Does anyone know? Did MS just ask them to?
longcat 7y ago
This only impacts 1903 and 1909 releases of Windows, so any Windows Server LTSC 2016 and 2019 aren't affected.
keepsmiling 7y ago
Hi, a patch has ben released CVE-2020-0796.

250 points by vo2maxer 7y ago

christophilus 7y ago

Another buffer overflow bug. I’d love to see a running tally of the cost of buffer overflows.

SteveNuts 7y ago
The number of buffer overflow vulnerabilities is probably starting to overflow itself by now.
vmchale 7y ago
> Another buffer overflow bug. time to shill ATS
- heartbeats 7y ago
  I don't get why ATS isn't more popular. It's a really cool language.
  - pjmlp 7y ago
    It is very cool, but the type system is quite complex.
johnr2 7y ago
> I’d love to see a running tally of the cost of buffer overflows. It's probably a lot lower than the cost of never implementing the software in the first place.
ksk 7y ago
Well if they would have written Windows in a dynamic language 26 years ago, nobody would be using it, and the cost would be zero.. :P
pjmlp 7y ago
Apparenltly quite a bit, https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-more-secure-code/ https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro... 70% exploits leading to a few billions in salaries to everyone involved fixing those holes.
ThrowawayR2 7y ago
> "I’d love to see a running tally of the cost of buffer overflows" Buffer overflows don't even show up in OWASP's list of top 10 vulnerabilities, most of which are language agnostic. Aside from that, a tally of the cost of buffer overflows is dwarfed by a tally of the cost of CPU cycles, RAM, and other system resources wasted by the inefficiency of safe languages and their ecosystems.

speedgoose 7y ago

Perhaps one day unsafe programming languages will be forbidden to use.

johnr2 7y ago
> Perhaps one day unsafe programming languages will be forbidden to use. That would mean ruling out a whole lot of performance-critical software (including that written in unsafe Rust). Be careful what you wish for.
- speedgoose 7y ago
  I'm quite sure the performance hit will be fine in a few decades.
  - fl0wenol 7y ago
    That kind of thinking made sense twenty years ago where you could assume Moore's law was going to hold into the next decades.
    - speedgoose 7y ago
      You don't think we will have budget for a few safety checks?
  - jsjddbbwj 7y ago
    That's exactly the line of thinking that has made computers much less responsive than they were 20 years ago.
msla 7y ago
Every programming language capable of expressing arbitrary recursion or looping is unsafe. Doesn't matter what kinds of checks you put in. It might matter what kind of runtime you have, but a runtime isn't a language, is it? We're talking about the language, and any language sufficiently expressive to allow you to say "loop until you are done" instead of "loop precisely 20 times" is inherently unsafe.

okareaman 7y ago

I'm an old asm/C/C++ programmer (retired) who wanted to learn Rust but didn't make the effort because of all the stories about how hard it was to deal with the borrow checker. Then I realized that for a programmer like me that was used to managing memory in my head, the borrow checker would be a piece of cake. I wrote my first program in it and it was not hard at all. I get it that JavaScript/Python etc... programmers who always had a garbage collector might have trouble. It was so nice to have the compiler catch several stupid errors for me. If I were King of the world I would decree that all new public facing software with real world consequences had to be written in Rust. I'm pretty sure I read that Microsoft is looking at Rust to mitigate some of these issues. Edit: added "new" to make it clear I don't mean rewriting everything in Rust.

pjmlp 7y ago
Currently the biggest issues with the borrow checker are valid codes that it marks as invalid (polonius might fix those when it arrives), and self referencial structures like those using in UI frameworks callbacks.
londons_explore 7y ago
When you already have 10's of millions of lines of code written in C++, migrating to rust is no easy task... Microsoft already tried to migrate bits of userspace to C# in 2008 with windows vista, and that didn't exactly go well... They also tried to migrate UI stuff to HTML in 1998 (Windows explorer, Active desktop). Didn't work out great either. Perhaps 10 years is their corporate memory-span and we're overdue another try tho?
- okareaman 7y ago
  I'm not suggesting re writing everything. I'm suggesting that it's irresponsible to start a new project in an unsafe language when an equally efficient safe language is available.
  - vlovich123 7y ago
    This isn't a new project. Also tooling is a thing & in bigger companies you have to deal with inertia (retraining people is hard). I think at some point the bullet has to be bitten. I also think there's some value in figuring out how to write C/C++ -> Rust translators to automate some of this process. That's the only way we can get ahead of the curve.

jra_samba 7y ago

(Copy of a comment I posted on ars): Microsoft hasn't contacted us (Samba) so this almost certainly isn't a protocol level bug (they're very good about being proactive on these), but an error in their implementation of the SMB3 compression transform. In other words, a typical buffer overrun in a compression library. Gee, wonder where I've seen these before. Currently Samba doesn't implement the SMB3 transform header, an example where being slow to implement a feature is an advantage for once :-). So most Linux-based SMB3 servers and NAS boxes (which use Samba) will not be affected by this (I believe - things may change as more information becomes available).

kazinator 7y ago
Are you saying that Samba would use the same compression library as the Windows file sharing implementation, and so hit the same flaw?
- oneplane 7y ago
  If the bug was in a library supply by MS and used by SMB and Samba would use that library then the vulnerability would also be present in Samba. But that isn't the case, Samba re-implements the SMB client/server code in it's own library. A vulnerability that would transfer between different codebases would be protocol-level because all clients and servers that are to be compliant would have to implement the same protocol(s) and perhaps would easily all write identical state machines. Those kinds of errors are often range errors and logic errors as far as I know, which is a different kind of error as far was I have seen written about this compression bug.
- jra_samba 7y ago
  No, I'm saying that these kind of bugs in compression libraries are very common. We'll pick an open source one of course (we don't want to be in the writing and maintaining compression library business, just like we don't want to be in the crypto business), but we'd also be vulnerable to bugs in upstream if the compression library we use has them. I don't know what compression library Microsoft is using - probably they wrote their own.
7y ago

upofadown 7y ago

>Windows users who have SMBv3 exposed on the Internet ... Is that something that ever happens on purpose?

T-hawk 7y ago
No, but that just means the internet isn't the attack surface. If a machine on an intranet gets compromised by some other means, this is a vector for that machine to attack anything it can reach with SMB.
olyjohn 7y ago
Azure Files is exactly this. https://docs.microsoft.com/en-us/azure/storage/files/storage-files-introduction https://docs.microsoft.com/en-us/azure/storage/files/storage...

ck2 7y ago

block port 445 inbound, it's more than nothing

pixl97 7y ago
The vast majority of desktop computers will not need 445 inbound. If you happen to have some enterprise tool that does, just add an allow rule for those particular servers. This protects you against a large number of other attacks such as ransomware over the local network too.
gruez 7y ago
You’d want to block 445 outbound as well, in case your computer tries to connect to an external server (eg. social engineering and/or UNC paths)

EvanAnderson 7y ago

Blocking TCP port 445 on servers and clients where file sharing isn't necessary is a good idea anyway. Windows Firewall and Group Policy are sufficient to get that rolled out. Unfortunately, Active Directory Domain Controllers must expose it to function properly, so hitting those machines with the workaround registry value is a good idea.

rfoo 7y ago

Don't worry, #itsjusttheblue.

technion 7y ago

I built an Active Directory template to deploy Microsoft's mitigation: https://github.com/technion/DisableSMBCompression https://github.com/technion/DisableSMBCompression

andrewflnr 7y ago

They just casually mention that Talos pulled their advisory without any indication of why. Does anyone know? Did MS just ask them to?

longcat 7y ago

This only impacts 1903 and 1909 releases of Windows, so any Windows Server LTSC 2016 and 2019 aren't affected.

keepsmiling 7y ago

Hi, a patch has ben released CVE-2020-0796.