5 ms·

Would a 'memory safe' language really have stopped any of this? From what I've briefly read, this incident the whole attack process (PR, fake test data, social

Would a 'memory safe' language really have stopped any of this? From what I've briefly read, this incident the whole attack process (PR, fake test data, social engineering) from start to finish by a state-actor (most likely), could have been in any language.

lifthrasiir 3y ago
You are right, but C/C++ was vulnerable to this particular MO because of its complicated build process.
- uecker 3y ago
  I would say today there is no real need for autoconf anymore in C / C++ and the build process could be fairly easy.
- kukkamario 3y ago
  There are million ways to hide exploits even in "safe" languages. If you have a bad actor that can spend couple years prepping how to hide an exploit, then it doesn't really matter which programming language is used. Build system is complex because of legacy and need to support millions of different platforms and distros.
  - lifthrasiir 3y ago
    Different platforms and distros still share a handful of common environments, while autoconf was invented back when there were hundreds of different environments to care about. Xz doesn't depend that much on the platform and could have ditched autoconf at least in the theory. But such switch is annoying in the world of C/C++.
  - josephg 3y ago
    I'd say there are fewer ways to hide exploits like this. Rust doesn't use configure scripts. And it has a built in testing mechanism - so there's no need for makefiles to run scripts. Any build scripts as complicated as configure in a rust project would be a much bigger red flag. And it would be rare and weird to see GNU_IFUNC in use in a rust project too. Sure; you can hide nasty code in rust. But I think it would have been harder. Not because rust is memory safe. But because rust is decades newer, and it doesn't inherit all of the quirks in C, in its build system and obscure mechanisms for dynamic linking.
- lewis1028282 3y ago
  It's easy to hide things in the Python build process as well. Things like using `getattr` instead of . (dot) etc
