Rust wont save us, but its ideas will
glitchbyte.io
glitchbyte.io
I think the main problem with the article referenced in the submission is that percentages of vulnerabilities change based on the problem domain. The main threat for web facing services isn’t memory safety but that’s because most web facing services already use memory safe languages like JS, Java/JVM, Python, Ruby, or Go. It’s weird to pick Rust for its memory safety for web services. The reason to pick Rust is because you get C/C++ like performance without the memory safety issues. If you don’t need the perf, all the other languages are better choices because you’ll probably move quicker.
It’s interesting that 20% are still memory vulnerabilities. Assuming this is all the same class of attacks on web services, that means 20% of applications do care about perf and have exploitable memory safety issues. Or the methodology is shoddy and they’re comparing different classes of software. Regardless, the premise of the first article is flawed and rife with statistical analysis problems that paint a misleading picture while the response isn’t infusing me with a lot of confidence on the merits and comes off as unnecessarily fanboish trying to stretch for a reason of “but no rust still makes sense”. 70% of vulnerabilities in Chrome are memory safety. This holds for similar classes of software written in c/C++ (eg Windows). There’s a reason all major c/c++ codebases have started getting grass roots and organizational support to transition away as quickly as possible.
The richer and stricter type system of Rust makes such errors a lot less likely. And if an error escapes, there usually is a way better indication of the origin of the error than just 'None'.
Caml Light, SML, OCaml, Haskell, F#, Scala, and whatever else is out there.
Most of them also come with a REPL, and have multiple toolchains, no need for always be waiting for the compiler.
In particular a strong point of Rust is that C programmers feel comfortable switching to Rust in way that has not happened with other safe languages.
It's much more common to go from C to Python, Go or even Zig, rather than Rust.
I think the C++ to Rust transition is by far the most common one.
I don't see this at all. C++ programmers might be switching, but C programmers aren't reaching for Rust when they need something better than C.
Python well, it isn't as if Rust is on the same level of developer experience and friendliness.
With CPython finally getting a JIT, and Mojo, I don't force that happening long term.
In any case, hardly changes the fact of not being Rust specific type system features not available anywhere else.
Python has the problem that large Python programs are often awkward. There are many reasons for that. And somehow the Python community doesn't seem to be able to solve those issues. Rust is a lot better in that respect.
Weak type checking at interface boundaries allows for all kinds of errors including vulnerabilities.
A famous class of vulnerabilities due to poor type checking is SQL injection.
Using Rust doesn't change how those folks keep concatenating strings.
Lets not forget a competent type system as well. Go/Java are decent, but i'd not even consider dynamic langs these days for any remotely complex project. I just don't believe in the benefits of a dynamic system.
I use Rust in areas that otherwise don't require it in part because i prefer the type system.
Let's start with the first example about IEF: first of all, I think that the security advisory was mostly referring to web APIs that allow users without the necessary permissions to perform actions they shouldn't be able to. If you can already call Java APIs you already have access to the machine so it matters little what visibility the method was declared with. And as somebody else mentioned, the default visibility for Java methods is package-private.
Second example about the URL interception: first of all, you could have `match`ed on the result of `strip_prefix` instead of checking `starts_with` and then `unwrap`ping the result of the former. Second, why not use a URI parsing library? And third: that is not what checking the source of the URL means in this context! I'm assuming there's a way to tell what is the URL currently shown on the webview, and that you should check that before doing an RPC.
The Rust code example shown in the post is functionally identical to the Java version. Also, `&str` doesn't mean the string size is known at compile time, the bounds checks are all performed at runtime.
Third example about path traversal: again, that's functionally the same code as the Java version. What is missing in both is a check that the path is relative to a well-known list of paths and doesn't contain any `..` which could possibly lead to, well, a path traversal vulnerability!
I appreciate the effort that went into the post and I agree that Rust is still better than many other languages out there (because of its API design in many important areas), but man, this ain't it.
There will never be language-level protection against e.g. trusting a URL which you shouldn't trust, or making a function public when it should be private, because languages have to be general enough to trust some URLs and make some functions public. Languages cannot take away the responsibility of the programmer not to do stupid stuff.
When a language (or framework) makes it easy to do the right thing, and hard to do the bad thing, a large category of "stupid stuff" is avoided.
I'm lazy, or tired, or stressed, or focused elsewhere. Make it so, that at these moments I'm forced to run extra miles to "do stupid stuff" and we've avoided several bugs (or code smells and such).
Like you say, that still leaves the domain logic to make mistakes in. But if we could make our mistakes only there, we've eliminated a lot of bugs too: we only have to pay extra close attention in a fraction of our codebase!
Now,we aren't there. Rust isn't, at least. There's still a lot of boilerplate or utility code where I can (and will) do stupid stuff. But rust, with it's proper defaults, secure by defaults, is a lot closer than most other languages. And rusts' emerging frameworks inherit that mindset and help us get closer even.
I don't think Rust offers anything special in this regard however.
Rather I think it is better understanding of the security nuances of particular problem domains that lead to api safety improvements.
Devs today are not particularly better at preventing xss or sqli than they used to be but the default tools they reach for have APIs that make it harder to do the wrong thing.
That's actually a feature in Ur/Web, which is a (very niche) language explicitly built for making web servers. It's sort of a domain-specific language though, so maybe it doesn't count.
> making a function public when it should be private
Nothing's gonna stop a programming mistake like that, but in languages with capabilities[0] you can restrict some functions to only be called when you have certain capabilities, and these capabilities can only be made to be acquired after authenticating a user, for example.
For example, Java has packages and a notion of package private. But that was always a bit of a weak form of modularization. So you end up with a lot of public functions just so some code in a different package can reach it. And while packages are hierarchical, visibility ignores that notion. Java of course has proper modules now. But they are a weak derivative of things like OSGI that while widely used at some point never really went mainstream. Module visibility in OSGI included explicitly defining exposed and required interfaces. If not exposed explicitly, the class loader would prevent you from calling it. Even if it was defined as public.
That kind of mechanisms are still missing in most languages. You kind of get some of this by using micro-services. But routing your function calls over a network is kind of stupid from a performance point of view. It doesn't scale. I've seen some graphql based systems that are a bit challenged on this front. There are other examples of trying to solve this problem outside of the compiler at run/deploy time. A lot of sandboxing used for docker, wasm, etc. is basically about that. But that is kind of mitigating the lack of solutions at the source code level.
OSGI was clunky but it definitely had some interesting ideas. Very sad that that never caught on.
But in reality, omitting Java visibility keyword puts the function into the "default" visibility rules, which is package-private. So, public in the same package, but private when seen from other packages. So the impact is severily limited, depending on the architecture of the application (it's de facto public for applications contained in 1 package).
Still, Rust version is more restrictive, so the point holds, but I think it should be fixed somehow.
Your argument is fair that the "default" state in Rust is more restrictive, but the difference honestly is tiny. In practice, basically all Java code I've seen always explicitly states whether every function is private, public or protected, that's just how you write Java. Should it be compiler-enforced that you always do so? Maybe, but we're really splitting hairs here.
E.g. modern cryptography works, the proof being that the UK wants to change the law to effectively ban it.
We've commoditized e2ee. The next step is to commoditize secure software, so that the baseline effort for any attack is too high for less determined / funded actors. You will still occasionally have to face a stuxnet, but we shouldn't need to face another epidemic of cryptolockers.
You are right that nation states can throw more resources at an attack. All you can do is make attacks as difficult and expensive as possible for an attacker to pull off without detection (commensurate with the value of the assets being protected).
I don't think so. Generally as software becomes more secure the hacks you hear about will become more sophisticated to match, but this does not mean that they are more prevalent.
So perhaps a more accurate statement would be that it is the first practical programming language to implement those ideas?
But what about F* (F-star) for example? That is a language used by Microsoft to write a proven correct network stack used in industry (and Firefox I think). That seems very practical to me.
• They're opt-in instead of opt-out (meaning none of your system libraries or 3rd party dependencies have bothered using them.)
• What's been implemented in practice frequently fails to find bugs in relatively simple toy examples (I often confuse myself wondering why I've failed to turn some new bit of static analysis on, when in fact I have, and it's simply failed to catch even my demonstration bug.)
• The effective tools, on the other hand, tend to have "false" positives as well.
The conclusion I've come to is that to fully solve these problems in C or C++, you'd effectively transform it into a new language. And at that point, you might as well stop pretending that's not exactly what you're doing, and actually create said new language.
---
That said, when stuck using C or C++, static analysis and the compiler-specific half measures that are available are worth using, IMO.
• https://awesomekling.github.io/Catching-use-after-move-bugs-...
• https://clang.llvm.org/docs/ThreadSafetyAnalysis.html
• https://clang.llvm.org/docs/AttributeReference.html#lifetime...
• https://github.com/MaulingMonkey/notes/blob/master/programmi...
• `printf` type checking annotations exist, but don't necessairly work on MSVC. Often sanest to make your legacy logging macros call `printf` in a dead branch to leverage any hardcoded type checking of `printf`
Basically everything is a warning that you might consider cranking up to an error, of course.
That’s true for rust, too, with the difference being that rust won’t compile false positives. I haven’t used rust or recent C++ much, but it wouldn’t surprise me if the false positives that C++ gives had significant overlap with cases where the equivalent rust code would not compile.
- no uninitialized memory
- clone vs copy semantics as part of the type system
- Send, Sync, "fearless concurrency"
- no unchecked indexing
- type safety (you can't just cast things like in C)
- hygienic macros
- namespaces
- pattern matching
- modern build/package systemRust is really high-level when you use it correctly.
And I rarely need lifetime annotations. Which is especially easy if you write in a somewhat functional style.
If you changed the language to support a Rust-like borrow checker, you’d lose back compat which defeats the purpose of stick with C semantics in the first place. There’s the related problem that the borrow checker isn’t automatic. There are places it does good inference, but any structure that has ownership needs to have that owner ship explicitly defined (and often in functions too). That is hard to do when you have to deal with a lot of legacy code that doesn’t have it - while that part can be solved through annotations, things inexpressible in the Rust borrow checker are perfectly legal C so you’d somehow also have to change that code. Additionally the Rust borrow checker can still fail spectacularly on very reasonable code. That’s being addressed in Polonius if that project ever lands, but even then it’s just a step function improvement to solve specific what should be valid code - it doesn’t fix all issues with the borrow checker.
C++ is exploring gradual safeness to provide for optionally strengthening the safety but it’s unclear that approach actually makes sense other than as a balwark to c++ dieing completely (ie the switching cost would be weighed against the cost of fortifying the safety of the code and relying on a poor estimate of the risks involved since there’s too many unknowns)
TLDR: structural, cultural, and back compat issues will prevent anything like the borrow checker.
Maybe in your industry, but not in general.
Dying doesn’t mean that there’s not going to be developers. It just means that it’s no longer growing and the ability to hire developers that have significant c/c++ experience will get harder and harder. It’s still very early days and c/c++ has a lot more legacy code still running than COBOL ever did and COBOL is still alive and kicking in a sense. I would still classify cobol as a largely dead language even though technically people still know it and the code is running.
As for industry, could be. I imagine you think finance but I have a hard time seeing them stick to c/c++ if the rest of tech proper has switched. For new projects, maintenance will be cheaper because of things like cargo crates and other ecosystem niceties that c/c++ will never have. And rust performance is on par with c/C++. So what would be the case for starting any new project in c/C++?
I’m not predicting a timeline. I’m just describing a clear trend. It could easily take 50+ years. Depends on investments by corporations + grass roots + how effective the c++ committee is at stopping the bleeding + whether the rust community does an own goal like trying to standardize the language through ISO which is a huge contributor for why c++ and c will be unable to adjust. But right now rust has a clear velocity and acceleration advantage and has achieved “escape” velocity for when a language will likely take over for another.
It’s not just inertia. Games have very specific latency and timing requirements that required tightly integrated language and compiler features developed for this very purpose. The financial industry too has similar needs and solutions. Rust isn’t a fit for those use cases. Not without a mountain of work that no one is doing, nor would be likely to be accepted as it conflicts with the design goals of Rust.
I think Zig stands the best chance of turning the corner by attacking the problems at the very base of the build system, libc, etc. Doing that opens up the floodgates for experimentation over a new base layer, and that will get you to a 10x change.
Could you elaborate?
Rust's approach is to produce code that is as fast as possible, but with the assumption that safety is paramount over breaking speed records. That's opposite the tradeoff that cutting edge games want to make.
Keep in mind a game engine might make updates to 100,000 objects, 144 times per second. In that context, every nanosecond really does matter.
Investment banks / high frequency traders care a little bit more about safety guarantees. But not as much as you might think. A segfault can cost you a trade, but being 0.5ns slower than the competition will cost you your business.
As for finance, you’re hyper focusing on HFT which is only part of what they use c++ for.
And again, I think you’re being a bit overly dramatic about the overhead Rust imposes or how much “unsafe” is require to recapture the performance.
As for aliasing, you’ve got it backwards. C++ loose aliasing rules means that it can’t enable optimizations that generate better code. Rust’s stricter aliasing rules means they ask llvm to compile with strict aliasing which generates much better code because the compiler can make assumptions that aren’t possible in c++ unless you explicitly force it to (and in those cases safety can be impacted so in practice no one enabled strict-alias in a c++ codebase which we know because llvm has bugs in that code path all over the place that Rust hit and had to fix which it is).
*Unnecessary because the thing being done won't crash the game if it is accidentally interleaved with a different update or whatever, and this is exceedingly unlikely to happen in a repeatable way. At worst you'll get a visual glitch gamers are used to, but often it's something internal and non-visible anyway.
When XBox, Office and Windows business units really do approach Rust support the same way as they embrace C++ over anything else, then Rust is really in the house.
Yes I am aware of Rust/WinRT and the GDI regions kernel module rewrite.
Rust/WinRT is done by the same guys that botched C++/WinRT, no big hopes with that one.
https://www.theregister.com/2024/01/31/microsoft_seeks_rust_...
Reasonable people can disagree but I wouldn’t call that a baby step. Core windows libraries, the NT kernel all being rewritten in Rust. Not sure why 365 stuff is being rewritten from c# to rust but maybe there’s some kind of perf issues that Rust will help them with.
But your bar is also too high. This stuff happens slowly and then all at once. The slow bit is making the infra changes and figuring out how to start the porting process so that other people can start to contribute in a way that’s a positive addition.
On Office side, is yet again Azure infrastructure, which I also referred.
> Around 70% of our high severity security bugs are memory unsafety problems (that is, mistakes with C/C++ pointers). Half of those are use-after-free bugs.
Rust isn't just about cyber security.
[1]: https://www.chromium.org/Home/chromium-security/memory-safet...
My prediction is modern C++, and even (looking at C23) modern C, will be evolved, albeit gradually, to offer enough of Rust's safety so that on a cost-benefit analysis of either updating an existing C or C++ codebase to its modern, safer dialect or rewriting it in Rust, it will be a no-brainer to stick with C or C++. Rust will ultimately become a marginal language, like (sorry) Zig:
Because that built habits. Has large bodies of education and documentation around it, and often even tooling (like snippets, ai completion, linters, static analysis)
When copy paste compatibility to C is available, only regulated industry practices like MISRA force devs to adopt them.
But I've found C to be much easier to reason about. You can inline all the functions and macros and all that's left is a bunch of pointer assignments and arithmetic. C++ has a much more complicated lifetime model which is surprisingly easy to violate. Combined with templates, it becomes really difficult to dig in.
Due to this, C is much more practical to use with formal verification tools like Frama-C and various model checkers.
If Rust had a restricted subset which had a footprint compared to C and allows formal verification (including functional requirements) I would switch right now.
Take a look at "#![no_std]", a Rust feature.
If you do that, your Rust Hello World program will have 14 kiB (with no linker optimizations).
>and allows formal verification (including functional requirements)
See <https://rust-formal-methods.github.io/tools.html>.
Also, the Rust compiler can be used as a library and you can add whatever checks you want like that. See <https://yoric.github.io/post/uom.rs/> for an example (not used that much).
Also, I like <https://docs.rs/pre/latest/pre/attr.pre.html>. It allows you to define and then mandate specifying textual requirements (in addition to the usual conditionals).
$ cat smallhello.c
#include <unistd.h>
int main()
{
char hello[] = "hello, world\n";
write(1, hello, sizeof hello - 1);
return 0;
}
$ diet gcc -Wl,-z,noseparate-code smallhello.c -o smallhello
$ strip smallhello
$ ls -l smallhello
-rwxr-xr-x 1 user user 4864 Feb 9 06:47 smallhello
$ ./smallhello
hello, world
i would argue that this is 'with no linker optimizations' because -z noseparate-code was the default until a few years ago. linker optimizations can save another 200 bytes or so in this case
note that this is without dynamic linking. there's no giant standard library being swept under the rug here. most of the executable code in the resulting program is _start pulling in stackgap, which calls find_in_auxvec, __libc_open, __libc_read, __libc_close, __setup_tls, getenv, strstr, and finally main, and strstr in turn calls memcmp (as does getenv) and strlen. main() itself is only 61 bytes of code, __libc_write is 6 bytes, mostly a tail call to __unified_syscall, which is 34 bytes. so we're already looking at overhead that's 40 times the size of the hello-world code itself, which rust apparently expands to 100 times?
but possibly not; it's easy to accidentally compile something with c that ends up 14 kilobytes too
but basically c's required runtime is just memset() and memcpy(). everything else only gets invoked if you call it explicitly
> but basically c's required runtime is just memset() and memcpy(). everything else only gets invoked if you call it explicitly
Rust is barely more: https://doc.rust-lang.org/stable/core/
> memcpy, memmove, memset, memcmp, bcmp, strlen
> rust_begin_panic
> rust_eh_personality
The main value of C and C++ is in their backward compatibility. Many projects don't even use current versions the languages, and stick to decades-old subsets instead.
There are safety improvements that C++ could do right now, but is unwilling to do. For example, `[]` on vectors could have bounds checks. `->` on empty `std::optional` could trap instead of being UB. Rust accepts performance cost of these things, C++ doesn't want to.
C and C++ move too slowly and are too fragmented and ossified to make a difference in the foreseeable future. They couldn't copy even the easy stuff like Rust's painless dependency management (C++ modules are not going well). Even if a miracle-safety-feature was invented tomorrow, it will take many many years before it goes through cycles of standardization, implementation across vendors, and new compilers being available as a baseline.
Safety improvements won't be a magic compiler flag — C has already deeply invested in analyzers, sanitizers, and fuzzers to improve safety without rewrites. Rust's improvements come from a richer but stricter type system, and that requires refactorings. There are safer C dialects already that have these features, but nobody wants to add lifetime annotations and rewrite their pointer arithmetic to use slices. "Nobody's going to rewrite millions lines of code" applies the same to Safe-C.
But the more Rust-like features they adopt, the easier it will be to automatically convert them to Rust.
C/C++ has DECADES of development with all chances to become good to go ignored. Is CULTURAL.
Look, no even C `if` fall-trough is fixed, and that is probably the easiest thing to fix of all.
Expecting better from them is like expecting fossil fuel companies to be green.
CHERI would stop memory issues being exploited, but it won't make your program work correctly when those same errors are encountered.
exactly how far that can go is a matter of debate (it clearly cannot cover all possible bugs, because people have legitimate disagreements about whether a given operation is a bug or correct) but it can certainly cover the bugs cheri can detect
I guess my only point is that CHERI may protect you from the worst abuse of those bugs, but it still doesn't mean you shouldn't use something that doesn't suffer from them in the first place!
Should we all be using formally verified C that e.g. the aerospace industry uses? It can prevent whole classes of logic bugs that languages like Rust couldn't dream of
My point is much simpler, if you can use something that removes bugs with no appreciable additional effort (or actually less effort), why wouldn't you?