BoringTun v0.4 Released For CloudFlare's Rust-Based WireGuard

[jacob]

I am aware that but the point I was trying to make is that, the unsafe marker is because in C you don't have a way to verify the safety, that doesn't mean it is automatically insecure, just that the compiler can't make the determination because the C language wasn't built around any strict notions of ownership. However whatever security vulnerability is there isn't caused by the binding, the binding is just the exposure point.

Indeed. The "unsafe" marker means this can't be proven safe, not this is certain to be insecure.

[jacob]

Most security vulnerabilities due to the unsafe { } tags are usually due to this binding with C. There are a number of examples around on how to exhibit (and luckily in many cases mitigate) against it.

If you want to find specific examples, perhaps check out a number of Rust memory checking tools. Here is one from 2021: https://www.micahlerner.com/2021/10/...tem-scale.html

264 memory safety bugs and 76 CVEs.

There is also Miri: https://github.com/rust-lang/miri#bugs-found-by-miri

You could argue that these bugs aren't really Rust's fault. It is where it connects to C that the problem arises. I absolutely agree but it *does* need to connect to C. There is no way around that if you plan to do anything useful with Rust. This unfortunately is a slight weakness of Rust (and every other language that is not C. Even C <-> C++ bindings can be a main source of memory issues if the order of deletion from RAII is not carefully considered).



This potentially demonstrates a slight misunderstanding of how crucial C is to... well everything. Rust can't access anything in POSIX, sys/*.h, sys/socket.h, netinet/in.h or anything like that without going through C. So even though the implementation is pure Rust, there are many, many cases where bindings are needed against C and the underlying system. You can't implement a userland version of wireguard without accessing the TCP stack (API in C)!

The question is, which one is safer?

1) Rust being the safer language but losing type safety "around the edges" of the underlying system
2) C bring a less safe language but keeping type safety and simplicity when interacting with the underlying system

Both remain to be seen. Rust is still relatively young but projects such as BoringTun are the best way to get a feel for which approach is ultimately better.

Of course if a platform could be developed from the ground up in Rust (i.e RedoxOS is very close), then I do believe Rust to be the clear winner. However in mixed environments, everything is so much messier when interweaving different languages.

Actually nothing forces you to rely on POSIX or C APIs. It's perfectly possible to use syscalls directly from Rust rather than calling into a C wrapper lib. I don't know if this version of wireguard does it or not, but the notion that you can't write a Rust program without involving an unsafe {} call into C at some point is simply not true. Of course one could argue that if you call directly into the kernel, that's just another way of calling C.

[RahulSundaram]

To an extent, the fact that so much new code (underlying middleware and frontend GUI applications) is still commonly written in C does suggest that there are some reservations with safer languages vs some of the complexities (i.e bindings) they bring

I don't think there is evidence this is an explicit conscious safety tradeoff people are making at all. Instead the tradeoff I think are elsewhere. There is a lot of legacy ecosystem that won't be shifted quickly no matter what, there is a lot of libraries written in languages like C which are significantly older and there aren't going away anytime soon, there is institutional knowledge, a lot of people will do "wait and see" approach for a couple of decades and so on.

My personal opinion is that the safe language that will come to save us all must be a superset of C rather than a new language entirely that needs bindings but admittedly this is simply an educated guess based on my experience. Perhaps if a tiny C compiler could be bolted onto Rust (similar to Zig and Golang) we might be close.

Superset is a non starter, if you guarantee compatibility with C, you are stuck with all that baggage that brings and you are competing against C++ at that point much more directly and I don't think there is an easy win there, the best you can do is easing the binding generation and reducing the impedance mismatch, it won't ever be perfect but it can be made easier, Zig prioritized that more but Rust isn't far behind on this.

[ssokolow]

No, it's the lack of need. Anyone who doesn't know what a static analyzer is shouldn't make comments about related issues. If the only way you can solve an issue is by rewriting it from scratch in a different language, you better not even touch that product, because you're disqualified immediately. You can write horrible code in any language. I prefer competent programmers over fresh shiny languages. It's not that earlier programming languages were inherently horrible, it's just that programmers are getting less and less competent. Peeps doing 12-hour Udemy courses now call themselves "programmers".

