Was it even run through shellcheck?!
Stop writing this stuff in shell people. 95% of the time I review any (posix, nushell lacks most of these issues) shell scripts, it's obvious they would fall apart the second any string unexpectedly had a space in it. Even scripts written by darling companies of HN.
- The barrier to entry for shell scripting is tiny. You basically start with `ls` in an interactive shell and end up writing a frickin' 500-line monstrosity within a month.
- POSIX has fossilised scripting languages. I hoped we'd have something like PowerShell by now, but although we have some fine alternatives, none of them seem to be good enough to actually overcome the inertia of POSIX.
- Doing something that looks correct is easy, but doing the right thing is super effing hard. See looping through complex sets of files.
- People use statements like "It's just a script", as if scripts are somehow easy to write. Bullshit.
But shell is really not hard if people stick to a few easy guidelines:
- quote all var expansion, e.g., "$var" not $var or ${var} (very rare to need otherwise, and never for untrusted data)
- use "$@" to perfectly forward arguments (not $@, not $*, not "$*" except when you want to turn many arguments into one)
- don't use eval
- use `set -eu` and explicitly handle functions/commands that may benignly return/exit non-zero, e.g., `diff -U10 ./a ./b || true`
- use printf on untrusted strings instead of echo (just use it generally, I say), e.g., printf %s\\n "$var" instead of echo "$var". One of the few times you want to use "$*" is with printf though, e.g., printf %s\\n "$*" instead of echo "$@". Try them out, easy to see why, as with one thing to format and multiple arguments, `printf %s\\n "$@"` is equivalent to `for i in "$@" ; do printf %s\\n "$i" ; done`
- when using xargs, use -0 if available, or at least -d\\n if available (busybox doesn't have it for example). also usually want to use -r
Or just use a scripting language that eliminates many of these headaches (nushell) or a real programming language.
I get it, I really do. At least now I have nushell for some sanity, but I still find myself constantly writing a shell script and then realizing after a few iterations that I should've just written in nushell/Rust.
As a thought experiment, how many places rolled out acme.sh to prod and didn't bother code reviewing it or running it through shellcheck?
Unfortunately requiring approval and authentication from a random incorporated entity running a CA every 90 days is inherently complex. And all the ACME protocol implementations do is hide that inherent complexity by adding even more. CA TLS HTTP is very fragile but it could be made less so if corporate browsers didn't demand short lifetime certs-- a demand reasonable for businesses but not for human people or things expected to last longer than a few years without being touched.
All of this also excludes that the fact that your shell script will be just as janky in 10 years as it is now. Again, I regularly, regularly see shell scripts from companies that HN fawns over that don't pass shellcheck and have inherent issues that don't occur in better scripting languages, or full programming languages.
"Forward-compat" is not unique, and not a value proposition to me if it inherently means less reliable function.
This doesn't get better if they had injected a better-written script or a Rust program or whatever else. They could still have injected anything, and that's the problem. The people who wrote acme.sh (different people than the Chinese CA), which has the security vulnerability that the Chinese CA exploited, might have some soul-searching to do.
I was using shell because the project want to maintain compatibility between different distros (including some weird customized one without `ps` and `sed`), but that's all. Shell is not a good choice for things other than scripting.
Fucked up and they should be booted from every root program for this.
They were also suggesting that user's ran the utility as root...
All really shady...
Everybody makes mistakes people. If this person was trying to be malicious they would have disappeared, not come straight clean about it on the thread.
Interestingly, the mozilla dev-security-policy group seems to contain a recent discussion about including "ssl.com" in the root store here https://groups.google.com/a/mozilla.org/g/dev-security-polic...
Curious to know if this could, maybe it should, have ripple effects to the various SSL Root CA programs. Having someone run a subCA that actually exploits an RCE against ACME clients doesn't seem very trustworthy, and any CA enabling this behaviour should probably be kicked out of the trust stores?
https://github.com/acmesh-official/acme.sh/issues/4659#issue...
[0] https://www.geoffchappell.com/notes/security/aim/index.htm
The site using this exploit, HiCA is run by xiaohuilam on Github. He/She is also the founder of two famous SSL certificate provider in China, DigitalSign and QuantumCA. Additionally, he is also a contributor of acme.sh repository. The acme.sh repository locked issue #4659 quickly after it raise attentions in the developer community in China.
It's hard to imagine that, as one of the repository's contributor, once you have found a vulnerability, you are going to use it in your own product, instead of fix it. They are just another version of Pinduoduo (owner of Temu, and also the one who put spyware on user's android phone).
I do wonder if what HiCA did gave possibilities to post the private key somewhere else?
What the ACME protocol wants to do is hand over a CSR (Certificate Signing Request), and get back a certificate, and to achieve that it has to explain how you'll prove you're entitled to such a certificate.
Most ACME clients will also make a suitable proof (in at least some cases), and also generate a suitable CSR from first principles, for which they will need to generate a new private key - but that's not a necessary part of the system, and it's certainly not rare to generate your own CSR, either because you must technically, or because your own security processes say strange women, lying in ponds, distributing swords is no basis for a system of government sorry, I mean, that this key is private and shouldn't be on the host running ACME services.
If the CA can access your private key, then it can reuse (or worse, redistribute) it without anyone knowing.