Conversation

Notices

1. Embed this notice
   hanno (hanno@mastodon.social)'s status on Tuesday, 02-Apr-2024 13:56:53 JST hanno

   in reply to

   Pretty much everyone develops code using Git these days, or some other SCM (some don't, there's this mail server, but I disgress). But people distribute code in tarballs. How does a Git repo become a tarball? The answer may disturb you. It's basically "every dev has some process, maybe some script, maybe some commands they remember". Nothing is reproducible, nothing is verifiable.

   • Embed this notice
     hanno (hanno@mastodon.social)'s status on Tuesday, 02-Apr-2024 13:56:53 JST hanno

     in reply to

     This creates a situation where even when the "many eyes" principle works, i.e. people are actually looking at the code, and at code changes and commits, you still have a path to a compromised package. Because noone checks how this git repo turns into a tarball. Because noone can, as nothing is standardized or reproducible. I can tell noone does for one of the most important libraries to parse one of the most important data formats, because of the story I just told you.

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     hanno (hanno@mastodon.social)'s status on Tuesday, 02-Apr-2024 13:56:54 JST hanno

     in reply to

     That file was named similar to the other testcases, but it was not used in any test. And if you fed that file into anything using that library, it would either crash or cause enormous CPU spikes. And most interestingly: This file was nowhere to be found in the project's git repository. It was *only* in the tarball.

   • Embed this notice
     hanno (hanno@mastodon.social)'s status on Tuesday, 02-Apr-2024 13:56:54 JST hanno

     in reply to

     I contacted the responsible project, but I never got an answer and never really got to the bottom of this. But here's what I think happened: This was a proof of concept file for a yet unfixed and undisclosed vulnerability. It appears the developer already had a testcase for that bug in his local copy of the source tree. And then created the tarball from that source tree. And by doing that leaked a PoC for a zeroday. FWIW, it was "only" a DoS bug. But still.

   • Embed this notice
     hanno (hanno@mastodon.social)'s status on Tuesday, 02-Apr-2024 13:56:54 JST hanno

     in reply to

     I wanted to disclose this eventually, but then a new version of that library came out and fixed the bug. And plenty of others, and well, people crash parsers for data formats from hell all the time. And I had some concerns that it would sound like I wanted to ridicule the dev, which wasn't my intention at all. But I already thought there's a deeper story here than someone accidentally leaking a PoC for an unfixed vuln. Why can this even happen?

   • Embed this notice
     hanno (hanno@mastodon.social)'s status on Tuesday, 02-Apr-2024 13:56:55 JST hanno

     I have a story to tell that is relevant to the xz-utils thing that just happened. I'll probably write this up properly later, but I'm in pre-vacation mode so it may take a while . We have a problem with the way we develop and then distribute FOSS software, and both stories show that. A while ago I looked at the testcases of a widely used library implementing a widely used data format. There was one file that was... strange. 🧵