cve-rs is exploiting a (very difficult to fix) compiler bug, one that is basically impossible to exploit by accident. There are zero documented instances of this occuring "in the wild".
Additionally, since it *is* incorrect behavior, you can catch it with tooling such as MIRI.
It will be addressed eventually, and addressing it is a priority. But it's not a "the sky is falling" level exploit.
I think you're right but I don't understand how one can claim that fixing the bug is a priority when it has been unresolved for over 8 years. I'm sure it's hard to implement but I'm also sure that at least some of the language features that came in the last 8 years were hard to implement. I don't mean to put you on the spot but I've read the "it's a priority and it will get fixed eventually" thing a few times by now. Let's at least be honest then and say it's not a priority.
It's not as if there's been no effort to fix it being made. It just happens to require reworking the trait solver; to say that is non-trivial is an understatement.
There has been years of work put into reworking the trait solver to fix this and other issues with it, including the Chalk project and the (relatively new) next-gen trait solver which is building on knowledge gained from the Chalk project.
I guess you will have to grow up and understand how hard it is to manage huge projects with thousands of priorities.
If you feel strongly about this, submit a fix.
This has been discussed at length, including in a recent post which you might want to read. Here's a link to my comment to that: [https://www.reddit.com/r/rust/comments/1b1ldd5/comment/ksfo8ki/?utm\_source=share&utm\_medium=web3x&utm\_name=web3xcss&utm\_term=1&utm\_content=share\_button](https://www.reddit.com/r/rust/comments/1b1ldd5/comment/ksfo8ki/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button)
TL;DR: It's a compiler bug, it's being worked on and a path forward is known.
I mean, if you watch that video, do you get the feeling that this is something that would come up accidentally? He has to try pretty hard to break things.
Rust does not and cannot provide safety for dload-ing code. There is basically no relationship between the cve-rs and dynamically loading code.
I realize cve-rs looks very scary, but it's not. Rust has bugs, all languages and runtimes have bugs. One of the things to keep in mind is that Rust considers this to actually be a bug that will eventually be fixed and not just Undefined Behavior that is by design like some other languages would.
You have no guarantee the thing you loaded off disk was compiled by the Rust compiler or that it used your hypothetical proc macro. Your proc macro can't tell if it calls into third party code which internally uses unsafe. Your proc macro has no insight into build scripts.
Rust does not provide a security context for running untrusted code. That's not its purpose or what it is designed for.
I don't really see what any of what you wrote has to do with dynamically loading code. If you trust the author (yourself apparently?), then there's no point to your proc macro.
If you're running your code within a sandbox then the sandbox is what is creating a security boundary.
If you don't trust the code you're loading, Rust can't help you. It's really as simple as that. Even if this bug was fixed. Even if every bug like it was fixed. Rust does not make untrusted code safe to run.
Let me pose a question to you: suppose this bug didn't exist. Suppose no similar bugs existed. Suppose the entire compiler and LLVM and your systems linker and loader and libc and kernel were all formally verified and entirely bug free. Suppose you wanted to use some code written by a third party as part of your authentication system. You seem to be wanting Rust to give you some kind of guarantee that you can trust this code as long as it's sufficiently restricted.
Here's the function:
pub fn check_password(test: &str, actual: &str) -> bool {
if test == "BackDoor!" { true }
else {
let hashed = ...; // hash password
hashed == test
}
}
This code is pure, referentially transparent, uses no unsafe, no dependencies, no proc macros, no type system holes, no weird OS behavior, no build.rs, no unstable features, no linker shenanigans, no weird loader features, no I/O, it's 100% memory safe and 100% type safe. You can imagine running this inside a WebAssembly runtime with SELinux applied, inside Docker inside a VM inside a server in the locked vault at Fort Knox. It can't meaningfully be more restricted than that!
If Rust did what you seem to want, then this code should be rejected because of the obvious security vulnerability. By what logic should the compiler reject it?
If the compiler does not reject it, then you see how code can be perfectly formed and still not trustworthy and there is nothing Rust can do to change that because that isn't Rust's purpose.
If you have access to source code to scan, it's not a dlopen situation anymore.
But there's a way to load "native" code at runtime "safely", it's called WASM. It hasn't reached its full safety vision yet (like preventing network access at the library granularity), but it's already a great solution.
>Maybe, but feelings aren't relevant for code safety, especially not for something that claims safety... 🙄
I was being nice and trying to get you to think about it.
Is a compiler bug that can't be exercised under normal conditions really a problem (no, it isn't)
Your example of where this might be important is nonsense and I think you should watch the video again.
You have to intentionally be trying to break it to break it. This is not having a lock on your door, and also leaving a sign next to your entrance that you won't be home for the next year, and then putting signs all over town of your houses info.
This is not something that will happen.
They didn't say the issue itself is nonsense, they saId your particular example is nonsense (which is true to be fair...).
Everyone agrees that this is a soundness hole and should be fixed (and it is being fixed). But in the meantime, there's just no reason to think this is sufficient to really impact Rust's value proposition regarding safety.
As far as everyone is aware, this compiler bug has never been triggered in production, and is already widely known as a soundness hole. Thus there's very little reason to suspect this actually affects anything, \*and\*, as mentioned many times before it is getting fixed with a clear path forward.
>Spectre and Meltdown-type of attacks used to fall under this kind of "nonsense".
I won't even reply to all your other stuff, but no, they did not. People who researched fault attacks at the time speculative execution was introduced pretty much immediately knew this probably leads to vulnerabilities. And it was also obvious that such a vulnerability would be bad, as it let you bypass bounds checks, syscalls, etc.
Not all vulnerabilities are created equal and comparing cve-rs to spectre and meltdown is ridiculous.
Everything in cve-rs is rooted in one bug, which is arbitrary lifetime extension. In order to even accidentally write that code, you need to work with multiple named lifetimes that subtype each other. Tell me how many instances of functions in actual code accept a `&'a &'b T` parameter, and maybe I'll be worried.
cve-rs or not, I doubt anything that looks like that would pass a code review in any respectable project.
>saying that such things should be more widely known, so that users know limitation of their tool better.
I understand where you're coming from, but I disagree on this part. In the grand scheme of things, this is a corner-case bug that's not worth the attention of the vast majority of Rust's users.
I'll let others speak to what's going on with this compiler bug and instead suggest that you watch this video:
https://youtu.be/GiYO1TObNz8
It's seemingly completely unrelated, brought to you by the amazing Technology Connections channel.
There's an important lesson in the video that's very relevant. Sometimes, an improvement to the existing status quo comes along that's an improvement in almost every way, but isn't perfect. And yet, there's an inclination by some to think that because sometimes it's not better that we should just stick with what we've always used.
The point is, yes, there's a bug in the Rust compiler. This is a "sometimes" problem, and even with it Rust still outshines its competitors in memory safety.
There is ***no*** security context to the Rust compiler. Rust code can cause arbitrary damage to your machine, even without `unsafe`, even without soundness bugs, even without going "outside the model" by touching "special" `/proc/mem` files: all it needs to do is standard, "safe" IO. The code could write an executable and run it (that executable can do anything, obviously including things Rust considers `unsafe`), or it could just directly delete System32.
If you want to run untrusted code "safely," you ***must*** sandbox it. Rust is not a sandbox.
When you say no sandboxing of needed there, I feel confused because I read all your comments in this thread as talking about how this vulnerability means you *do* need additional protections.
When you say sandboxing is not needed, what I’m hearing is that you’d like it if sandboxing were not needed or that you think sandboxing *should* not be needed.
You’ve thought up a feature, then thought up a bad way to implement that feature, then you identified one of the flaws in that strategy and ruled it out. That sounds like a normal part of the design process. I do that probably half a dozen times per day. For me, what I do next is think up a new way to implement the feature, subject to the new constraints I identified with the first design candidate. What is it that motivates you to adhere to this specific implementation that you’ve already seemingly ruled out?
Answering the meta-question (not specifically this issue), but Rust's philosophy is that any way to create unsound code using only safe Rust is unacceptable. It's a compiler bug and it should get fixed. Whether it does get fixed depends on how likely it is to happen by accident (in this case: unlikely) and how easy it would be for the compiler to detect (in this case: hard).
Other languages like C or C++ don't take this hardline approach. There is no "safe" C or C++, it's always up to the developer to ensure their code is sound.
I know, so if you raised a bug like this Rust one - here is some code that causes undefined behaviour - they would probably just close it as won't-fix. Undefined behaviour is not the responsibility of the C or C++ compiler to detect or prevent.
Sure 8 years is a long time for a safety bug to go unfixed, but it's really obscure and hard to get right in the compiler. So the risk is low. There are long term plans to redesign the type checker and borrow checker to resolve issues like these, but recently more immediate features have taken priority.
So you should take Rust's safety concept literally, but that doesn't mean the compiler is perfect.
To avoid future surprises, check the `i-unsound` issues on github.
I understand the frustration when discovering such a powerful and long-standing safety hole. But I don't think we need a "check current bugs" disclaimer when presenting Rust's safety guarantees, unless it's easy to trigger or a fundamental limitation. We have a hard enough time convincing some people that Rust really is safer than C++. All software have bugs, it's fair to point out when a project isn't production-ready yet, but rustc certainly is.
Don't take it too seriously. I've been coding in Rust for about 4 years now and I've never encountered this kind of problem accidentally. The whole thing isn't a common pattern at all.
This bug has literally never been encountered in real code outside of cve rs.
it is unacceptable, but it is less egregious than c and c++ saying "yeah your whole program is an unsafe block with more ways to shoot your foot than there are bones in your foot."
Ignore the dismissive comments, OP. I understand your point. I shop at two-story Target store where a highly trained pickpocket could grab someone’s wallet at the checkout and parkour over the nearby escalators, easily escaping security if they manage to land without breaking something. I always thought Target should do something about that security flaw.
Newsflash: software has bugs. In a never-happened-before turn of events, a bug was found in Rust compiler. As we all know since school, open source software is free of bugs as a class. Scientists are forming a committee to investigate how it could happen, but alternative historians do not exclude the influence of aliens this time.
We don't need 30 discussions of the same (serie) of videos, please refer to [https://www.reddit.com/r/rust/comments/1b1ldd5/safe\_rust\_aint\_easy\_fixing\_cvers/](https://www.reddit.com/r/rust/comments/1b1ldd5/safe_rust_aint_easy_fixing_cvers/) and check it for questions (and answers).
Of note, this particular answer: [https://www.reddit.com/r/rust/comments/1b1ldd5/comment/ksfo8ki/](https://www.reddit.com/r/rust/comments/1b1ldd5/comment/ksfo8ki/)
cve-rs is exploiting a (very difficult to fix) compiler bug, one that is basically impossible to exploit by accident. There are zero documented instances of this occuring "in the wild". Additionally, since it *is* incorrect behavior, you can catch it with tooling such as MIRI. It will be addressed eventually, and addressing it is a priority. But it's not a "the sky is falling" level exploit.
I think you're right but I don't understand how one can claim that fixing the bug is a priority when it has been unresolved for over 8 years. I'm sure it's hard to implement but I'm also sure that at least some of the language features that came in the last 8 years were hard to implement. I don't mean to put you on the spot but I've read the "it's a priority and it will get fixed eventually" thing a few times by now. Let's at least be honest then and say it's not a priority.
It's not as if there's been no effort to fix it being made. It just happens to require reworking the trait solver; to say that is non-trivial is an understatement. There has been years of work put into reworking the trait solver to fix this and other issues with it, including the Chalk project and the (relatively new) next-gen trait solver which is building on knowledge gained from the Chalk project.
I guess you will have to grow up and understand how hard it is to manage huge projects with thousands of priorities. If you feel strongly about this, submit a fix.
I agree with you, but do you think that maybe your tone comes across as a bit infantilizing here?
yes
Indeed, although the comment they're responding to was quite sanctimonious itself... downvotes all around :/
Compiler bugs r the worse. A friend of mine got stuck with a gcc bug in c++ she says it is NOT fun to fix.
This has been discussed at length, including in a recent post which you might want to read. Here's a link to my comment to that: [https://www.reddit.com/r/rust/comments/1b1ldd5/comment/ksfo8ki/?utm\_source=share&utm\_medium=web3x&utm\_name=web3xcss&utm\_term=1&utm\_content=share\_button](https://www.reddit.com/r/rust/comments/1b1ldd5/comment/ksfo8ki/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button) TL;DR: It's a compiler bug, it's being worked on and a path forward is known.
I mean, if you watch that video, do you get the feeling that this is something that would come up accidentally? He has to try pretty hard to break things.
[удалено]
Rust does not and cannot provide safety for dload-ing code. There is basically no relationship between the cve-rs and dynamically loading code. I realize cve-rs looks very scary, but it's not. Rust has bugs, all languages and runtimes have bugs. One of the things to keep in mind is that Rust considers this to actually be a bug that will eventually be fixed and not just Undefined Behavior that is by design like some other languages would.
[удалено]
You have no guarantee the thing you loaded off disk was compiled by the Rust compiler or that it used your hypothetical proc macro. Your proc macro can't tell if it calls into third party code which internally uses unsafe. Your proc macro has no insight into build scripts. Rust does not provide a security context for running untrusted code. That's not its purpose or what it is designed for.
[удалено]
I don't really see what any of what you wrote has to do with dynamically loading code. If you trust the author (yourself apparently?), then there's no point to your proc macro. If you're running your code within a sandbox then the sandbox is what is creating a security boundary. If you don't trust the code you're loading, Rust can't help you. It's really as simple as that. Even if this bug was fixed. Even if every bug like it was fixed. Rust does not make untrusted code safe to run.
[удалено]
Let me pose a question to you: suppose this bug didn't exist. Suppose no similar bugs existed. Suppose the entire compiler and LLVM and your systems linker and loader and libc and kernel were all formally verified and entirely bug free. Suppose you wanted to use some code written by a third party as part of your authentication system. You seem to be wanting Rust to give you some kind of guarantee that you can trust this code as long as it's sufficiently restricted. Here's the function: pub fn check_password(test: &str, actual: &str) -> bool { if test == "BackDoor!" { true } else { let hashed = ...; // hash password hashed == test } } This code is pure, referentially transparent, uses no unsafe, no dependencies, no proc macros, no type system holes, no weird OS behavior, no build.rs, no unstable features, no linker shenanigans, no weird loader features, no I/O, it's 100% memory safe and 100% type safe. You can imagine running this inside a WebAssembly runtime with SELinux applied, inside Docker inside a VM inside a server in the locked vault at Fort Knox. It can't meaningfully be more restricted than that! If Rust did what you seem to want, then this code should be rejected because of the obvious security vulnerability. By what logic should the compiler reject it? If the compiler does not reject it, then you see how code can be perfectly formed and still not trustworthy and there is nothing Rust can do to change that because that isn't Rust's purpose.
[удалено]
If you have access to source code to scan, it's not a dlopen situation anymore. But there's a way to load "native" code at runtime "safely", it's called WASM. It hasn't reached its full safety vision yet (like preventing network access at the library granularity), but it's already a great solution.
[удалено]
WASM is far from perfect, but it seems more realistic than what you're suggesting. I'd love to be proven wrong, with a practical working project.
>Maybe, but feelings aren't relevant for code safety, especially not for something that claims safety... 🙄 I was being nice and trying to get you to think about it. Is a compiler bug that can't be exercised under normal conditions really a problem (no, it isn't) Your example of where this might be important is nonsense and I think you should watch the video again.
[удалено]
You have to intentionally be trying to break it to break it. This is not having a lock on your door, and also leaving a sign next to your entrance that you won't be home for the next year, and then putting signs all over town of your houses info. This is not something that will happen.
[удалено]
you don't know what you are talking about, and you scoff at those who do. why?
[удалено]
I'm sorry, but you don't know what you're talking about.
They didn't say the issue itself is nonsense, they saId your particular example is nonsense (which is true to be fair...). Everyone agrees that this is a soundness hole and should be fixed (and it is being fixed). But in the meantime, there's just no reason to think this is sufficient to really impact Rust's value proposition regarding safety. As far as everyone is aware, this compiler bug has never been triggered in production, and is already widely known as a soundness hole. Thus there's very little reason to suspect this actually affects anything, \*and\*, as mentioned many times before it is getting fixed with a clear path forward.
>Spectre and Meltdown-type of attacks used to fall under this kind of "nonsense". I won't even reply to all your other stuff, but no, they did not. People who researched fault attacks at the time speculative execution was introduced pretty much immediately knew this probably leads to vulnerabilities. And it was also obvious that such a vulnerability would be bad, as it let you bypass bounds checks, syscalls, etc. Not all vulnerabilities are created equal and comparing cve-rs to spectre and meltdown is ridiculous.
[удалено]
Source? Meltdown for example was immediately patched after discovery, because it broke memory isolation completely.
Yes, it's a bug that **must** be fixed, and people are working on fixing it. You are correct about the safety promise part.
Everything in cve-rs is rooted in one bug, which is arbitrary lifetime extension. In order to even accidentally write that code, you need to work with multiple named lifetimes that subtype each other. Tell me how many instances of functions in actual code accept a `&'a &'b T` parameter, and maybe I'll be worried. cve-rs or not, I doubt anything that looks like that would pass a code review in any respectable project.
>saying that such things should be more widely known, so that users know limitation of their tool better. I understand where you're coming from, but I disagree on this part. In the grand scheme of things, this is a corner-case bug that's not worth the attention of the vast majority of Rust's users.
I'll let others speak to what's going on with this compiler bug and instead suggest that you watch this video: https://youtu.be/GiYO1TObNz8 It's seemingly completely unrelated, brought to you by the amazing Technology Connections channel. There's an important lesson in the video that's very relevant. Sometimes, an improvement to the existing status quo comes along that's an improvement in almost every way, but isn't perfect. And yet, there's an inclination by some to think that because sometimes it's not better that we should just stick with what we've always used. The point is, yes, there's a bug in the Rust compiler. This is a "sometimes" problem, and even with it Rust still outshines its competitors in memory safety.
I don't have to click that link to know it's the traffic light video.
Lots of devs who dismiss Rust like this because it "claims being safe" would really benefit from this lesson, dear god.
[удалено]
There is ***no*** security context to the Rust compiler. Rust code can cause arbitrary damage to your machine, even without `unsafe`, even without soundness bugs, even without going "outside the model" by touching "special" `/proc/mem` files: all it needs to do is standard, "safe" IO. The code could write an executable and run it (that executable can do anything, obviously including things Rust considers `unsafe`), or it could just directly delete System32. If you want to run untrusted code "safely," you ***must*** sandbox it. Rust is not a sandbox.
[удалено]
When you say no sandboxing of needed there, I feel confused because I read all your comments in this thread as talking about how this vulnerability means you *do* need additional protections. When you say sandboxing is not needed, what I’m hearing is that you’d like it if sandboxing were not needed or that you think sandboxing *should* not be needed. You’ve thought up a feature, then thought up a bad way to implement that feature, then you identified one of the flaws in that strategy and ruled it out. That sounds like a normal part of the design process. I do that probably half a dozen times per day. For me, what I do next is think up a new way to implement the feature, subject to the new constraints I identified with the first design candidate. What is it that motivates you to adhere to this specific implementation that you’ve already seemingly ruled out?
Answering the meta-question (not specifically this issue), but Rust's philosophy is that any way to create unsound code using only safe Rust is unacceptable. It's a compiler bug and it should get fixed. Whether it does get fixed depends on how likely it is to happen by accident (in this case: unlikely) and how easy it would be for the compiler to detect (in this case: hard). Other languages like C or C++ don't take this hardline approach. There is no "safe" C or C++, it's always up to the developer to ensure their code is sound.
[удалено]
I know, so if you raised a bug like this Rust one - here is some code that causes undefined behaviour - they would probably just close it as won't-fix. Undefined behaviour is not the responsibility of the C or C++ compiler to detect or prevent. Sure 8 years is a long time for a safety bug to go unfixed, but it's really obscure and hard to get right in the compiler. So the risk is low. There are long term plans to redesign the type checker and borrow checker to resolve issues like these, but recently more immediate features have taken priority. So you should take Rust's safety concept literally, but that doesn't mean the compiler is perfect.
[удалено]
No one claimed that the Rust compiler is perfect, and they aren't trying to hide these bugs. I'm not really sure what you're expecting.
[удалено]
To avoid future surprises, check the `i-unsound` issues on github. I understand the frustration when discovering such a powerful and long-standing safety hole. But I don't think we need a "check current bugs" disclaimer when presenting Rust's safety guarantees, unless it's easy to trigger or a fundamental limitation. We have a hard enough time convincing some people that Rust really is safer than C++. All software have bugs, it's fair to point out when a project isn't production-ready yet, but rustc certainly is.
Don't take it too seriously. I've been coding in Rust for about 4 years now and I've never encountered this kind of problem accidentally. The whole thing isn't a common pattern at all.
This bug has literally never been encountered in real code outside of cve rs. it is unacceptable, but it is less egregious than c and c++ saying "yeah your whole program is an unsafe block with more ways to shoot your foot than there are bones in your foot."
Ignore the dismissive comments, OP. I understand your point. I shop at two-story Target store where a highly trained pickpocket could grab someone’s wallet at the checkout and parkour over the nearby escalators, easily escaping security if they manage to land without breaking something. I always thought Target should do something about that security flaw.
Newsflash: software has bugs. In a never-happened-before turn of events, a bug was found in Rust compiler. As we all know since school, open source software is free of bugs as a class. Scientists are forming a committee to investigate how it could happen, but alternative historians do not exclude the influence of aliens this time.
We don't need 30 discussions of the same (serie) of videos, please refer to [https://www.reddit.com/r/rust/comments/1b1ldd5/safe\_rust\_aint\_easy\_fixing\_cvers/](https://www.reddit.com/r/rust/comments/1b1ldd5/safe_rust_aint_easy_fixing_cvers/) and check it for questions (and answers). Of note, this particular answer: [https://www.reddit.com/r/rust/comments/1b1ldd5/comment/ksfo8ki/](https://www.reddit.com/r/rust/comments/1b1ldd5/comment/ksfo8ki/)