Languages
Post #5959 · source on Telegram
Safely Unsafe: A Rust Library for Memory Vulnerabilities
Description
A screenshot of the documentation for "cve-rs," a satirical Rust library. The text humorously claims to allow developers to introduce memory vulnerabilities like buffer overflows and segfaults in a "memory safe" way. The page header reads "cve-rs" and the tagline is "Blazingly fast memory vulnerabilities, written in 100% safe Rust." The body of the text explains the "benefits" of being able to corrupt memory in a safe language. The technical joke is layered: it satirizes Rust's obsession with safety by creating a library for intentionally unsafe behavior, ironically claiming it's all safe. It's a deep-cut joke for developers who appreciate Rust's memory safety guarantees and the absurdity of circumventing them
More like this
More like this in Languages →
Use J and K for navigation
Comments
46Comment deleted
This library is perfect for when you need to explain to your C++ colleagues what a memory-safe language is, but in a language they'll finally understand: a segmentation fault
Security wanted a realistic exploit drill but compliance forbade `unsafe`; so I just `cargo add cve-rs` - now we ship use-after-free in 100% safe Rust and Clippy still high-fives the commit
After 20 years of fighting memory corruption bugs, we've finally achieved the impossible: a way to write segfaults that pass the borrow checker. Now your Rust code can have all the excitement of C++ undefined behavior while still compiling with --release and sleeping soundly knowing you never wrote 'unsafe'
Finally, a crate that lets you write Rust code with all the memory safety of C, but with the smug satisfaction of still passing `cargo clippy`. It's like achieving zero-cost abstractions by abstracting away the cost of actually being safe - truly the pinnacle of 'if it compiles, it works' philosophy, now with 100% more segfaults as a feature, not a bug
cve-rs: where Security Theater meets the borrow checker - UB-as-a-Service with #![deny(unsafe_code)] so compliance is happy while prod still gets reproducible segfaults
The borrow checker greenlit this buffer overflow - peak memory-safe architecture
Rewriting in Rust broke our bug‑compatible acceptance tests, so we added cve-rs - now even the segfaults pass without unsafe
lifetime resolution go brrrrrrrrr Comment deleted
https://github.com/Speykious/cve-rs Comment deleted
C could never Comment deleted
C++ doesn't need it. It comes automatically if (user->hasSkillIssue) Comment deleted
but it ain't blazingly 🔥 fast 🚀 and 100% memory safe 💯 Comment deleted
So does it really demonstrate that Rust's safe code is unsafe? There's no joke there? Comment deleted
It demonstrates that rustc has a bug that causes unsound code to be accepted despite that not being the intention. Whether you interpret that as "Rust is unsafe" is your decision Comment deleted
Well even in safest language you still can try your best to shoot your leg with a gun... Comment deleted
I see, you are from "you are holding it wrong" team. Comment deleted
Not really, I'm more from "use it however you want, in the worse case scenario you'll hurt yourself" team Comment deleted
"fuck around and find out" team to be more precise Comment deleted
You have deliberately abuse Rust to get any of these bugs to occur. Comment deleted
i dunno why people make such a fuzz out of cve-rs Comment deleted
https://t.me/utk8g/1968 Comment deleted
Hm? Comment deleted
they are trying to push rust back because they think it is too aggressively imposed Comment deleted
Well, they should probably go shopping for better arguments to use, then Comment deleted
compare your replies to my original question Comment deleted
I have, and I still don’t see why anyone would make a big deal out of it Comment deleted
So does it really demonstrate that Rust's safe code is unsafe? There's no joke there? if you see any "deal" in these words you do not understand language of Shakespeare Comment deleted
well, its no big deal because it doesnt demonstrate that rust's safe code is unsafe Comment deleted
like i said, all it demonstrates is "rustc has a bug" Comment deleted
I actually like rust, but doesn't that mean they failed their 'guarantee'? Comment deleted
why would it Comment deleted
Because of what 'guarantee' means? Comment deleted
if the bar for being able to make claims like that is as high as not having even slight implementation bugs, then nothing that hasnt been formally verified can really claim anything Comment deleted
(that is, assuming the models youre using for your verification aren't themselves flawed) Comment deleted
i feel like it makes sense to take these things in context is this kind of bug particularly unique for community-driver compilers? not really does it indicate a fundamental flaw with the memory safety model, or is it just a mistake on the part of the compiler in enforcing that model? everything seems to point to the latter how easy is it to trigger by mistake? doesn't look like it's something you could just easily stumble upon, but it doesn't seem impossibly hard to trigger, either how much does it detract from the goal of memory safety in an average program? given that it seems to have been very rare in the wild, little to basically not at all to me, all that cve-rs seems to indicate for rust is the basically foregone conclusion that "you can't trust a compiler to not never have bugs", which is not something that was ever being claimed for rustc Comment deleted
There are languages that are designed with handling malicious code in mind. There are languages that impose formal verification and compilers that went through one. Sure, there is still possibility for something to go wrong (insufficient model, hardware not behaving according to spec, etc…) but it's significantly different bar. Comment deleted
Could you name some? Comment deleted
https://github.com/dckc/awesome-ocap?tab=readme-ov-file#programming-languages https://en.m.wikipedia.org/wiki/CompCert https://cakeml.org/ https://www.fstar-lang.org/ Anything working with mobile code, smart contracts, etc. will generally take the "no escape hatches" approach. Also I've always found Ada to be more readable than Rust. Comment deleted
but when you hack your teach brain when he compiles your malicious code in his head is priceless Comment deleted
😄😁👏 Comment deleted
It's like spoon is safe to use by design, but you still can plop your eyes out with it if you want 😁 Comment deleted
nah, it's a legit compiler bug. and yet unfixable due to ongoing refactoring Comment deleted
GCC's and Clang's codegen around floating-point numbers on x86 is fucking unsound and no one bats an eye rustc has a soundness bug no one could possibly accidentally trigger and everyone loses their minds Comment deleted
floating point has some spec. rust lifetime doesn't (yet). but losing they mind due to ability to segfault safely Comment deleted
> floating point has some spec I'm not sure how that's related to codegen bugs in any fashion? > but losing they mind due to ability to segfault safely I mean, that's what soundness bugs do. Almost any soundness bug can lead to a segfault when exploited intentionally, regardless of the language. The original bug doesn't cause a segfault by itself, it has to be used as a primitive to perform a use-after-free to corrupt a pointer. Comment deleted
its a compiler bug, those happen, and rustc is a young compiler. whats the big deal? Comment deleted