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).
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.
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.
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.
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.
> 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.
> 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.
> 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.
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!
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.
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.
> When Rust calls into C code it completely loses almost all of its safety guarantees.
Not really, it means that if there is a memory safety bug it must be either in an unsafe block or foreign C code (which also must be called in an unsafe block). While technically any C code could completely invalidate Rust's memory model, in practice that is almost always a C bug which you can debug more easily if much less of your codebase is in C (or equivalently, unsafe Rust).
> Having a codebase which is half C and half Rust sounds worse to read and reason about than all either.
I think that really depends how it's structured. You would probably want to avoid something like Rust calling C calling Rust calling C (calling Rust calling ... etc), but if the codebase is already separated into modules or even separate libraries you could rewrite a library or module while maintaining the same C API (and that Rust or C module can be read independently from the rest of the codebase).
COM is not windows specific, and it doesn’t require any language extensions. You can implement and consume these objects with GCC on ARM Linux just fine: https://github.com/Const-me/ComLightInterop
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.
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.
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.
Worth pointing out that MS has made extensive investments into making their C++ code bases safe and secure in the last ~twenty years, yet they still regularly have these problems. If Microsoft cannot handle the problem, few organizations would have the resources to.
Also see the recent slew of security issues on OpenBSD, which is developed by what many consider some of the most skilled and careful C programmers.
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?
There are mainstream efforts to do the legwork to allow Linux kernel modules to be written in Rust and a fair few core system libraries (the most obvious example being librsvg) and applications have undergone Rust rewrites. And of course there's Redox OS which a full OS entirely written in Rust, and it only contains a few hundred lines of unsafe code (which, given how Rust works is the only really key code that needs to be audited for memory safety).
The reason that more things aren't yet written in Rust is because these things take time, and there is lots of inertia to switching languages for established projects (one big roadblock to such rewrites is that maintainers need to be familiar enough with Rust).
> yet to be proven that is safer than C/C++ with various tools.
What "various tools"? Buffer overruns were old-hat decades ago. Impossible in Pascal in 1970, impossible in ALGOL-60 years before that. If the C/C++ tools to protect against buffer overruns in 2020 are worse than the technology of sixty years ago, how much longer do you suggest we wait?
> Because one issue
This isn't the first buffer overrun issue. This isn't the first buffer overrun issue in 2020. PHP has had a buffer overflow which could leak data or crash. IBM DB2 has had a buffer overflow which could allow an attacker to gain privileges. macOS and all iPad/WatchOS and iTunes for Windows have had buffer overruns leading to arbitrary code execution. Samsung Galaxy S10 has. QEMU has. pppd has. SQUID has. CA Nimsoft has arbitrary code execution buffer overflow. PHP Multibyte string handling has. Emerson OpenEnterprise SCADA, libmysofa, OpenJPG, mRuby, libMing, Cisco Unified Contact Center, Honor smartphones, QEMU iSCSI handling, Intel Graphics Drivers, Adobe Reader arbitrary code execution (Again!)
> 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.
And now we got this fragments ecosystem of classic bare metal "Win32" apps, WinForms, WPF, UWP, and obviously a handful of 3rd party GUI libraries so vendors can completely redesign their UI so it is a special snowflake.
C# in 2008 was too early. It was still slow and resource hungry since .NET wasn't that optimized, but also PCs were a lot slower. They sold Vista machines with 1GB of RAM back then. half of that was eaten by the system without opening any actual program you wanted to use.
Using rust shouldn't significantly increase resource usage, and nobody is suggesting you go ahead and design yet another UI framework for it. I'm still perfectly fine with win32 apps today.
> And now we got this fragments ecosystem of classic bare metal "Win32" apps, WinForms, WPF, UWP, and obviously a handful of 3rd party GUI libraries so vendors can completely redesign their UI so it is a special snowflake.
What do you know, Microsoft really did embrace Linux, including its design mentality.
That was the thing, if WinDev was serious, they would have contributed to the .NET runtime improvements, like the SIMD support, AOT compilation or value type improvements in C# 7.x that came from Midori experience.
> 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...".
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.
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.
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.
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!
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.
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).
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?
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:
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.
The spiral rule is wrong (or at least overcomplicated). There was once a guy who didn't understand how C declarations work, so he made some guesses, put them on his webpage, and then he still didn't know how declarations work! Too bad this page got so popular.
While you are correct that the spiral rule is an over-complicated (and sadly, popular) rule for C declarations, that doesn't really answer GP's point -- that putting the types after the binding results in much less messy type signatures. This was the reason why Go went with such a setup (and presumably also Python, though their hand was slightly forced by backwards compatibility concerns).
And functions taking and returning function pointers are exceedingly rare. In practice I still find C type syntax the easiest to read (it's so concise, and in fact there is almost no type synax because it's just expressions). The valid argument for me why we should move away from that syntax is tooling - the syntax is hard to parse for machines (but not for humans) because it requires serial reading and complete preprocessing from the start of the file.
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.
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.
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.
> "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.
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.
'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...
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.
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.
You don't even need a type system to eliminate memory unsafety. Show me the memory unsafety in lambda calculus. (and don't forget that, as you said, we're talking about languages, not runtimes)
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).