101–110 of 129 posts
Amazing, this is a life saving feature for C developers. Apparently it's not complete yet? I will apply this to my code once the feature is included on LLVM and GCC. Would be nice if the annotations could also be applied to structure fields. struct bytes { size_t count; unsigned char * __counted_by(count) pointer; }; void work_with(struct bytes);
Clang has this and upcoming GCC will also have this: https://godbolt.org/z/KETrPEnT1
Niklaus Wirth died in 2024, and yet I hope he is having a major I-told-you-so moment about people blaming Pascal's bounds checking to be unneeded and making things slow.
Earlier quoted context omitted.
A service going down is a million times better than being exploited by an attacker. If this is a witch hunt then C is an actual witch.
Why can it be exploited? I’ve configured my OS so my process is isolated to the resources it needs.
Earlier quoted context omitted.
The wider industry data gathered indicates that for memory unsafe languages 80% of issues are due to memory vulnerabilities, including mature codebases like Linux kernel, curl, V8, Chrome, Mach kernel, qemu etc etc etc. This doesn’t mean that logic bugs are less common, it just means that memory safety issues are the easiest way to get access. As for why your experience may be different, my hunch is that either your…
> The wider industry data gathered indicates that for memory unsafe languages 80% of issues are due to memory vulnerabilities, including mature codebases like Linux kernel, curl, V8, Chrome, Mach kernel, qemu etc etc etc. You are misremembering the various reports - the reports were not that 80%[1] of issues were due to memory errors, but more along the lines of 80% of exploits were due to memory errors. You could ha…
For EMV you had C connected directly to the network under a steady stream of attacks and only had an issue once? I find that hard to believe. What’s more likely is a Java websever frontend talking to some C processing / crypto code in which case again you’re less likely to encounter bugs in your code because it’s difficult to find a path to injecting unsanitized input.
For munitions there’s not generally I/O with uncontrolled input so it’s less likely you’d find cases where you didn’t properly sanitize inputs and relied on an untrusted length to access a buffer. As a famous quote states, it’s ok if your code has an uptime of 3 minutes until the first bug if the bomb explodes in 2
Earlier quoted context omitted.
Why can it be exploited? I’ve configured my OS so my process is isolated to the resources it needs.
What language is your OS written in?
Surely your not suggesting that the Rust compiler never produces exploitable code?
Earlier quoted context omitted.
What language is your OS written in?
It’s written in C I’m glad you asked. Do you have any exploits in the Linux process encapsulation to share? Surely your not suggesting that the Rust compiler never produces exploitable code?
If your attitude is that getting exploited doesn’t matter because your software is unprivileged, you need some part of your stack to be unexploitable. That’s a tall order if everything is C.
You can get exploitable code out of any compiler. But you’re far more likely to get it from real-world C than real-world Rust.
Earlier quoted context omitted.
It’s written in C I’m glad you asked. Do you have any exploits in the Linux process encapsulation to share? Surely your not suggesting that the Rust compiler never produces exploitable code?
I probably don’t have such an exploit, since you’re probably running something up to date. There have been many in the past. I doubt the last one to be fixed is the last one to exist. If your attitude is that getting exploited doesn’t matter because your software is unprivileged, you need some part of your stack to be unexploitable. That’s a tall order if everything is C. You can get exploitable code out of any compi…
Kernel level process isolation is extremely robust.
> If your attitude is that getting exploited doesn’t matter because your software is unprivileged
It’s not that exploits doesn’t matter. It’s that process architecture is a stronger form of guarantee than anything provided by a language runtime.
I agree that the place where rust is most beneficial is for programs that must be privileged and that are likely to face attack - such as a web server.
But the idea that you can’t securely use a C program in your stack or that rust magically makes process isolation irrelevant is incorrect.
Earlier quoted context omitted.
I probably don’t have such an exploit, since you’re probably running something up to date. There have been many in the past. I doubt the last one to be fixed is the last one to exist. If your attitude is that getting exploited doesn’t matter because your software is unprivileged, you need some part of your stack to be unexploitable. That’s a tall order if everything is C. You can get exploitable code out of any compi…
> you need some part of your stack to be unexploitable. Kernel level process isolation is extremely robust. > If your attitude is that getting exploited doesn’t matter because your software is unprivileged It’s not that exploits doesn’t matter. It’s that process architecture is a stronger form of guarantee than anything provided by a language runtime. I agree that the place where rust is most beneficial is for progra…
You have a process receiving untrusted, potentially malicious input from the outside. If there’s an exploit then an attacker can potentially take control of the process. Your process is isolated, that’s good. But it can still communicate with other parts of your system. It can make syscalls. Now you’re in the same situation where you have a program receiving untrusted, potentially malicious input from the outside, but now “the outside” is your subverted process, and “a program” is the kernel. The same factors that make your program difficult to secure from exploits if it’s written in C also apply to the kernel.
I’m not sure where those ideas as the end of your comment came from. I certainly didn’t say them.
Earlier quoted context omitted.
> The wider industry data gathered indicates that for memory unsafe languages 80% of issues are due to memory vulnerabilities, including mature codebases like Linux kernel, curl, V8, Chrome, Mach kernel, qemu etc etc etc. You are misremembering the various reports - the reports were not that 80%[1] of issues were due to memory errors, but more along the lines of 80% of exploits were due to memory errors. You could ha…
Sorry, I didn’t misremember but I wrote down without proof checking (see another comment where I got it right). I did indeed mean 80% of security vulnerabilities are caused by memory safety issues. For EMV you had C connected directly to the network under a steady stream of attacks and only had an issue once? I find that hard to believe. What’s more likely is a Java websever frontend talking to some C processing / cr…
EMV terminals. No Java involved.
> As a famous quote states, it’s ok if your code has an uptime of 3 minutes until the first bug if the bomb explodes in 2
Look, first you commented that it's not possible for nontrivial or non-networked devices, now you're trivialising code that, if wrong, directly killed people!
All through the 80s, 90s and 2000s (and even now, believe it or not), the world was filled with millions and millions of devices programmed in C, and yet you did not live a life where all the devices around you routinely crashed.
Crs, Microwaves, security systems... they didn't routinely crash even though they were written in C.
Earlier quoted context omitted.
Still requires a gcc/clang specific extension (although this one I'd be very happy to see standardized)
Only statement expressions, but one can also implement this without them.
I don't use much C but if you add them to the standard they'll probably trickle down to C++ compilers by 2045 and I'll have a good 10 years to use them before I retire.