If Microsoft and the Chrome team and the Android team and the iOS and macOS teams and the Linux devs can't shift that ~70% number, and Mozilla estimated that writing Firefox's new CSS engine in Rust has prevented memory-safety bugs that would have amounted to ~70%, then I think this is a No True Scotsman fallacy. If you argue that all it takes is a true C developer, then, by definition, true C developers who can meet the demands of this environment are a myth.

These companies have poured a ton of time, energy, and money into better tooling, better training, and better hiring practices... to the point where Google has released innovative new fuzzing initiatives multiple times, which got reported on here. Over a certain project/team size, nobody can write C or C++ safely.

[ssokolow]

Actually nothing forces you to rely on POSIX or C APIs. It's perfectly possible to use syscalls directly from Rust rather than calling into a C wrapper lib. I don't know if this version of wireguard does it or not, but the notion that you can't write a Rust program without involving an unsafe {} call into C at some point is simply not true. Of course one could argue that if you call directly into the kernel, that's just another way of calling C.

"into C"? Maybe not, but, by definition, the unsafe keyword is required for any FFI or any function where passing the wrong arguments can cause a memory bug. Whether it's C, syscalls, or raw assembly language, you're going to need unsafe at the bottom of the stack at some point.

Also, it's been mentioned before, but you can only do the syscalls directly on Linux. Go had to backpedal on Windows and macOS because their policy on syscall stability is "Our system update broke your binary when it changed the syscalls? Tough luck. We told you to use ntdll/libSystem" and OpenBSD has adopted a security measure which catches syscalls that don't pass through libc and assumes them to be attempted code execution exploits. I don't know how stable the syscalls are on FreeBSD, NetBSD, or DragonflyBSD in practice, but my memory is that they also follow the same "libc is developed in the same repo as the kernel and is effectively part of the kernel that runs in userspace. Syscalls are internal implementation details" approach to ABI stability.

[ultimA]

Anyone who still fails to see the value of rewriting in rust are choosing blindness. The only reason the whole industry isn't migrating to memory-safe languages now that it's possible for pretty much every use-case is the sheer amount of work, not the lack of value. Starting to write new security-critical software in an unsafe language today would be reckless negligence.

It's more complicated than that. Rewriting a non-trivial codebase in a new language is not just a huge time/money investment, but you are also likely going to introduce a lot of new bugs. Rust offers safety for memory and threading, but like any language, no safety against other kinds of logic- and applications bugs or security vulnerabilities in general. And there is no place here for the "70%-study-by-Google" argument that Rust enthusiast often advertise, as that only studies the ratio of memory-related bugs to security bugs, not the ratio to all software bugs, of which there are many-many more.

While it might be a no-brainer to choose a memory-safe language for a new project or when rewriting existing software, whether that must be Rust specifically is not so obvious. Maybe the performance requirements are not so high, so one might choose a language like C#. Or maybe the old project was written in C++, in which case simply modernizing the codebase to new C++-codestyle brings similar advantages as Rust with much less effort, but at the same time with a reduced likelihood of introducing new bugs. In Rust it is also easier to do multi-threading, right, but in reality only a relatively small portion of applications need multi-threading, and even less if we're talking about library code.

As I always say, Rust is a good language with many advantages. But it is foolish to generalize and say anyone who does not choose Rust in any project is blind. Quite often there are other choices too that are just as good in practice for a specific project in question. In reality it must be a case-by-case decision. Don't start any new projects in C though, that's true.

[ssokolow]

Poke. One of my replies is still unapproved.

[sinepgib]

ultimA I fully agree with your post, but I'd like to discuss some parts anyway.

And there is no place here for the "70%-study-by-Google" argument that Rust enthusiast often advertise, as that only studies the ratio of memory-related bugs to security bugs, not the ratio to all software bugs, of which there are many-many more.

I think the cite comes from a mindset of security over functionality (in terms of priorities, obviously). A bug that makes your program crash in some situations would, allegedly, be better than one that exposes credentials. Of course, that's arguable, as losing work is bad as well, nobody stops you from corrupting files "the right way" (e.g. normal calls to write but with the wrong data) and certainly I'd rather not run code that doesn't do its job well enough.

