Hacker News Reader

Comment by gorgoiler | Hacker News Reader

A clever trick with a funny example, but I’m also fine with curl|bash — as fine as I am with “pip3 install thing” or installing “thing.dmg”.

I almost always decide whether to execute someone’s else’s software based on their reputability. Is the project well known? Is it maintained, with lots of GitHub stars? My decision is never based on reading the source code. I don’t have nearly as much of a problem with curling shell scripts as the finger-wagging “actually you shouldn’t do that” crowd seem to say I should.

The one thing that really does give me the creeps is adding someone else’s apt repository to my system-wide one. I just can’t seem to square that off in my head against my more laissez-afire “well do I trust them or not?” attitude that I take for every other installation attack vector. Maybe because it means trusting the third party forever, instead of just once?

View on HN

The problem with Pypi is the transitive dependencies. You may trust a high profile package but it could pull in any number of projects that are exploited by bad actors.

This is a real problem that I believe will become increasingly commonly used by attackers to break into companies.

Unfortunately, it's not an easy problem to automate the detection. There are some heuristics, but you're basically writing something like Norton Antivirus for Python packages lol.

A sufficiently skilled attacker can make their code look totally innocent[0]. :)

Source: Former security engineer at Uber/Snap that's now working on tooling in this space[1].

0: "Underhanded C Competition" http://www.underhanded-c.org/

1: Open Source "Supply Chain Security" platform https://github.com/lunasec-io/lunasec

It’s already extremely common in the Python, Ruby and Node ecosystem (see sources below).

The only company that has a real chance at making a dent in the issue is GitHub and to a degree they already have.

SOURCES:

- https://www.mandiant.com/resources/blog/supply-chain-node-js

- https://www.zdnet.com/article/backdoor-found-in-ruby-library...

- https://www.reversinglabs.com/blog/mining-for-malicious-ruby...

- https://news.sophos.com/en-us/2021/10/24/node-poisoning-hija...

- https://www.bleepingcomputer.com/news/security/dev-corrupts-...

- https://portswigger.net/daily-swig/amp/malicious-python-libr...

And a problem which is some 5x worse in npm

5x worse on each level, maybe. That composes quite quickly.

Npm packages have really crazy dependency graphs. It's usually on the 1000s of times larger than what you get on most languages, 100s of times larger than python or ruby.

Why is this the case?

Because JS had a very poor stdlib and attracted people that had little to no experience in best-practices in older languages

Hence left-pad. And this pet-peeve of mine https://nodejs.org/docs/latest/api/process.html#processargv (who cares about the node fullpath in argv[0]?)

Why oh why do people cite left-pad like this as an example of package bloat? It’s functionality was so valuable it was included in ECMAScript 2017!

The problem with left pad was a security one, not a package bloat one.

No, the problem is bad developers pulling in dependencies for trivial functionally. If there was a `for-loop` npm package bad devs would be pulling it in instead of writing their own for loops. Padding on the left is something if it doesn't exist you write it in a few lines of code yourself. You don't add a package for such trivial functionality.

