[adriancr]

curl|bash allow personalized attacks... If for example you have an IP address from a certain company. (if you have access to ad targeting data you can refine a lot further - just remember web site visits from an IP and match them to IP from curl command)

repos are mirrored, come with signing keys and any successful attacks are detected sooner or later and become public knowledge.

[rnijveld]

I wasn't arguing that official distro repositories are unsafe, I was actually saying user provided repos are almost as bad (or even worse in some ways, given that give the feeling of being way more secure) as `curl|bash`. Even if they are signed (such as AUR and PPA) most people will blindly add signing keys for people or organisations they do not know, giving them the feeling that they have secured themselves, but have they really?

I guess detecting attacks is easier if all files have to be uploaded to a central service, which does allow everyone to see the personalized attack (I mean adding `if (targetUser()) attackTarget()` isn't that hard, but it would be visible for everyone compared to doing that server-side). But then if I'm a sophisticated attacker I'd be sure to make that way less obvious in my code. My feeling is that it would be detected later rather than sooner if hidden well enough. And that is excluding things like non-official apt repositories.

[YetAnotherNick]

Is `curl raw.githubusercontent.com/.. | bash` fine for you? I think most of the curl | bash uses github master branch. Using your own domain is actually scary as owner have to be sure that they never lose control of them.

[adriancr]

I would never pipe something to bash.

Always download, inspect, run. (maybe even backup if something strange happens)

[Uehreka]

Really though? What are you looking for in this inspection?

This strikes me as one of those things where the “inspectors” underestimate the security of “curl|bash from a known HTTPS origin” and overestimate their ability to detect anything that could evade that security. At that point you’re dealing with a g0d level hacker, or your cert trust has been broken, and in either of those cases you were already pwned.

[adriancr]

I read the script and see if I like what I see.

As example: https://sh.rustup.rs It's really easy to read and useful to understand what it does.

If it's too obfuscated and I can't understand it I don't run it and look for other install options or give up

If I do spot bugs, I'll go to their github and provide a PR.

If I spot something malicious I'll check the github to see who put it in and raise the problem. (if it's not on github then alarm bells)

[oblio]

> repos are mirrored, come with signing keys and any successful attacks are detected sooner or later and become public knowledge.

1. Not all package managers come with signing keys or actually check them.

2. "Sooner or later" - weasel words. Some of these breaches have been discovered years after the fact. Who really cares if they get discovered after 3 years? By that point all the harm has been done plus the attacker could have taken control of the systems in more varied ways so even removing the initial entry point won't save you.

[adriancr]

> 1. Not all package managers come with signing keys or actually check them.

Seems like a very big problem with those package manager... Ubuntu as far as I'm aware does proper signing. (as any sane distro and hell, microsoft too)

I would not be using those package managers.

> 2. "Sooner or later" - weasel words.

What's your point?, I trust Ubuntu/Red Hat to keep their keys safe. I trust that google project zero and others would notice anything spooky.

I do not trust a random distro with only a few users to keep their keys safe and I do not use that.

It's also hard to do a proper attack when you have:

ubuntu -> (n) mirrors -> me

Ubuntu can't push a malicious package directed at me (I go via mirrors which can be picked at random)

Mirrors can't push a malicious package directed at me (they would need ubuntu signing keys, and someone would need to own all of them or be very lucky)

And if someone does compromise Ubuntu's keys, they're not going to go after me and risk getting detected that way.

There is a lot more security built into package managers then what I said compared to 0 you get on curl|bash.

[simiones]

That's true if you're using Ubuntu's repos. But a lot of software on Linux comes as a key that you need to tell apt to trust, and then a repo that uses that key. This is just as unsafe, if not more unsafe, than curl | bash - it gives me a way to not just send you malicious code today, but also any other time you apt upgrade.

[adriancr]

We are talking on an article that highlights a major flaw of curl|bash.

The website owner can determine if you are just downloading to investigate script or if you are downloading and running.

In the last scenario the owner can decide to give you bad code and you won't know what happened / can't prove that the website owner did anything to you.

With APT the owner cannot see which case it is in, someone can always investigate what is being published by just downloading a package.

Otherwise, as you noted - if you trust the wrong person you will get owned either way, but curl|bash is inherently more dangerous due to easy targeting.

(I can push a package in apt via curl|bash too so it gets upgrade regularly)

[mannykannot]

While this technique allows an attacker to avoid revealing the exploit if you simply redirect the curl output to a file, it will contain tell-tale information (in this case, bufferloads of zero bytes) allowing one to discern that it is up to no good.

The author hints at other techniques for detecting curl|bash (http or dns callbacks), which would obfuscate but not completely mask the attacker's intentions.

Note that I'm not advocating for using curl|bash: it's a technique for gathering low-hanging fruit, and there's no point in putting yourself in that position.

[adriancr]

Quick note - I've had this happen to me.

- browser crash

- I reload last website

- crash again

- I know that site has an exploit - so I try curl to get the payload - it's no longer there.

- I set up wireshark - open up in browser - exploit no longer there.

I'm now stuck with no way to figure out what happened, core dump is useful to prevent the crash but not find the code that triggered it.

So disconnect / fresh install OS.

This kind of targeting can happen now with curl|bash detecting if you install or just download.

[mannykannot]

It would require somewhat more sophistication on the attacker's part to detect curl|tee|bash being run in a VM, I think. Also, can you start bash with tracing on? Or put awk in the pipeline to turn it on, and also filter out attempts to turn it off?

[oblio]

Package managers include npm, bundler, maven, gradle, cargo, etc, not just distro ones.

[adriancr]

and those package managers need to have security built into them as well.

[corobo]

Anyone that dedicated would probably more likely bash you over the head with a rock until you give up your password

[adriancr]

why would they do that when they can run a script from halfway around the world and take profit without getting caught?

I'm thinking ransomware attacks, bitcoin mining farms set up on AWS accounts after stealing keys / racking up huge costs, bank account takeovers, stock market account takeovers...

Someone hitting you in the head is easier to avoid / easier to recover funds from. (and if you're in the US and have a gun, that person trying to hit you in the head is going to have a bad time)

[corobo]

I mean they'd more likely do that than target you personally with a curl|bash. That's a very noisy and blatant move, super unlikely to work on anyone techy enough to know what curl and bash is, probably the last resort. Other exploits are on the table and indeed much more likely too

[Ivoah]

https://xkcd.com/538/