Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Acme.sh runs arbitrary commands from a remote server

github.com

Post reply on HN
Print view View original

51–60 of 71 posts

Re: Acme.sh runs arbitrary commands from a remote server

#51

Post by predictabl3 »

superkuh wrote: post #36
predictabl3 wrote: post #27

Sounds about par for the course for folks that think shell is a productively sustainable way of writing secure or reliable software. Not even remotely sorry about that opinion. The gall to claim ACME compat, then force require a single client, all so you can remote execute arbitrary commands. Should be enough to ruin the CA, but we know how people handle things like this "oh, won't affect me " (until it does). Seemin…

People write in bash because you can expect bash to be forward compatible with how people write bash. A bash script written by the average person today will run on a bash interpreter from 2006 (or 2023). Very few languages have the developer culture to achieve this in practice even if it might be possible in theory. And it's not like Bash doesn't get new features. It does constantly. But unlike, say, Rust or JS, the…

This doesn't make any sense to me. Stable Rust is forward compatible just as much as shell scripts are. Bash, for example, does introduce things in newer versions and they're near universally ignored.

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.

Re: Acme.sh runs arbitrary commands from a remote server

#52

Post by tialaramex »

Vecr wrote: post #16

Even if this is just RCE in the script somehow (I doubt it, it can probably do anything the user running it can), it's horrifying. It means the certificate authority could just take your newly generated certificates and upload them anywhere they want. That's a catastrophic compromise in the TLS security model.

Somebody who cares about the acme.sh client specifically would be able to say, but in general it's not necessary that your ACME client has these keys.

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.

Re: Acme.sh runs arbitrary commands from a remote server

#53

Post by electroly »

predictabl3 wrote: post #27

Sounds about par for the course for folks that think shell is a productively sustainable way of writing secure or reliable software. Not even remotely sorry about that opinion. The gall to claim ACME compat, then force require a single client, all so you can remote execute arbitrary commands. Should be enough to ruin the CA, but we know how people handle things like this "oh, won't affect me " (until it does). Seemin…

This is a Chinese CA, I don't think there was a danger of any of us using it, and none of them are here to receive this criticism. Most of your complaints are about the shell script that the Chinese CA is injecting and that's... not really the problem at all. It's amazing that it's not literally a rootkit; that's what I expected when they said a Chinese CA was injecting a shell script that acme.sh was running. You're missing the forest for the trees here.

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.

Re: Acme.sh runs arbitrary commands from a remote server

#54

Post by predictabl3 »

dundarious wrote: post #44
predictabl3 wrote: post #27

Sounds about par for the course for folks that think shell is a productively sustainable way of writing secure or reliable software. Not even remotely sorry about that opinion. The gall to claim ACME compat, then force require a single client, all so you can remote execute arbitrary commands. Should be enough to ruin the CA, but we know how people handle things like this "oh, won't affect me " (until it does). Seemin…

There is almost never a good reason to use constructs like eval in any language (and it exists in many languages), just like there are barely any good reasons to use constructs like system() in C. It appears acme.sh was running eval. I haven't looked into it, but the most common reason I see eval in use is because people don't know that you do it much simpler/more directly by just geting the shell to run commands tha…

And then run shellcheck because even those of us that painful have this seared into our brains make mistakes.

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?

Re: Acme.sh runs arbitrary commands from a remote server

#55

Post by dundarious »

predictabl3 wrote: post #54
dundarious wrote: post #44

Earlier quoted context omitted.

There is almost never a good reason to use constructs like eval in any language (and it exists in many languages), just like there are barely any good reasons to use constructs like system() in C. It appears acme.sh was running eval. I haven't looked into it, but the most common reason I see eval in use is because people don't know that you do it much simpler/more directly by just geting the shell to run commands tha…

And then run shellcheck because even those of us that painful have this seared into our brains make mistakes. 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 writt…

Every language exists on this spectrum, and pretty much every language is clustered near shell. All languages require you to be "principled" in a few key areas, and many projects (open source and closed source) don't do a great job at that.