Or maybe the old project was written in C++, in which case simply modernizing the codebase to new C++-codestyle brings similar advantages as Rust with much less effort, but at the same time with a reduced likelihood of introducing new bugs.

You would get partial advantages, but whatever creeps for being C-compatible might still be there. The advantage of not rewriting in Rust also is contingent to this modernization not becoming just another rewrite in C++, which sometimes happen. If you end up rewriting anyway, you should probably go with a memory safe language from the start. And even if you don't, you can make a partial rewrite (it comes with its own complications tho), as the interoperability is quite decent.

In Rust it is also easier to do multi-threading, right, but in reality only a relatively small portion of applications need multi-threading, and even less if we're talking about library code.

Arguably, library code does need to be the safest and quickest possible tho. You don't want your library to be the bottleneck for business logic or the source of bugs. That's why lots of critical libraries end up being written in C, even if used in higher level languages (it gives you the "quickest" part, Rust adds the "safest" part).

But it is foolish to generalize and say anyone who does not choose Rust in any project is blind. Quite often there are other choices too that are just as good in practice for a specific project in question. In reality it must be a case-by-case decision. Don't start any new projects in C though, that's true.

And this is where I agree the most

[jntesteves]

It's more complicated than that. Rewriting a non-trivial codebase in a new language is not just a huge time/money investment, but you are also likely going to introduce a lot of new bugs. Rust offers safety for memory and threading, but like any language, no safety against other kinds of logic- and applications bugs or security vulnerabilities in general. And there is no place here for the "70%-study-by-Google" argument that Rust enthusiast often advertise, as that only studies the ratio of memory-related bugs to security bugs, not the ratio to all software bugs, of which there are many-many more.

While it might be a no-brainer to choose a memory-safe language for a new project or when rewriting existing software, whether that must be Rust specifically is not so obvious. Maybe the performance requirements are not so high, so one might choose a language like C#. Or maybe the old project was written in C++, in which case simply modernizing the codebase to new C++-codestyle brings similar advantages as Rust with much less effort, but at the same time with a reduced likelihood of introducing new bugs. In Rust it is also easier to do multi-threading, right, but in reality only a relatively small portion of applications need multi-threading, and even less if we're talking about library code.

Just to clarify, my original message, that you quoted, agrees with what you just said. It's not advocating specifically rust in any way, only the choice of memory-safe languages for security-critical parts of software. I don't even use rust myself (yet). I took care to choose well my words to try to make that as clear as I could. The only use of the name rust I made was to address specifically the "concern" of the comment I was responding to, since the thread is about rust specifically. But the same apply to anything. Changing to better tooling brings value in itself, that's the high-level argument. The programming language is just a tool to an end.

The hard data that the majority of high-severity security vulnerabilities are memory-related is not something to be ignored. I didn't generalize or misrepresent it. Of course other sources of errors exist and should be part of the consideration, but I do believe that falls under the claim of the amount of work, and hence, time and cost. Rewriting introduces cost, same as refactoring or any other type of rework, and no one disagrees these are valuable when done for the right reasons. "Bug-free" software is simply more costly.

As I always say, Rust is a good language with many advantages. But it is foolish to generalize and say anyone who does not choose Rust in any project is blind. Quite often there are other choices too that are just as good in practice for a specific project in question. In reality it must be a case-by-case decision. Don't start any new projects in C though, that's true.

Since this sentence seems to imply that I said such foolish generalization, specifically about rust, I think it deserves special mention that I've never said anything such. This is a far-fetched misread of my comment.

[ssokolow]

The hard data that the majority of high-severity security vulnerabilities are memory-related is not something to be ignored. I didn't generalize or misrepresent it. Of course other sources of errors exist and should be part of the consideration, but I do believe that falls under the claim of the amount of work, and hence, time and cost. Rewriting introduces cost, same as refactoring or any other type of rework, and no one disagrees these are valuable when done for the right reasons. "Bug-free" software is simply more costly.

Since it's *still* unapproved, the link in my unapproved comment leads to a post named "What science can tell us about C and C++'s security" by Alex Gaynor which links to a lot of said hard data. (I have no idea if vBulletin has any measures to ensure that stuff that stays unapproved for a long time actually gets seen by people when it finally gets approved.)