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

61–70 of 71 posts

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

#61

Post by Vecr »

tialaramex wrote: post #52
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…

I've looked at it more, it looks like this RCE could harvest the private key.

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

#62

Post by SergeAx »

l0b0 wrote: post #48
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…

How did we get here? - 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. - Doin…

Script may be not easy to write, but it's universally easy to deploy. Single almost cross-platform file, no dependencies. Publish the text on a webpage or in an email newsletter so everyone can copy-paste it to their system. Brilliant.

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

#63

Post by predictabl3 »

dundarious wrote: post #55
predictabl3 wrote: post #54

Earlier quoted context omitted.

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 al…

I'm happy (and spoiled) that I live in a world where I get to use reliable software and not worry about it being inaccessible. With a single nix command, I'm dropped in an environment with secrets mounted by a single age key, with all programs and configuration exactly as I want. It's trivial for me to "just switch" to nushell/rust and not worry about such things. And nushell and rust are not clustered near shell for the aspects I'm talking about in this discussion.

"bash is everywhere" is just more lipstick on the pig, in my strong opinion.

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

#64

Post by bheadmaster »

predictabl3 wrote: post #57
superkuh wrote: post #56

Earlier quoted context omitted.

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.

Three months old software is new enough to be in Arch repository, so in this case it's not about Debian being old, it's about rust devs using bleeding edge features.

If you're contradicting a person's argument ("yeah, it was") at least provide some more explanation, otherwise your comment is rarely more than a "is too!".

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

#65

Post by tialaramex »

Vecr wrote: post #61
tialaramex wrote: post #52

Earlier quoted context omitted.

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…

I've looked at it more, it looks like this RCE could harvest the private key.

I have no idea, my point was that in general the ACME client can't necessarily give you the private key even if it wanted to, because if you provide a CSR the key needn't even be on the same machine, let alone accessible in its execution environment.

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

#66

Post by monetus »

yjftsjthsd-h wrote: post #33
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…

Shell is a bad fit for many uses (an ACME client is more ambitious than I would build in shell, personally), but the things it's good at, it's really good at. I have yet to find anything else that's even close to as good for glue code when I have a handful of tools and/or a bunch of files that I need to string together. Unless you're writing in Ada, I promise whatever language you think is better has its own sharp ed…

Ever tried TCL? Curious on your thoughts.

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

#67

Post by Bystroushaak »

pornel wrote: post #58
yjftsjthsd-h wrote: post #49

Earlier quoted context omitted.

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.

Well. I've been using python personally since 2007, and it never broke with update (I still occasionally run scripts written for 2.5). Also, I am working as a python backend dev, dealing with hundreds of systems (we are deploying 270+ systems and supporting another 340 user built docker images built on top of py library), and no problems there either. In my previous job, I was doing deployment to 4000+ kiosk computers, and still, no problems with python breaking.

What was definitely problematic was the update from 2 to 3. Another problem may be dependency management (people not pinning dependencies). But the python itself? What does it even mean? Interpreter not starting?

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

#68

Post by cozzyd »

Bystroushaak wrote: post #67
pornel wrote: post #58

Earlier quoted context omitted.

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.

Well. I've been using python personally since 2007, and it never broke with update (I still occasionally run scripts written for 2.5). Also, I am working as a python backend dev, dealing with hundreds of systems (we are deploying 270+ systems and supporting another 340 user built docker images built on top of py library), and no problems there either. In my previous job, I was doing deployment to 4000+ kiosk computer…

If you're using Python as a bash script replacement for various individual standalone scripts, typically you would be using system libraries without pinning dependencies, in which case you'll break on various OS updates as Python libraries don't seem to value backwards compatibility. Sure you could include a virtual environment with every script but that's not very ergonomic and will really add up...

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

#69

Post by broknbottle »

Bystroushaak wrote: post #39
yjftsjthsd-h wrote: post #33

Earlier quoted context omitted.

Shell is a bad fit for many uses (an ACME client is more ambitious than I would build in shell, personally), but the things it's good at, it's really good at. I have yet to find anything else that's even close to as good for glue code when I have a handful of tools and/or a bunch of files that I need to string together. Unless you're writing in Ada, I promise whatever language you think is better has its own sharp ed…

I usually replace shell scripts with python (using sh module: https://amoffat.github.io/sh/ for calling other scripts/programs).

macOS doesn’t even come with Python..

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

#70

Post by zhfliz »

0x0 wrote: post #38
tptacek wrote: post #32

Earlier quoted context omitted.

This feels a little bit like doubling down to find ways to implicate the actual CA instead of the reseller. It's clear how mismanagement by a real CA would make a more interesting story than by this random no-longer-existing pseudo-reseller, but I don't think there's evidence to support that story yet.

But it's not a random pseudo-reseller? The one github comment from "the founder of Quantum CA" seems to say they are also the creator of HiCA, which is the entity that was exploiting the 0day in acme.sh. And the crt.sh link shows an intermediate CA cert named "QuantumCA", signed by ssl.com. So QuantumCA == HiCA == exploiters of the acme.sh 0day, it's all the same entity? The intermediate CA could just as well be name…

Quantum CA (brand, not operator)/HiCA still can't issue certs for domains they don't "control" by having RCE on the systems they point to.

all CA requirements for validation still need to be fulfilled for issued certificates, as ssl.com, the Quantum CA operator, which exclusively holds the private keys, is a "proper" CA.

this does not affect the trust in the CA infrastructure or ssl.com itself; while this is morally questionable to keep the business relationship, it does not mean the CA is not following the signing requirements.

Post reply on HN