Recent discussion about memory safety of programs and finger-pointing towards C-programmers has gone too wild so I am just taking some little notes.
While one of the inventors of C, Dennis Ritchie, received numerous
awards and the honor of the very same institution - The POTUS - for his achievements (UNIX and C)
its now all void.
I am not neglecting the technical work that is done by CISA that resulted in the White House entering langwars. They do have a point, but as always: it depends!
Did they finger-point Log4Shell that was a devastating cyber pathogen (lol) in a memory-safe language? I am not mentioning all the pwnage that happened due to PHP or how lot of the issues addressed in rustsec are actually memory-issues ...
I am stopping here and are not entering the full discussion about memory-safety, GC, performance, confinements, or full-chain pwnage of the past 50y.
Just giving you a single thing to consider:
You want 0day RCE's in memory-safe languages? Here is one, client side:
Note that the executions come not from the just checked out repo
This also works with cargo check which claims to not build anything. Best with rustup installs but
also works fine with the packages provided by your distributor. The injected DSO is made for Linux x86_64 deployments.
As a professional programmer you know the difference between the build machine and the machine(s) stuff is deployed
on. In professional context they are not the same 99% of the time.
You can have evil code in the repo that you checked out and after the build it would infect your deployment servers.
Thats bad and can happen to any language. You can also have trojan code within the Makefile that would affect your
build hosts. Thats why you skim through it after checkout for sanity. Buildroot for instance is comparing SHA-256
hashes for all the stuff it downloads during the build.
Pwning the build system is pwning the deployment and likely pwning the developer machines too.
Under no circumstances a make should fetch and build recursively and execute anything that it fetches from the untrusted recursion chain. DevOps is a thing. Keep in mind recent liblzma debacle and OpenSSH build scripts would have
automatically downloaded and executed everything recursively.
Mind: Currently there is no way for you to verify the rust dependency chain without getting infected at last:
- There is no dry-run:
cargo checkalready infects you. - If you follow the dep-chain painfully and manually by
git clone, you run into a TOCTOU situation: The code that you checkout by hand might not be the same that is checked out bycargo builddue to finger-printing against the user-agent and selective returns by sophisticated attackers.
I haven't digged into open issues of cargo or rustc or whether this topic has already been discussed.
The version I used was cargo 1.77.0 (3fe68eabf 2024-02-29) which is the latest I got.
It does not even require an evil open-source project to pwn you. It is an open secret that root-CAs are hacked and such certificates are traded on the black market. Sometimes things can even be easier by making laws or issuing warrants that force providers or distributors to include evil CA's.
Either way, this allows for MiM-ing the recursive fetch&build chain at the very end or anywhere in between without even forensicans noticing since the modified checkout would only be delivered to certain selected victims, not the broad masses. Good luck determining what has pwned you 8y ago ...
So the next time someone approaches you about memory safety being the cause of destruction of the world, you can pay back with a balanced view. Not neglecting the validity of some of their arguments.
One personal thing that I can't get over when just compiling rust programs is that it notoriously contacts/downloads
rustup servers and downloads stuff without my consent. Can someone please change that? You wouldn't believe but there is
folks which works offline and just wants to compile this, without being forced to go online and to dl 500MB of binaries
before a single line of code is even translated.