daniel:// stenberg://Mar 30, 2024
In an almost spooky coincidence I wrote about backdooring #curl exactly on this day three years ago: https://daniel.haxx.se/blog/2021/03/30/howto-backdoor-curl/
HOWTO backdoor curl | daniel.haxx.se

Show threaddaniel:// stenberg://Mar 30, 2024

"If the attacker instead can just sneak the code directly into a release archive then it won’t appear in git, it won’t get tested and it won’t get easily noticed by team members!"

... like... xz.

Show threadmid_kidMar 30, 2024
@bagder I really consider this xz situation a testament to the resilience of the open source community, and distros in particular. The damage did happen, but it was discovered rather quickly, despite how ridiculously sophisticated the attacker was, and the fallout was really contained to just "run an update asap". It didn't even land in most systems thanks to the stabilization process. It can't and won't linger for years like log4j did.
Show threadNoratrieb
@mid_kid @bagder While everyone involved definitely did great work and deserves praise, I think it's a bit dangerous to say it like this. I consider it really lucky that this was discovered this early. It wasn't just some person doing regular code auditing, it was someone investigating bad performance. The next attacker will definitely performance test their exploit. What then?
Mar 30, 2024 at 9:09amWeb
Show threadmid_kidMar 30, 2024
@nilstrieb @bagder The attacker had to weaken tests in google's oss-fuzz as well as fix valgrind warnings in downstream distribution testing that almost got him caught. In the end he got caught due to the performance issues, but I also think there's other behaviors and incompatibilities that would've cropped up in downstream testing. But you're right, an attacker can make sure it has no performance issues, so the open source world needs to find a way to make it more difficult next time.