At least shell is good at a specific and very useful thing (sequences and pipelines of other commands), and is already installed on most machines -- even windows nowadays since almost everyone has git installed. My "build system" for C projects is just doing the following from pwsh: `& "$env:GIT_INSTALL_ROOT\bin\bash.exe" .\build.sh`

Most software is not great. That is the issue.

Re: Acme.sh runs arbitrary commands from a remote server

#56

Post by superkuh »

predictabl3 wrote: post #51
superkuh wrote: post #36

Earlier quoted context omitted.

People write in bash because you can expect bash to be forward compatible with how people write bash. A bash script written by the average person today will run on a bash interpreter from 2006 (or 2023). Very few languages have the developer culture to achieve this in practice even if it might be possible in theory. And it's not like Bash doesn't get new features. It does constantly. But unlike, say, Rust or JS, the…

This doesn't make any sense to me. Stable Rust is forward compatible just as much as shell scripts are. Bash, for example, does introduce things in newer versions and they're near universally ignored. 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…

Here's an anecdote to provide sense. I recall when I was using a 3 month old (1.48.0 2020-11-19) rustc on Debian 11 (right before it was officially released) and I kept running into rust software I couldn't compile because rust devs used bleeding edge 1.50 (2021-02-11) features. This wasn't a debian is old thing. The rustc was literally 3 months old at this point. At least one of the devs was a person I knew on IRC. He was kind enough to re-write it ("plotsweep" a rust software defined radio program) using only 1.48 and older features. But that's the exception. Most rust devs assume your toolchain is from 3rd party out-of-repository and latest and think forwards compatibility is useless like you do.

Shell scripts can be and often are jank. But at least it's stable jank. Shell devs tend to write portable, stable code because that's the entire point of dealing with the shell jank.

Re: Acme.sh runs arbitrary commands from a remote server

#57

Post by predictabl3 »

superkuh wrote: post #56
predictabl3 wrote: post #51

Earlier quoted context omitted.

This doesn't make any sense to me. Stable Rust is forward compatible just as much as shell scripts are. Bash, for example, does introduce things in newer versions and they're near universally ignored. 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…

Here's an anecdote to provide sense. I recall when I was using a 3 month old (1.48.0 2020-11-19) rustc on Debian 11 (right before it was officially released) and I kept running into rust software I couldn't compile because rust devs used bleeding edge 1.50 (2021-02-11) features. This wasn't a debian is old thing. The rustc was literally 3 months old at this point. At least one of the devs was a person I knew on IRC.…

Yeah, I think we're not going to agree on this. I very much like living in a world where I get to use stable, released software, provided by my distro, to build reliable software that is forward compatible.

> This wasn't a debian is old thing.

From my reading and understanding, yeah, it was.

Re: Acme.sh runs arbitrary commands from a remote server

#58

Post by pornel »

yjftsjthsd-h wrote: post #49
cozzyd wrote: post #47

Earlier quoted context omitted.

Python scripts will often break with system upgrades, most acutely when Python2 went away, but under many other circumstances as well.

I would expect python2 to only have gone away across major versions of an OS, which is about as non-disruptive as it could have been, considering. Of course, as I write this ansible is broken on one of my machines for reasons that appear to stem from a python 3.x->3.y update, so...

That's the thing — Python can break with any OS update (I personally can break it whenever I touch it ;)

OTOH a script for /bin/sh written 30 years ago has a good chance running today unchanged.

Having said that, I still would not recommend shell for anything that needs to be robust and secure.

Re: Acme.sh runs arbitrary commands from a remote server

#59

Post by catkitcourt »

This raise one more issue about Chinese providers.

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).

Re: Acme.sh runs arbitrary commands from a remote server

#60

Post by catkitcourt »

predictabl3 wrote: post #27

Sounds about par for the course for folks that think shell is a productively sustainable way of writing secure or reliable software. Not even remotely sorry about that opinion. The gall to claim ACME compat, then force require a single client, all so you can remote execute arbitrary commands. Should be enough to ruin the CA, but we know how people handle things like this "oh, won't affect me " (until it does). Seemin…

I had wrote some shell software (~5k loc without comment i think?) and agree.

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.

Post reply on HN