bostik 3y ago
> could have been in any language Bingo. This was a highly motivated, targeted, and well planned compromise of the supply chain itself. And funnily enough, using a memory-safe language could have actually made it less likely for this to be detected. There were symptoms showing up prior to the discovery, most prominently Valgrind errors in otherwise unrelated project builds. (ref: https://bugzilla.redhat.com/show_bug.cgi?id=2267598 https://bugzilla.redhat.com/show_bug.cgi?id=2267598)
- dwattttt 3y ago
  The equivalents in memory safe languages raise more eyebrows. Segfault developing on a shared C codebase and it's a day ending with y. Segfault in a language that's meant to not let that happen? Or conversely if a patch turns up that's explicitly doing lots of unsafe things? That gets more scrutiny.
  - bostik 3y ago
    People like to harp on software written in C, and often for very good reasons. A vocal minority of those then whip out their calling card, "should have used Rust!" As a result, there is a sentiment in the peanut gallery that "memory safe language == Rust". You are correct in that a segfault in a project written in memory safe language gets more scrutiny. But imagine for a moment what would have happened if the compiler guaranteed that those Valgrind-caught memory access violations could not have occurred in the first place? We got lucky, and the developers who wrote the actual backdoor were sloppy. They were aiming for sneakiness and evasion first, memory correctness would have likely been an afterthought. The next group tasked with a similar approach will know better.
saati 3y ago
Yes, they used a memory corruption bug to run the payload.
- DrBazza 3y ago
  And if the code submitted used Rust's 'unsafe'?
  - dralley 3y ago
    Then it would be a massive shining "review me harder daddy" beacon
- armitron 3y ago
  You're imagining things, there is no memory corruption mechanism. The payload is delivered into the process address space by dynamic linking through a shared dependency and hijacks a function via GNU_IFUNC.
  - nindalf 3y ago
    Well, Rust doesn’t support dynamic linking. So this particular attack wouldn’t be possible with Rust in March 2024. But it’s a moot point because there are undoubtedly other mechanisms a malicious maintainer could use to inject a vulnerability. Just not this exact one.
    - josephg 3y ago
      Yes, But it would at least be harder. C has so many weird quirks and edge cases - including decades of legacy mechanisms (like IFUNC) that almost nobody today understands. The underhanded C contest would be a lot less entertaining in rust. Thats a good thing. It wouldn't solve the underlying problem permanently. But I don't think there's any slam-dunk solution here. I'll take any small wins where we can get them.
      - steveklabnik 3y ago
moonchild 3y ago
capability safety inhibits supply chain attacks. memory safety is a prerequisite, but it is not sufficient
nindalf 3y ago
Right now they’re worried that somewhere in those 700 commits added by the malicious maintainer there may be some subtle memory safety bug. So great is the difficulty of finding these bugs that they’re planning to discard all work since the commiter became involved, including work by others. Introducing such hidden bugs that are basically impossible to find is much harder in a memory safe, statically linked language.

lifthrasiir 3y ago

You are right, but C/C++ was vulnerable to this particular MO because of its complicated build process.

uecker 3y ago
I would say today there is no real need for autoconf anymore in C / C++ and the build process could be fairly easy.
kukkamario 3y ago
There are million ways to hide exploits even in "safe" languages. If you have a bad actor that can spend couple years prepping how to hide an exploit, then it doesn't really matter which programming language is used. Build system is complex because of legacy and need to support millions of different platforms and distros.
- lifthrasiir 3y ago
  Different platforms and distros still share a handful of common environments, while autoconf was invented back when there were hundreds of different environments to care about. Xz doesn't depend that much on the platform and could have ditched autoconf at least in the theory. But such switch is annoying in the world of C/C++.
- josephg 3y ago
  I'd say there are fewer ways to hide exploits like this. Rust doesn't use configure scripts. And it has a built in testing mechanism - so there's no need for makefiles to run scripts. Any build scripts as complicated as configure in a rust project would be a much bigger red flag. And it would be rare and weird to see GNU_IFUNC in use in a rust project too. Sure; you can hide nasty code in rust. But I think it would have been harder. Not because rust is memory safe. But because rust is decades newer, and it doesn't inherit all of the quirks in C, in its build system and obscure mechanisms for dynamic linking.
lewis1028282 3y ago
It's easy to hide things in the Python build process as well. Things like using `getattr` instead of . (dot) etc

bostik 3y ago

> could have been in any language Bingo. This was a highly motivated, targeted, and well planned compromise of the supply chain itself. And funnily enough, using a memory-safe language could have actually made it less likely for this to be detected. There were symptoms showing up prior to the discovery, most prominently Valgrind errors in otherwise unrelated project builds. (ref: https://bugzilla.redhat.com/show_bug.cgi?id=2267598 https://bugzilla.redhat.com/show_bug.cgi?id=2267598)

dwattttt 3y ago
The equivalents in memory safe languages raise more eyebrows. Segfault developing on a shared C codebase and it's a day ending with y. Segfault in a language that's meant to not let that happen? Or conversely if a patch turns up that's explicitly doing lots of unsafe things? That gets more scrutiny.
- bostik 3y ago
  People like to harp on software written in C, and often for very good reasons. A vocal minority of those then whip out their calling card, "should have used Rust!" As a result, there is a sentiment in the peanut gallery that "memory safe language == Rust". You are correct in that a segfault in a project written in memory safe language gets more scrutiny. But imagine for a moment what would have happened if the compiler guaranteed that those Valgrind-caught memory access violations could not have occurred in the first place? We got lucky, and the developers who wrote the actual backdoor were sloppy. They were aiming for sneakiness and evasion first, memory correctness would have likely been an afterthought. The next group tasked with a similar approach will know better.

saati 3y ago

Yes, they used a memory corruption bug to run the payload.

DrBazza 3y ago
And if the code submitted used Rust's 'unsafe'?
- dralley 3y ago
  Then it would be a massive shining "review me harder daddy" beacon
armitron 3y ago
You're imagining things, there is no memory corruption mechanism. The payload is delivered into the process address space by dynamic linking through a shared dependency and hijacks a function via GNU_IFUNC.
- nindalf 3y ago
  Well, Rust doesn’t support dynamic linking. So this particular attack wouldn’t be possible with Rust in March 2024. But it’s a moot point because there are undoubtedly other mechanisms a malicious maintainer could use to inject a vulnerability. Just not this exact one.
  - josephg 3y ago
    Yes, But it would at least be harder. C has so many weird quirks and edge cases - including decades of legacy mechanisms (like IFUNC) that almost nobody today understands. The underhanded C contest would be a lot less entertaining in rust. Thats a good thing. It wouldn't solve the underlying problem permanently. But I don't think there's any slam-dunk solution here. I'll take any small wins where we can get them.
    - steveklabnik 3y ago

moonchild 3y ago

capability safety inhibits supply chain attacks. memory safety is a prerequisite, but it is not sufficient

nindalf 3y ago

Right now they’re worried that somewhere in those 700 commits added by the malicious maintainer there may be some subtle memory safety bug. So great is the difficulty of finding these bugs that they’re planning to discard all work since the commiter became involved, including work by others. Introducing such hidden bugs that are basically impossible to find is much harder in a memory safe, statically linked language.