Woah. This is something that is incredibly sketchy, and I think warrants an investigation by Mozilla and Chrome. My knee-jerk reaction is complete revocation of the intermediate cert that HICA is using and a full explanation.
How does one bring this to Mozilla’s and Chrome’s root programs’ attention?
Yes, though non-bash programmers are also often ending up throwing a sh() or exec() or two with unsanitized strings without thinking twice about the consequences since calling external programs with arguments is such a different paradigm than regular function arguments.
What do you suggest instead in general? While I do like to avoid it, I’ve unfortunately found it necessary to interop with certain things. Obviously you can avoid a lot of it by passing parameters as an array rather that string concatenation (as most exec implementations allow), but is there something more to it than that?
Passing params as an array is exactly the difference between “shelling out” (using a shell to string process your command and execute the right thing), and general subprocess execution (pointing the kernel to an executable and passing argv as an array - no shell or string processing involved)
In this case, that’s not enough, because HiCA supports none of the non-shell ACME clients. The support only the one that’s in shell, apparently because it has this hole :)
That said, this issue is relatively easy to understand, and I filed a bug here to let the author know that they can safely restore their logging wrapper.
_execute_or_log() {
"$@" 2>>logfile # run the command $1 with args $2 $3 ...
}
_execute_or_log nginx -t # no quotes !!!
_execute_or_log 'shell | chars > are $(ok)' # string not evaluated as shell
I get why "$@" looks weird to people. There’s no first word. It’s a weird syntax, but it’s correct.
The problem is that quotes usually mean don’t split words, giving one arg, where has it means almost the opposite: don’t mangle the arguments array, giving multiple args.
In YSH/Oil, it’s just
var cmd = ['nginx', '-t']
@cmd # splice array, running the command cmd[0] with args cmd[1], cmd[2], ...
@ARGV # splice argv array
which hopefully makes more sense
Shell also has prefixes like
command -- "$@" # no function lookup
builtin -- "$@" # only builtins
It would be possible to add some kind of no-op wrapper that could reduce confusion
run-this-command -- "$@"
echo "$@" # log the command
This is the best tool IMHO. Unfortunately it hasn’t been ported to linux AFAIK. The second best choice is lacme which is available in Debian’s official repo.
I found out yesterday that RHEL 9 doesn’t provide any ACME client, you have to go to EPEL. Seems like more and more having an ACME client is a pre-requisite for running apps, and not having one on a general purpose server OS is quite the oversight.
There is a port of acme-client(1), but I don’t know if it’s still kept in sync with upstream since it hasn’t had a commit in 8 months https://sr.ht/~graywolf/acme-client-portable
oh it’s one of these things that tells you to download a script piped directly into sh. This is such an anti-practice. We should not be teaching people that it’s “ok” to do this. It’s not ok.
I think it would be helpful to motivate this complaint with a specific harm. In this case it strikes me as particularly odd - the software is itself a shell script that you’re downloading from the internet for the purpose of execution, with all the consequences that entails. At 8000 lines I’m not exactly confident in my ability to spot any mischief.
oh it’s one of these things that tells you to download a script piped directly into sh. This is such an anti-practice. We should not be teaching people that it’s “ok” to do this. It’s not ok.
You know, downloading a script and piping it into sh is roughly equivalent to downloading a .exe installer that installs an application, which has been standard practice in Windows for decades. I know Microsoft has an app store nowadays, but it’s not all that surprising people would readily do it so easily.
It’s just as bad as running any externally sourced binary. Compiling it yourself doesn’t count either, unless you have a good reason to trust the code.
If you don’t trust the install script, why trust the software it installs?
Yes, “it’s been standard practice on Windows since the 2000s” should under no circumstances be used to justify security practices. Anyone who attempts to do so will receive a free cup holder.
No it really isn’t. A shell script should be transparent as to its purposes. As a competent systems administrator you are able to download, analyze and assess what the script is doing by virtue of being able to read the code in the shell script. You can then make an informed decision - “do i trust running this code on my host?”. An .exe is basically an opaque binary blob.
The anti-pattern is telling Unix users to ignore this basic security hygiene they have and to just trust the source of the script you are running. It was bad when the Gnome project started doing this in the 2.x days and its probably worse today.
As a competent systems administrator you are able to download, analyze and assess what the script is doing by virtue of being able to read the code in the shell script. You can then make an informed decision - “do i trust running this code on my host?”. An .exe is basically an opaque binary blob.
A shell script over some length is worse than opaque binary blob because the tools for analyzing it are worse, and in either case, nobody is doing that no matter what you claim about “basic security hygiene.” There has to be trust if you want to do more than build your own LoseThos on the computer.
when i used to use arch I never once read the scripts for AUR packages I installed. Was this foolish? Yeah, probably. But I could read the package script and have it check out, and then the source code could be malicious, so maybe I should have read all of the source, too?
The major thing with curl | sh that I think is a problem is if the domain name gets squatted by a bad actor. I don’t think there’s any danger in following the Rust installation instructions, for example.
s a competent systems administrator you are able to download, analyze and assess what the script is doing by virtue of being able to read the code in the shell script.
OK so read it, you can waste your time if you want to, just delete the pipe to sh
“do i trust running this code on my host?”.
lol it’s installing a binary blob that executes code by virtue of compilation, auditing the build script is a waste of time
The anti-pattern is telling Unix users to ignore this basic security hygiene they have and to just trust the source of the script you are running.
Last time I checked, it was pretty easy to host a Debian package repo (I think GitHub lets you do it for free). If you package your Rust binaries as a .deb on such a package repo then you have a few advantages:
Uninstall works as it would for any other application.
Updates work automatically.
There’s an audit trail of exactly which files were installed by the package.
The packages are signed by a key that you can verify out of band.
Woah. This is something that is incredibly sketchy, and I think warrants an investigation by Mozilla and Chrome. My knee-jerk reaction is complete revocation of the intermediate cert that HICA is using and a full explanation.
How does one bring this to Mozilla’s and Chrome’s root programs’ attention?
I am not involved with the Mozilla root program, but I made sure the team is aware.
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/heXVr8o83Ys has the current discussion.
https://wiki.mozilla.org/CA has an ‘information for the public’ with a link to ‘report an incident to Mozilla’ which takes you to a bugzilla project.
We really gotta stop writing and using software written in shell. There are so many footguns in shell that these types of mistakes are inevitable.
Yes, though non-bash programmers are also often ending up throwing a
sh()orexec()or two with unsanitized strings without thinking twice about the consequences since calling external programs with arguments is such a different paradigm than regular function arguments.Not on my watch! Few things trigger my “add comment to pull request” finger faster than shelling out for running subprocesses.
What do you suggest instead in general? While I do like to avoid it, I’ve unfortunately found it necessary to interop with certain things. Obviously you can avoid a lot of it by passing parameters as an array rather that string concatenation (as most exec implementations allow), but is there something more to it than that?
Passing params as an array is exactly the difference between “shelling out” (using a shell to string process your command and execute the right thing), and general subprocess execution (pointing the kernel to an executable and passing argv as an array - no shell or string processing involved)
Ah! Ok. I had always referred to both as “shelling out” but this makes sense to me. Thanks :)
In this case, that’s not enough, because HiCA supports none of the non-shell ACME clients. The support only the one that’s in shell, apparently because it has this hole :)
That said, this issue is relatively easy to understand, and I filed a bug here to let the author know that they can safely restore their logging wrapper.
https://github.com/acmesh-official/acme.sh/issues/4666
Instead of removing this logging wrapper
https://github.com/acmesh-official/acme.sh/commit/327e2fb0a4bdbe4b75339e1cad6d20bda29318d6
You can replace it with one without
eval:I get why
"$@"looks weird to people. There’s no first word. It’s a weird syntax, but it’s correct.The problem is that quotes usually mean don’t split words, giving one arg, where has it means almost the opposite: don’t mangle the arguments array, giving multiple args.
In YSH/Oil, it’s just
which hopefully makes more sense
Shell also has prefixes like
It would be possible to add some kind of no-op wrapper that could reduce confusion
I just want to note that there is also OpenBSD‘s acme-client(1), which is a privilege separated implementation of ACME.
This is the best tool IMHO. Unfortunately it hasn’t been ported to linux AFAIK. The second best choice is lacme which is available in Debian’s official repo.
I found out yesterday that RHEL 9 doesn’t provide any ACME client, you have to go to EPEL. Seems like more and more having an ACME client is a pre-requisite for running apps, and not having one on a general purpose server OS is quite the oversight.
There is a port of acme-client(1), but I don’t know if it’s still kept in sync with upstream since it hasn’t had a commit in 8 months https://sr.ht/~graywolf/acme-client-portable
what is acme.sh
oh it’s one of these things that tells you to download a script piped directly into sh. This is such an anti-practice. We should not be teaching people that it’s “ok” to do this. It’s not ok.
https://github.com/acmesh-official/acme.sh#1-install-online
I think it would be helpful to motivate this complaint with a specific harm. In this case it strikes me as particularly odd - the software is itself a shell script that you’re downloading from the internet for the purpose of execution, with all the consequences that entails. At 8000 lines I’m not exactly confident in my ability to spot any mischief.
You know, downloading a script and piping it into sh is roughly equivalent to downloading a .exe installer that installs an application, which has been standard practice in Windows for decades. I know Microsoft has an app store nowadays, but it’s not all that surprising people would readily do it so easily.
the argument about windows .exe files doesn’t imply that curl | sh is a good thing to be doing.
It’s just as bad as running any externally sourced binary. Compiling it yourself doesn’t count either, unless you have a good reason to trust the code.
If you don’t trust the install script, why trust the software it installs?
Yes, “it’s been standard practice on Windows since the 2000s” should under no circumstances be used to justify security practices. Anyone who attempts to do so will receive a free cup holder.
No it really isn’t. A shell script should be transparent as to its purposes. As a competent systems administrator you are able to download, analyze and assess what the script is doing by virtue of being able to read the code in the shell script. You can then make an informed decision - “do i trust running this code on my host?”. An .exe is basically an opaque binary blob.
The anti-pattern is telling Unix users to ignore this basic security hygiene they have and to just trust the source of the script you are running. It was bad when the Gnome project started doing this in the 2.x days and its probably worse today.
A shell script over some length is worse than opaque binary blob because the tools for analyzing it are worse, and in either case, nobody is doing that no matter what you claim about “basic security hygiene.” There has to be trust if you want to do more than build your own LoseThos on the computer.
when i used to use arch I never once read the scripts for AUR packages I installed. Was this foolish? Yeah, probably. But I could read the package script and have it check out, and then the source code could be malicious, so maybe I should have read all of the source, too?
The major thing with curl | sh that I think is a problem is if the domain name gets squatted by a bad actor. I don’t think there’s any danger in following the Rust installation instructions, for example.
OK so read it, you can waste your time if you want to, just delete the pipe to sh
lol it’s installing a binary blob that executes code by virtue of compilation, auditing the build script is a waste of time
They already trust it, it changes nothing
Many of lot of these scripts include base64 or other encoded compressed data
I thought that’s how you install rust O_o
this should not be how rust is installed
im not saying that’s not how people do it but it is not good
It’s often hard to do better. For example, Debian doesn’t yet package rustup, and the version of Rust it does package is outdated.
I think eventually this will sort itself out by every distro/OS providing a “good” way to get rustup, but we are not at that point yet.
It’s easy to do better: Don’t recommend people do curl | sh
It’s better to say “do Y instead of X” instead of “don’t do X”.
What would be a better way to install Rust?
By this line of argument:
Last time I checked, it was pretty easy to host a Debian package repo (I think GitHub lets you do it for free). If you package your Rust binaries as a .deb on such a package repo then you have a few advantages:
It is ok
So this thread is about way more than just acme.sh… there’s a whole weird thing going on