Nope, this is a bad take, parroted without understanding; if it got moved into the std lib, it was probably useful enough. You can even read why in the original proposal if you comb the archives enough (from https://github.com/tc39/proposal-string-pad-start-end):

> It is highly probable that the majority of current string padding implementations are inefficient. Bringing this into the platform will improve performance of the web, and developer productivity as they no longer have to implement these common functions.

“It’s too trivial” is not why left-pad was in the news. Go read about it to understand the actual issue: https://www.theregister.com/AMP/2017/07/12/javascript_spec_s...

> if it got moved into the std lib, it was probably useful enough

Of course it was useful, hence why most non-crappy languages had it in its stdlib from inception pretty much

But building a package just to do left-pad is stupid, especially since it can be implemented in a couple of lines

You can’t both believe it’s worth putting in the stdlib and not worth importing a library for, if your intention is to be consistent.

You are neglecting the risk-factor of pulling in libraries from unknown authors on npm vs the stdlib. The package-bloat problem is one of culture, where developers keep neglecting this risk, only seeing the 5 lines of code they save by importing something, without seeing the potential cost and tech debt of having to review, maintain, update and security-monitor this dependency for all future.

Nobody thinks leftPad was not a useful function. The question is, was it useful enough to counter all the risks of npm, probably not. In the stdlib there is no such risk.

Ah, and now we’re talking about the real issue, which was the security risk.

My point has been this whole time that left-pad was not a story of a trivial function needlessly pulled from an external source as the person I replied to had claimed, and it appears you agree. Good!

Here's my theory. Older programming languages force you to think about sub-dependencies: if you decided to use a third-party library, you would have to look at and manually add its requirements to your build system.

But, with npm, suddenly it was trivial to include other packages without having to worry about sub-dependencies. The whole tree just magically added itself to your build, and only if you paid attention to the build process would you discover just how many developers you were transitively trusting.

Well, while yes, automatic dependency management is a really relevant reason why things got that bad, it can't be the only reason.

Programs in other languages with the same kind of tooling tend to stop at hundreds or at most low-thousands of dependencies. Javascript code often reach tens or low-hundreds of thousands of dependencies.

Dependency explosion is bad all around, but JS is exceptionally bad.

Javascript lacks many basic facilities that other languages have.

it's becoming the same in rust. Here's the rust official docs

https://github.com/rust-lang/docs.rs

Follow the build instructions, then you get to `cargo build` you'll see this message

    Downloaded 448 crates (44.1 MB)

448 crates for a static site generator!?!?!?! WTF!

I think a large chunk of this is the tendency in larger Rust projects to split themselves up into smaller library crates, rather than single crate monoliths: single libraries that you use may depend on 5 different crates all from the same project, that count as separate in the number you’ve quoted. On top of that, C bindings tend to live in their own crate, so while you might depend on the openssl crate, it in turn depends on openssl_sys which contains raw bindings (rather than a nice Rust wrapper). That all said, I think crates.io is still at the initial stage of “tiny crates each doing a single thing” that I think every registry goes through to begin with.

I think there is a trend towards reducing dependency bloat, at least in some circles. For example, the main React package has had this much recursive dependencies throughout the past few major versions:

  react@15 — 20 deps
  react@16 — 6 deps
  react@17 — 4 deps
  react@18 — 3 deps

The latest version of vite (a webpack replacement that's been gaining in popularity) has 14 recursive dependencies. It could be better, but it's still a significant improvement over 300+ package monstrosity you get by combining webpack with everything necessary to reimplement what vite is doing.

If you pick your packages carefully (for example, looking for alternatives this one ↓ instead of the much more popular react-router), it's not as bad as it used to be.

https://github.com/molefrog/wouter

I find that this is more of an npm problem - thanks to the lack of a standard library and a cultural affectation towards small packages with a narrow focus.

A high level python package is more likely to depend upon 3-30 well known packages.

I think the biggest factor is just a much larger overall number of packages in the ecosystem. If there are, on average, 20 popular packages for solving a given problem instead of 3, you end up with exponentially more transitive dependencies.

The company I work for hosts their own PyPi mirror internally and will attempt to ban packages or dependencies before PyPi does.

I think more companies should do this.

But that's how trust works. If you don't trust them to pull in safe dependencies, then you don't really trust them.

There are various degrees of trust. One may trust a package maintainer to write correct, well-designed code and to maintain it. But should one trust that package maintainer to have solid security standards in their code repo, their CI/CD, and their distribution mechanism?

So, actually you don't really trust them...

An interesting thing is that it should be the other way around.

Repository packages usually are signed with GPG. You can even use HTTP - it does not matter. And GPG could be used to sign packages on another machine, may be even on offline machine with HSM.

Things like pip or curl rely only on HTTPS. There are many agents between developer who built a deliverable artifact and your machine. There's WWW-server. There's some CDN with HTTPS termination. There's NSA which can issue fake certificate and MITM attack you (mostly imaginably threat for sure, but still).

And hacked WWW servers already happened. Transmission website was hacked and their binary was infected.

Now I don't claim it to be a big issue. Malevolent developer is much more dangerous and much more likely to happen. But if we want to compare those two methods - I think that repositories with proper signatures are safer.

At the risk of pointing out what I see as the obvious, but you’re focusing on different attacks. It’s a lot more nuance than “it should be the other way around”. A very valid argument can be made that it’s more likely that you’re installing a dodgy package rather than being subject to some sort of MITM attack.

An apt repository has to be trusted forever: every apt upgrade brings a risk that something new and nefarious will slip in. With curl|bash it’s a one time risk.

The point of TFA is preventing piping curl to bash, not preventing from running bash scripts.

The problem with piping is that bash will read line by line, keeping the connection open while it runs. If the connection fails for any reason, the script will stop, potentially breaking or corrupting things.

This can be prevented by first downloading the file, and then running it.

> If the connection fails for any reason, the script will stop, potentially breaking or corrupting things.

If the script is meant to be piped from curl, and is well written, it will be written so that it first defines everything as functions and then at the very end makes a single function call. This ensures that the script will only do anything if it has been completely downloaded.

For example, the script that rustup.rs tells you to pipe from curl is written in that way.

You can't be sure that developer did that and it's better to stay on the safe side IMO.

>it will be written so that it first defines everything as functions and then at the very end makes a single function call. This ensures that the script will only do anything if it has been completely downloaded.

This is not sufficient. More care is required.

    lsp_init() {
        ...
    }

    lsp_init

If the last line gets truncated between the `s` and the `p`, then `ls` gets executed. Of course `ls` is harmless, but I'm sure you can imagine how it could be worse.

In other words, not only do you have to wrap your script in functions, but you have to ensure that any top-level function / command invocations are named such that they do not become different commands if truncated.

This is unsolvable in general, because the user can have any arbitrary names in their $PATH , such as custom personal utils in ~/.local/bin which can have any unforeseeable name.

It's much easier to just wrap the script in `()` to make it run in a subshell. bash will not run anything until it sees the closing `)` so truncated scripts are not a problem, and it also doesn't have the name collision problem.

How would it become truncated?

A cat unplugs the router?

When a dog does it, would it be trundoged instead?

In the case of curl it can happen if the server did not use Content-Length and the connection gets closed.

All the presence of the content-length header would do is change curl's exit code when the connection breaks. The part where curl output the truncated script and bash executed it would be unchanged.

The whole context of this conversation is >If the connection fails for any reason, the script will stop, potentially breaking or corrupting things.

I've heard this theory before-- that a command could get cut off halfway and execute something really bad-- and tbh I'm skeptical that this has happened even one time in all the billions of invocations of curl|bash. It's just not worth worrying about, in the same way that a cosmic ray bitflip could cause a kernel bug that erases my entire drive but in reality I don't spend any time worrying about this.

>It's just not worth worrying about

For you, apparently. Other people do worry about it, which is why they do take care to wrap their script in functions. And my point is there's an even easier and more foolproof way than that.

>in the same way that a cosmic ray bitflip could cause a kernel bug that erases my entire drive but in reality I don't spend any time worrying about this.

Other people use ECC memory because they worry about this, and because it does measurably happen.

> If the last line gets truncated between the `s` and the `p`, then `ls` gets executed.

My shell[0] dies with a error "source file did not end with a newline". This is easily solvable in general, regardless of what's in PATH, as long as the shell works correctly. Valid text files do not end with bytes other than 0x0A. Being truncated at the end of a line, on the other hand, is not manifestly obviously a error.

0: That I wrote, because of bugs other than this one in bash et al, such as $FILE_WITH_SPACES; not just "my shell that I use".

You can fix that by wrapping the entire code in a function and calling it at the end.

My problem with curl|bash is that it tends to not take into account my preferences wrt where binaries, config files, etc go. If you’re lucky it’ll take an envar. If you’re really lucky they’ll tell you what it is in the docs. I recently had to install the latest curl from source and it was as easy as ./configure --prefix ….

The apt repo thing is actually why I switched to Arch a while back. In Arch you have most packages being up-to-date by default (because you're on a "rolling release").

There is also the "Arch User Repository" which includes a bunch of useful packages that are easy to install, but with full transparency about where the contents are coming from (you can inspect the script).

They have even released an easy installed for Arch now that you can use, or you can just use Manjaro Linux. Regardless though, I really appreciate this distro for development after many years of using Ubuntu!

Where this easy arch install at?

https://wiki.archlinux.org/title/Archinstall

It's called archinstall and it's a helper script (it looks like)

Oh thanks, I'll look into it!

curl|bash does't have an obvious UNinstall mechanism. You can pip3 uninstall, apt-get remove, but what do you do for curl? It could give a shit all over your system, /usr, /etc and you wouldn't know what to delete.

But I have the same problem building from source and using make install. There’s often not an easy make uninstall command. And pip uninstall only uninstalls individual packages, it doesn’t clean up auto-installed dependencies while also ignoring dependencies that I had at any point requested to be installed directly

Reputability won't help you if someone intercepts your connection and replaces the script. TLS helps, insofar as the version of curl you're using and its configuration is correct, your machine has the right certs installed, and the remote domain and/or host and/or repo hasn't been hijacked.

If eithet you or the host have been compromised, it doesn't matter where you curl into bash, run pip install or download an exe/dmg/deb file - you're hosed.

Packages are signed, unless you're using a niche, insecure distro or package manager. Of course, that signing key could also be compromised, but those are usually more tightly guarded than web servers, which are compromised rather more frequently (any reputable dev should have their key in a hardware enclave like yubikey or similar).

Then maybe a solution is script signing. PowerShell scripts can contain a signature at the end, and the shell will check that signature. It can either be mandated all the time or only if the script originally comes from a remote source (or disabled completely if you don’t care). Since it’s just a comment block, it’s fully backwards compatible to add too

This solves the part of downloading partial scripts, but doesn't solve the problem of malicious scripts. If you download a script from a compromised host, they'll just re-sign the modified script with their own signature. The solution is that you have to trust the script source, and transmit over secure channels.

If they sign the script with their own signature then it’s no longer a script that you trust. I can’t remember if PowerShell automatically trusts a script that’s been signed by a cert issued by someone like VeriSign, but if the system were to be adopted for Bash scripts there’s no reason it couldn’t use a store that only trusts the distro maintainers by default.

If it only trusts the certs from distro maintainers then surely it will be distributed as part of the normal package sources. If you need to add a cert, then the problem is exactly the same as adding a repository to the package manager; if the delivery mechanism of the instructions is compromised you're hosed.

Powershell will accept codesigning certs that are signed by verisign, so the workaround for an attacker who has already compromised a web site is to modify and re-sign the script with a certificate that can be obtained for $60.

> they'll just re-sign the modified script with their own signature

Nope. Of course if someone stores a Code Signing key on the same server as the distribution server then all bets are off, but otherwise it's no possible.

PS CodeSign isn't perfect, but there is enough hoops to jump around for this not to be an easy task for a malicious actor gained access a distribution point.

If I take a script, modify it and re sign it with a valid key, it will still be signed, just not by the original author, and will run.

Even on windows now, package are often signed by individual developers rather than an entity that you might recognise the name of.

> but there is enough hoops to jump around for this not to be an easy task for a malicious actor gained access a distribution point.

If this is an optional step (which it would have to be) then the easiest thing to do is to remove the signature from the script and modify the instructions on how to run the script. If an attacker has compromised the supply chain, unless the original host has done something incredibly dumb, chances are they're quite dedicated and jumping through a handful of extra steps arent going to stop them.

> If I take a script, modify it and re sign it with a valid key, it will still be signed, just not by the original author, and will run.

> Even on windows now, package are often signed by individual developers rather than an entity that you might recognise the name of.

This is implies what you, as an attacker:

have the access to the Enterprise PKI

can issue code signing certificates

somehow your certificate drops in the Trusted Publishers[0] on the endpoint ie you have the access or to the GPO/domain controllers (keys to the kingdom) or to the endpoint (making the whole dance with certs moot)

> If this is an optional step (which it would have to be) then the easiest thing to do is to remove the signature from the script

This would make the script to fail from running in a proper configuration

> and modify the instructions on how to run the script.

And again this requires the access to the endpoint, which makes your assumptions moot.

> If an attacker has compromised the supply chain, unless the original host has done something incredibly dumb, chances are they're quite dedicated and jumping through a handful of extra steps arent going to stop them.

Exactly, which is why you don't "signed by individual developers", don't provide the easy way to access the PKI, don't sign the scripts and yet run them with -bypass.

Come on, I did deploy PKI and PS Code Signing.

[0] https://old.reddit.com/r/PowerShell/comments/kpwi5r/powershe...

> Packages are signed, unless you're using a niche, insecure distro or package manager.

You still need to get that signature from somewhere, likely a web server. If your threat model is that you don't trust web servers but do trust the packages and repositories they give to you, then I guess this is true but that seems a little crazy given that the attacker can just change the website you're visiting to host a malicious package, and change the signature it verifies against.

> Of course, that signing key could also be compromised, but those are usually more tightly guarded than web servers,

Why is it reasonable to assume that? I don't think it is, at all. If their SSL certs are comprised, all bets are off.

> any reputable dev should have their key in a hardware enclave like yubikey or similar).

I suspect you will be very very very disappointed at the number of people who publish software that meet the criteria you've outlaid here.

Fundamentally, your argument is flawed right at the beginning because all the attacker needs to do is compromise the web server and change the installation instructions.

> Why is it reasonable to assume that? I don't think it is, at all. If their SSL certs are comprised, all bets are off.

I have no statistics to offer, but it does seem likely to me that TLS private keys gets compromised more frequently than software/package signing keys.

and the CA who signed the package isn’t a bad actor. But there are known bad actors in the ca-certificates list and worse yet they can sign any certificate.

You may trust them to produce legit software and have good intentions. But it's not really enough - It's hard to use reputation to divine someone's proficiency and diligence in operating a web server without getting it pwned and the published trojaned. Several dimensions of risk / trust are relevant here, and the distribution mechanism can address some of the opsec risks in a way that is transparent to the end user (you).

A platform like PyPI also increases chances of something like that getting detected after it happens, giving you a chance to react in a timely way.

curl | bash doesn't bother me because I do it like twice a year from sites I trust. On the otherhand, the node crowd uses "npx command" all the time where npx will download and execute code from the net. Unlike "curl | bash", "npx command" is something you're expected to do 10s or 100s of times a day. Each one of those times is a chance for you to have a typo and execute code from some randon source like if you type "npm commmand" or "npx comman" or "npx coomand" or "npx comman dargument", etc...

And in the end you could always do

    curl -o file.sh
    bash file.sh

No detection

Right, the point of the thought experiment is to inject malicious code only in cases where someone is piping directly to bash without reading it, and not in cases where they might have the opportunity to read it. So in that case you would not inject malicious code. That is correct for the exersize.

I hate it when I do that, look at the script and realize that the script itself curl | bash other scripts.

Unless there are other sane ways to install the project, I just put in on my blacklist and ignore it.

Reply on news.ycombinator.com