[HN Gopher] Windows has a new wormable vulnerability, with no patch
___________________________________________________________________
Windows has a new wormable vulnerability, with no patch
Author : vo2maxer
Score : 170 points
Date : 2020-03-11 12:14 UTC (10 hours ago)
(HTM) web link (arstechnica.com)
(TXT) w3m dump (arstechnica.com)
| ck2 wrote:
| block port 445 inbound, it's more than nothing
| pixl97 wrote:
| 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 wrote:
| 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)
| andrewflnr wrote:
| They just casually mention that Talos pulled their advisory
| without any indication of why. Does anyone know? Did MS just ask
| them to?
| jra_samba wrote:
| (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).
| gsam wrote:
| Have you seen any signs of which compression algorithm might be
| the one affected? Presumably it's one of their more snowflake
| ones. If it is in a library, surely SMB isn't the only affected
| resource? Perhaps it's not the library, but the plumbing or the
| headers and such.
| kazinator wrote:
| Are you saying that Samba would use the same compression
| library as the Windows file sharing implementation, and so hit
| the same flaw?
| jra_samba wrote:
| 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.
| oneplane wrote:
| 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.
| upofadown wrote:
| >Windows users who have SMBv3 exposed on the Internet ...
|
| Is that something that ever happens on purpose?
| olyjohn wrote:
| Azure Files is exactly this.
|
| https://docs.microsoft.com/en-us/azure/storage/files/storage...
| T-hawk wrote:
| 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.
| EvanAnderson wrote:
| 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.
| christophilus wrote:
| Another buffer overflow bug. I'd love to see a running tally of
| the cost of buffer overflows.
| ThrowawayR2 wrote:
| > " _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.
| pjmlp wrote:
| Apparenltly quite a bit,
|
| 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.
| johnr2 wrote:
| > 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 wrote:
| 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
| SteveNuts wrote:
| The number of buffer overflow vulnerabilities is probably
| starting to overflow itself by now.
| vmchale wrote:
| > Another buffer overflow bug.
|
| time to shill ATS
| heartbeats wrote:
| I don't get why ATS isn't more popular. It's a really cool
| language.
| pjmlp wrote:
| It is very cool, but the type system is quite complex.
| speedgoose wrote:
| Perhaps one day unsafe programming languages will be forbidden to
| use.
| ksk wrote:
| 'Banning' things you don't personally like is not a great
| tactic to convince people. Other technologies should keep
| making things easier for the C folks to migrate to...
| msla wrote:
| 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.
| andrewflnr wrote:
| It is not the case that every Turing complete language allows
| certain inputs to cause the program to break the bounds of
| the language's semantics and go rampaging through its
| simulator. That's what unsafe means in the context of memory
| vulnerabilities. Yes, Rice's Theorem is cool, but so are
| sound and complete type systems.
| johnr2 wrote:
| > 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 wrote:
| I'm quite sure the performance hit will be fine in a few
| decades.
| fl0wenol wrote:
| 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 wrote:
| You don't think we will have budget for a few safety
| checks?
| pjmlp wrote:
| Back in 1961 Burroughs introduced an OS, nowadays still sold by
| Unisys.
|
| Guess what, their system language ESPOL, an Algol derivative
| later replaced by NEWP, already had unsafe code blocks.
|
| Binaries that made use of unsafe were tainted and required that
| the admin would given them permission to execute.
|
| This almost 10 years before C was created.
| rfoo wrote:
| Don't worry, #itsjusttheblue.
| okareaman wrote:
| 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.
| fortran77 wrote:
| There's no reason Samba can't be user-mode and written in
| C#/.net. Even safer!
| jimmaswell wrote:
| I really wanted to give Rust a chance for the memory management
| but I just don't have the motivation to get past the absolutely
| bizarre syntax, naming conventions full of weird abbreviations
| like it's the 80s, and the inscrutable replacement for the OO
| everyone is familiar with. Every facet of the language feels
| like an exercise in NIH syndrome and it's just too much at
| once.
| nicoburns wrote:
| Bizarre syntax? It's almost identical to
| JavaScript/TypeScript syntax. You know, the #1 most used
| language.
| jimmaswell wrote:
| JS, C++, C# are what I'm coming from. There was no need to
| put things in strange orders and otherwise do so many other
| things different from C style for no apparent reason. Sure,
| you can find some example of another language doing
| something any way, but that doesn't make it a good idea.
| What tangible benefit is there to having to put the type
| after the function declaration?
| TheDong wrote:
| You've given one concrete example, the type after the
| function deceleration.
|
| I'll respond to that because there is a concrete benefit.
| For what it's worth, typescript, go, SML, haskell, and
| many other languages follow this pattern too.
|
| In C, there's the "clockwise spiral rule"[0] to read a
| complex c declaration. Let's take an example from that:
| void (*signal(int, void (*fp)(int)))(int);
|
| In rust, that would be: fn signal(i:
| isize, fp: Fn(isize) -> ()) -> Fn(isize) -> ()
|
| In rust, the clockwise spiral rule is more simply the
| "read left to right" rule, which follows more naturally
| for most people.
|
| For what it's worth, C++ also includes alternate function
| syntax [1], which matches rust's ordering of return
| values.
|
| The reason it was added to C++ is because there were
| actual expressions the old syntax could not unambiguously
| express. Even to a machine the C-style declaration is
| more confusing.
|
| With no offence meant, you're sounding a little
| blub[2]-ish in that complaint.
|
| [0]: http://c-faq.com/decl/spiral.anderson.html
|
| [1]: https://en.wikipedia.org/wiki/C++11#Alternative_func
| tion_syn...
|
| [2]: http://www.paulgraham.com/avg.html
| simias wrote:
| A lot of the syntax was borrowed from C++ for better or
| worse. It does make the transition from C++ a lot easier but
| of course if you're not familiar with the language there'll
| be some friction. Beyond that there are things that Rust
| needs syntax for that simply doesn't exist in many other
| languages such as the Trait-based generics, modules (that
| didn't use to exist in C++) and of course lifetimes.
|
| Beyond that I can't help but feeling that you're following
| this (IMO) counterproductive cargo cult that holds that
| sigils are teh 3v1l and everything should be alphanumeric
| only. Python was at the forefront of this movement but it's
| now very popular. IMO it's completely counterproductive, even
| in Python case. It's form over function. You end up with a
| language where you have to be careful when you refactor
| because indentation becomes significant and no way to scope
| your variables properly. Or a language like JS where somebody
| genuinely thought that having arcane rules to automatically
| insert semicolons was a reasonable idea because "ewwww
| semicolons look ugly". It sure looks good if you want to get
| them tatooed, but in practice at best it's pointless and at
| worst it gets in the way.
|
| I'm all for descriptive variable and function names but the
| core syntax of the language is repeated all over the place
| all the time and benefits from concision. Having Rust spell
| out "function" instead of "fn" wouldn't disambiguate anything
| since you're exposed to it within 5 minutes in the language
| and you'll be super familiar with it very quickly. Having a
| shorthand means that it doesn't pollute the code listing and
| leaves more room for the actually important stuff.
|
| A lot of people like to point out Perl as an example of
| "sigil soup gone wrong" but I'd argue that it's not even the
| real problem here, Perl can become an unreadable mess because
| of all the "magic" it allows, meaning you can write code that
| seems to do absolutely nothing but actually does a whole lot
| (with things like the implied variable $_ for instance). If
| you look at an exhaustive list of Perl operators there are
| only a handful I'd personally consider questionable (like `x`
| and maybe `<=>`. Also some of the quoting q{} qq{} and qx{}
| are really obtuse).
| empath75 wrote:
| i actually really enjoy the syntax and trait system and
| dislike the memory management stuff -- i'd rather have the
| rust syntax in more of a scripting language.
|
| It's a joy to write rust code for the most part.
| vmchale wrote:
| > Every facet of the language feels like an exercise in NIH
| syndrome and it's just too much at once.
|
| Not really, a lot of things are taken from sensible theory
| (e.g. traits and typeclasses).
| skykooler wrote:
| Coming from Python, Rust feels like C++ with a stricter
| compiler. It depends on how you look at it.
| steveklabnik wrote:
| Almost all of these things come from other languages, some
| that have existed for decades. It's probably unfamiliar
| because you haven't run across them yet, which is fine!
| [deleted]
| wrs wrote:
| > an exercise in NIH syndrome
|
| Don't fall into the trap of thinking the entire world is like
| what you can see from where you're standing. It's not really
| "not-invented-here", it's "not-invented-there", where "there"
| is wherever you're used to being. There aren't many
| unprecedented ideas in Rust.
| IshKebab wrote:
| This is really misleading and I wish people would stop but for
| some reason everyone is like "Rust is actually easy! You
| already have to think about borrowing and lifetimes in C/C++ -
| Rust just makes it explicit.".
|
| I love Rust, but that is nonsense. First of all it's a
| reasonable complicated language even without lifetimes and the
| borrow checker, but let's ignore that. My issue with this
| sentiment is that it ignores the fact that the borrow checker
| isn't smart enough to prove that loads of perfectly valid
| programs are valid.
|
| A simple example: `a[0].foo = a[1].foo;`. Perfectly valid. No
| memory errors. But Rust isn't smart enough to know, and so it
| really does make things harder than in C/C++.
|
| This isn't a criticism of Rust at all. I think it is a
| worthwhile tradeoff to get memory safety. I just wish people
| would stop pretending that it isn't a tradeoff at all!
| fpgaminer wrote:
| > 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.
|
| Yeah as you've alluded to Rust _feels_ harder, but is easier if
| one considers the entire effort curve of a project. Rust front
| loads the problem solving so the hard work is at the beginning
| of the project instead of C/C++ with its long tail of debugging
| that takes up 90% of one's effort.
|
| Of course, if you don't know that the hard work at the
| beginning is going to pay off it's hard to commit to it. And
| coders don't know that until they've tried it. It's why I think
| Go is a good stepping stone to Rust.
|
| Go is easier to get into and useful in its own right, but most
| importantly it introduces the concept of "if it compiles, it
| runs" to coders who are used to compilers that fight against
| them (ala C/C++, Java, Python, JavaScript, etc). Once someone
| has a taste for helpful compilers I think it's easier for them
| to swallow Rust. In particular that idea that the borrow
| checker is there to _help_ you and the supposed "difficulty" of
| working with it is more about the compiler being transparent
| with you, instead of the C/C++ way of looking at your broken
| program and just shrugging and going "Okay, if you say so...".
| Terr_ wrote:
| > front loads the problem solving
|
| Indeed, and I think this principle applies to other things,
| like statically-checked type systems. You have to decide
| types early, but it means a huge class of bugs becomes a non-
| issue.
| pjmlp wrote:
| Not only Go, any memory safe with AOT to native code
| toolchains.
| pjmlp wrote:
| 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 wrote:
| 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 wrote:
| 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.
| Thaxll wrote:
| Rust is not equal to C++, not even language wise and
| certainly not from a tool / pipeline / libraries /
| knowledge side.
|
| When you have legacy code, with millions line of code you
| just don't swap for something else for the sake of it might
| be better.
|
| Adding a new language in a medium / large company is not an
| easy task.
|
| I think Rust is a good contender for C++ "replacement" on
| the long term but it's a really difficult task and you need
| proper planning.
| jodrellblank wrote:
| > _for the sake of it might be better._
|
| There are a billion Windows computers on the planet. Each
| time we have a buffer overrun which gives attackers
| access or lets them exfiltrate user data, real people are
| at risk. At risk of ID theft, of money theft, of
| scammers, of crypolockers, of extortion and blackmail, of
| company collapse and job loss, of stolen business
| secrets, of fines, and of wasted time. Each time we have
| an urgent patch, tens of thousands of IT people around
| the world have to hurry to
| patch/bodge/remediate/mitigate/educate systems with
| little warning and little testing, dragged away from
| whatever else they were doing.
|
| Microsoft have proven they can't do this competently in
| C++. Are we not long past the "might be better to have
| tools which check" speculation, and far into "definitely
| definitely definitely is better" by now?
|
| If not by now, what will it take to convince you?
|
| (I'm not saying "Definitely Rust", but something -
| Microsoft make implementations of C++, T-SQL, C#, F#,
| JS/TypeScript, VB.Net, and employ many top Haskell people
| at Microsoft Research, and various other languages, they
| aren't inexperienced at languages).
|
| _it 's a really difficult task and you need proper
| planning._
|
| Then they should hire good developers and plan properly?
| They are one of the richest companies on the planet who
| make some of the most popular programming languages and
| tools on the planet. They're not a poor-me charity case.
| Thaxll wrote:
| Because one issue doesn't mean hurry we need to switch
| language. Especially not on the OS side where unsafe will
| be used and has not yet to be proven that is safer than
| C/C++ with various tools.
|
| If you think that's possible why no-one is actually doing
| it?
| pjmlp wrote:
| Microsoft is fully aware it is reached the tipping point.
|
| https://msrc-blog.microsoft.com/2019/07/18/we-need-a-
| safer-s...
|
| https://msrc-blog.microsoft.com/2019/11/07/using-rust-in-
| win...
| vlovich123 wrote:
| 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.
| HideousKojima wrote:
| It's possible to migrate C to Rust function by function,
| not sure if anyone has figured out something similar for
| C++ yet though:
|
| https://github.com/carols10cents/rust-out-your-c-talk
| steveklabnik wrote:
| There is also https://github.com/immunant/c2rust
| ancarda wrote:
| How about this - every time a problem like this is found, the
| affected component is rewritten in Rust.
|
| Kinda like how a bug should ideally be fixed by reproducing
| the issue with a unit test first - the test ensures that
| particular problem won't come back.
|
| AFAIK that's possible for C - a project can be rewritten in
| Rust one function at a time - but I acknowledge it may not be
| possible or practical for C++ or other languages.
|
| Thing is, there's going to be tons of old C in Windows that
| is perfectly safe. That code doesn't need to be changed - and
| with this model, it wouldn't be. What needs to be changed is
| components like SMB which has been the source of a few high
| profile vulnerabilities before.
| muricula wrote:
| When Rust calls into C code it completely loses almost all
| of its safety guarantees. Having a codebase which is half C
| and half Rust sounds worse to read and reason about than
| all either.
|
| Additionally, most Windows code is C++ with Windows
| specific language extensions (COM, Structured Exception
| Handling, and others).
|
| I think most C++ code should be rewritten in Rust library
| by library, but most software is not properly constructed
| as a series of libraries. And asking a business to rewrite
| working code in a brand new language instead of fixing a
| buffer overflow is a difficult ask.
| pjmlp wrote:
| Microsoft is already had an internal Rust summit,
|
| https://twitter.com/ryan_levick/status/122583705718600089
| 6?s...
|
| and are doing other experiences as well,
|
| https://www.infoq.com/news/2019/11/microsoft-exploring-
| rust-...
|
| https://msrc-blog.microsoft.com/2019/11/07/using-rust-in-
| win...
|
| Kenny Kerr, the original author of C++/Winrt, which
| replaced C++/CX, has now turned into Rust.
|
| https://kennykerr.ca/2020/02/22/rust-winrt-coming-soon/
|
| They are also motivated to actually make C safer, with
| Checked C project, something that ISO C doesn't seem to
| care that much.
|
| https://www.microsoft.com/en-
| us/research/project/checked-c/
|
| As per MSRC advisory, new code should be a mix of .NET,
| Rust or Core Guidelines compliant C++, depending on the
| use case.
| gpderetta wrote:
| I believe 10's of millions might be quite an underestimate.
| pjmlp wrote:
| > Microsoft already tried to migrate bits of userspace to C#
| in 2008 with windows vista, and that didn't exactly go well..
|
| If there was an actual support from WinDev they would have
| managed to pull it off, instead they sabotaged the effort and
| went on redoing those C# classes as COM objects in Vista
| until we got UWP instead.
|
| These kind of reboots do require a change of developer's
| generation to pull it off.
| ksk wrote:
| Why limit developers freedom? If it were so simple with no
| negative consequences, people would be using Rust already.
| JackC wrote:
| > I get it that JavaScript/Python etc... programmers who always
| had a garbage collector might have trouble.
|
| FWIW, as a JS/Python programmer I didn't run into borrow
| checker issues on my most recent Rust foray -- I think it's
| gotten easier over time with stuff like non-lexical lifetimes?
|
| What I did run into was differences in error handling. If
| you're used to exceptions it takes a while to get a feel for
| the variety of idioms that replace them, particularly the
| chains of
| and_then().unwrap_or().map().filter().ok().filter_map() that
| are more familiar for folks coming from pure functional
| languages.
| twic wrote:
| > FWIW, as a JS/Python programmer I didn't run into borrow
| checker issues on my most recent Rust foray -- I think it's
| gotten easier over time with stuff like non-lexical
| lifetimes?
|
| It also varies hugely according to what kind of program
| you're writing. Some programs naturally have borrowcheck-
| friendly structures, others don't.
|
| For example, i wrote a program which processes network
| packets. There is a main loop which reads packets, then
| passes them down a pipeline of filtering, extraction, and
| other processing, eventually sending out more network
| packets. From the compiler's point of view, the pipeline is
| just a series of nested function calls. Each call can safely
| borrow from any of the enclosing scopes. Some of the stages
| are stateful, but they manage their own state, copying data
| to and from the packets. There's nowhere in a program like
| this that you run into a problem with borrowing, it all just
| flows naturally.
| nicoburns wrote:
| > If you're used to exceptions it takes a while to get a feel
| for the variety of idioms that replace them, particularly the
| chains of
| and_then().unwrap_or().map().filter().ok().filter_map() that
| are more familiar for folks coming from pure functional
| languages.
|
| Coming from JS, this felt familiar to me too: It's virtually
| identical to how handling errors in Promise chains works.
| technion wrote:
| I built an Active Directory template to deploy Microsoft's
| mitigation:
|
| https://github.com/technion/DisableSMBCompression
___________________________________________________________________
(page generated 2020-03-11 23:00 UTC)