I was idly wondering about this the other day (maybe php prompted it). Making release tarballs should become a reproducible process too [1]. That avoids the "hack the releaser's dev machine" attack if you verify elsewhere, or avoids the "hack the CI pipeline" if you verify on your dev machine.
My personal approach is to read the line by line diff against the last (gpg signed) release, useful too just to be reminded of everything that has changed. Not perfect, but will catch some things.
A supply chain attack to get a backdoor into curl wouldn't involve any of the methods he describes in his blog post, it would involve putting the backdoor into one of the dependencies that curl uses such that when curl is compiled using the tainted lib, you end up with a backdoored curl.
The blog post assumes that curl wouldn't be the primary target (fair, almost no end-user uses curl directly), which would make an attack on curl a supply chain attack.
I sometimes think about those kinds of security problems, anf I think he underestimates how easy it is to make any machine infection persistent
> But such an attacker would not only have to breach my development machine, such an infection of the release scripts would be awfully hard to pull through. [...] I of course do my best to maintain proper login sanitation, updated operating systems and use of safe passwords and encrypted communications everywhere.
1. Get the local user exploit at the machine. This is the hardest part, and requires most luck. But let’s say it happened for some reason.
2. Install malicious sudo and get root access. Clean up right away once you have it, because malicious sudo is a huge red flag.
3. Install a subtle exploit to persist on system. Try to avoid modifying existing binary files - maybe add .so file into unusual location, or add a fake plugin into a package.
4. Backdoor so file used by release tool. Maybe tar or sed or something like this. It will be trivial to add a caller check and invoke evil payload if we are inside the release script.
The scary part is how is it is to permanently persist on a modern machine. I can easily come up with half a dozen methods which no automated tool will detect, and which would be tough to spot by manual inspection.
Our developer machines are infinitely more vulnerable than those cloud servers we are working hard to secure. One mistake is all it takes. I probably don’t have to worry about it because no one cares very much about the stuff I do, but this is a very scary thought. Makes me wish I used ostree or fuix or some other system where I at least have a chance of spotting the backdoors.
> Another way could be for the attacker to breach the origin download server and replace one of the tarballs there with an infected version, and hope that people skip verifying the signature when they download it
that's a reasonable hope, tbh, I mean, how many FOSS projects recommend installation by curling a script direct into sh?
But he goes on to raise a good point, that someone more security minded will likely notice it sooner rather than later:
> Most people download the latest release, and then it’s enough if a subset checks the signature for the attack to get revealed sooner rather than later.
May the developer can also monitor the download server and verify the sig with a cron. That will decrease the timeframe for a successful attack. Good idea?
"For all of us who sign our git commits, detecting such a forged commit is easy and quickly done. In the curl project we don’t have mandatory signed commits..."
This gives me the impression that some people on the team sign their commits, but not all. As this is a team that is clearly takes security very seriously, I am interested in learning how the cost/benefit case works out for this particular feature/burden.
Original post has a comment by a possible 'black hat' who claims to have sold a cURL exploit [1]:
>[ZERO_DAYS_4_EVA] LMFAO, $100 isn’t much of a reward, especially since we sold a curl exploit to a third-party broker for much, much, MUCH more than that a few months ago. This exploit has survived multiple patches and your OSS fuzzer because the code isn’t being actively fuzzed.
OpenBSD: These are reasons I decided it was worth learning to use it, and change parts of my tech stack in the process, to favor things that come with it in the base. It took a lot of time (still does, as I still have much to learn), so it is debatable. But it makes me think I at least eliminated very many of the attack vectors (not all, and not hardware).
Only 2 remote holes in the default install, since I think ~ 1996. Amazing. Then when you install more software from the ports/packages system you can consider their security implications. But don't expect peripherals to always work perfectly without work, or some, at all, and choose hardware that will do what you need compatibly with the system. And do expect to read documentation and learn something about the culture.
It is interesting how different systems and languages have different priorities. Here is my current understanding:
openbsd: security, correctness, portability.
freebsd: stability, performance (speed).
gnu/linux (example: debian): stability of userspace, features & compatibility, developer convenience, speed.
netbsd: portability, enjoyment, inclusivity?
All of those: Freedom/openness (usually).
MS/Apple: legal duty to shareholders, customer convenience and attachment.
Etc. Others will have other views of course, especially in the details.
Can I just say that I love how transparent Daniel is about curl's security status? I have never gotten good at using curl, nor have I ever used libcurl, but I am tempted to put some time into it, just because of that transparency.
I think the first option (backdoor patch) is actually the most likely for a dedicated state actor - especially since it needs to pass all the CI tests anyway.
And given large amount of resources you’d be adding something that would only trigger when combined with something else on the target machine (think Stuxnet).
My personal approach is to read the line by line diff against the last (gpg signed) release, useful too just to be reminded of everything that has changed. Not perfect, but will catch some things.
[1] https://reproducible-builds.org/docs/archives/