Originally posted by RahulSundaram
View Post
Announcement
Collapse
No announcement yet.
BoringTun v0.4 Released For CloudFlare's Rust-Based WireGuard
Collapse
X
-
Originally posted by kpedersen View Post
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.
Comment
-
Originally posted by kpedersen View PostTo 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
Originally posted by kpedersen View PostMy 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.
- Likes 4
Comment
-
Originally posted by anarki2 View Post
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".
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.
- Likes 1
Comment
-
Originally posted by jacob View Post
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.
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.
- Likes 1
Comment
-
Originally posted by jntesteves View PostAnyone 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.
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.Last edited by ultimA; 09 March 2022, 09:11 AM.
- Likes 2
Comment
-
ultimA I fully agree with your post, but I'd like to discuss some parts anyway.
Originally posted by ultimA View PostAnd 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.
Originally posted by ultimA View PostOr 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.
Originally posted by ultimA View PostIn 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.
Originally posted by ultimA View PostBut 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.
Comment
-
Originally posted by ultimA View PostIt'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.
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.
Originally posted by ultimA View PostAs 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.
- Likes 1
Comment
-
Originally posted by jntesteves View PostThe 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.
- Likes 1
Comment
Comment