I was a successful and happy user of acme.sh for perhaps two years ... and then the RCE was discovered and I stopped using it immediately.
I am now revisiting a LE implementation on a new system and looking for a replacement for acme.sh and I am surprised to see that people continue to use acme.sh but further acme.sh is prominently featured on the LE client page:
I don't understand this - why is it reasonable to re-adopt acme.sh given an honest-to-god RCE in their code ?
Discovery of an RCE is a reason to be vigilant, and is certainly a factor to consider when choosing software. It's not necessarily a reason to instantly distrust and shun an entire software project.
If folks would like to continue discussing this topic, please keep our Code of Conduct in mind. Criticism (whether of a project, or of other criticism) should be reasonable and constructive.
This is very well said, thank you. While it'd be great if all code was free of bugs, especially severe security bugs, in practice software engineering isn't that great yet.
I haven't seen any indication that the maintainers of acme.sh intentionally placed or intentionally left in place the recent RCE bug, and my understanding is that it was fixed and a new version released pretty quickly as soon as it was discovered.
I certainly can see why one would want to hesitate to use them, and perhaps would hesitate to use any shell-script-based implementation that might have those kinds of bugs in them, but I also don't see a reason for a one-strike-and-you're-out policy. I suspect that whatever OS or browser you're using has had at least as many severe security bugs in it that were similarly patched once discovered.
This would be absolute news to me. I haven't heard or seen indication that the bug was introduced intentionally. (And if this would be the case and would be known, it would indeed be a reason no longer to trust acme.sh.)
The RCE bug was used intentionally by some "CA" (instead of reporting it to get it fixed), but as soon as this became known the bug got fixed by the acme.sh authors.
Yes, that's my impression as well. The GitHub issue has a lot of cross-talk about the way the issue was exploited, which can be confusing to read, but neither the discussion nor the code made me suspicious.
My believe is that it was a genuine, unintentional bug and a CA, unrelated to acme.sh, abused the bug to bypass some kind of restriction.
While you can never really know for sure, I believe it's in the realm of a conspiracy theory to think the bug was put there intentionally, even if I'm not a fan of the client in the first place. There are no clues leading into that direction.
For the truly paranoid:
There should be a separation of duties between obtaining certs and using certs.
Where one never runs any such un-audited code outside of a "sandbox / DMZ".
OR
You take the time to:
download the source code
review it (line by line) for anything suspicious
[while also ensuring it can't auto-update itself]
I admit that I never looked too deeply into the issue and just immediately discontinued my acme.sh toolchain at the first sign of trouble ...
My impression based on initial discussions on reddit and HN was that what happened was deeply suspicious and a lot of - as you say - conspiracy theories were floated.
So, may I try to summarize and, please, let me know if I have this correct:
There was a shell coding error in acme.sh that sat undetected for months/years
An unrelated third party appears to have discovered that coding error and set up a workflow that resulted in RCE when acme.sh was used with that specific cert provider.
If I was not using that specific cert provider, the RCE never occurred for me - even though I was running acme.sh
I skimmed the GitHub issue when it first came out. My takeaway is it's really hard to sanitize inputs with shell scripts. Acme.sh wouldn't be my first choice due to it's language, but it may be the only option for certain systems. It's also darn near universally compatible.
That would be correct, my understanding is that HiCA is the only one that discovered the bug. And as soon as they started using it it was patched. Acme.sh uses ZeroSSL by default.
Thank you - that was the key issue for me: the RCE never occurred unless the user went out of their way to use that specific cert provider. That is very reassuring and, in fact, I only ever used the default.
Going off-topic a bit but ... I was wondering, can I just do the entire process manually with properly crafted 'openssh' commands on the command line ?
I guess the openssh commands are the easy part and it is the submission and retrieval from the CA (using curl ?) that makes things complicated ...
But to satisfy my curiousity, is there a step-by-step fully manual howto anywhere ?
Well, in theory I suppose someone else could have exploited it as well that hasn't been publicized. But yes, you would need to have gone out of your way to select an ACME server that exploited it. It required connecting to a hostile server, it wasn't something just listening on your network for commands or anything like that.
I think that sort of thing may just be how the shell-script-based clients got started. Using the ACME protocol isn't trivial. Any sort of manual workflow would require some software that knows how to speak the ACME protocol, including creating JWT signatures and such. I suppose it's possible, but you'd probably end up with something that's just as complex and depends on assuming that the commands you'd be given are correct and not exploitable in the same sort of way.
If you're looking for a client that's just "copy onto a server with minimal dependencies", you might want to look at lego or something else written in Go. I think might have the ease-of-deployment of a shell script without worrying quite as much about if the author knows how to escape arguments properly.
Leaving aside the discussion of the exploit, how do you see that this is the case? acme.sh is listed among the Bash clients (which appear to be in random order). It's the first section, which is because the clients are listed alphabetically by implementation language or environment. But acme.sh isn't called out or featured in any way; it's just one of the clients in the list. And AFAIK, that list includes all known, publicly-available clients; it doesn't endorse or recommend any other than certbot. In what way do you perceive that "acme.sh is prominently featured" on that page?
Using the ACME protocol isn't trivial. Any sort of manual workflow would require some software that knows how to speak the ACME protocol, including creating JWT signatures and such. I suppose it's possible, but you'd probably end up with something that's just as complex and depends on assuming that the commands you'd be given are correct and not exploitable in the same sort of way.