Hacker News Reader

Comment by Tepix | Hacker News Reader

You lost me right there. No checksum, no digital signature - if your server gets hacked, so do your customers.

Why don't you use your github releases in the installation instructions?

Since it's HTTPS, a signature or checksum are pretty pointless, TLS will do the certificate checking and encryption for you.

Your assertion that "if your server gets hacked, so do your customers", also applies to a checksum, as the hackers would just change the checksum listed on the website.

If you have a problem with piping curl to bash, then you can just not do so, you can download the bash script, see what it does, and modify it before running it. It's only 140 lines and it's fairly simple.

Further to your point, the bash script also does checksums internally!

Putting releases up on github isn't a bad idea, but their github account credentials could also be hacked, so it's no more secure than this really.

I don't understand your first paragraph. Could you elaborate?

curl will error out if the chain of trust is invalid, unless you override it with the -k option.

Guess what, all you need to prove in order to get a new "valid" cert is that you control the server. And, if you control the server then you already have access to the original certificates, so you probably don't even need new certs.

Since it's HTTPS, a signature or checksum are pretty pointless, TLS will do the certificate checking and encryption for you.

Serving the file over HTTPS is good because it means no one can do a man in the middle attack to change it, but it's not enough to be secure. If someone compromises the server itself the file could be altered at the source. The point of the checksum is to ensure that the file you're downloading is the file you're expecting. If you host the file in one place and the website in a different place it's harder for an attacker to change both the file and the website that reports the checksum, so you can be much more confident the file is correct. HTTPS on it's own doesn't give you that.

> If you host the file in one place and the website in a different place it's harder for an attacker to change both the file and the website that reports the checksum, ...

That is not a practical solution at all. What do users find if they enter the "download" page? A link to an external site containing the checksum? Wouldn't an attacker just replace (or remove!) the link?

The reality of today's identity management is TLS and certificates. If your website is https://oya.sh, then obviously any attacker who has access to the web server can direct clients to their malware downloads. No extra servers will help against that.

Perhaps not practical, but I could see this as one actually useful example of how a blockchain-style distributed ledger could be used. Have two accounts, one posts the binaries, another posts the checksums. That way one account breach doesn't compromise the whole thing, and the ledger could prove the history, etc.

Agreed. There could be better solutions than the current reliance on X.509 certificates and TLS, for example a blockchain solution like you propose.

But the fact that these solutions do not exist or at least aren't commonplace, makes the criticism to Oya in this regard rather awkward. They are doing what everybody does for their downloads: Relying on the certificate chain.

A link to an external site containing the checksum? Wouldn't an attacker just replace (or remove!) the link?

It wouldn't need to be an external site. You can have more than one server running a domain, with a different set of keys (entirely different architecture if you want) to make hacking both harder.

I still don't really see how this makes hacking harder. An attacker needs to replace the information presented to the user in order to download the software. For instance, the "download" link, or the paragraph describing the download/checksum procedure.

This always originates from one spot for one user. You can spread among users, but you can not spread a single html snippet over machines in a way that a hacker couldn't replace the "root" html snippet.

If someone compromises the server itself there's basically no form of security from that point that would help. The attacker could just put anything on the downloads page, including a new checksum for the compromised download. Nothing is safe if the server falls into malicious hands, but TLS is much easier for both the user and the website host when compared to a checksum, so that's probably the best decision for this kind of system.

The only time where I'd recommend a checksum over TLS is when you're dealing with a very large download, like a Linux ISO or something. The TLS encryption would cause a noticeable slowdown, so in that case a checksum may provide the best user experience.

A blog on this general attitude: https://sandstorm.io/news/2015-09-24-is-curl-bash-insecure-p...

The difference between a digital signature and HTTPS for identity verification is probably somewhat of a toss-up, and a checksum hosted on the same server as the download is mostly useless for anything but ensuring your download of the malicious version completed successfully.

Thanks, good read. :)

I recall two other popular projects doing the curl xyz| bash approach

Rust[0] Chef [1]

And here is an old HN comment[2] going into why it doesn't really matter.

Besides it's a Show HN- why be negative when we can raise the same issue more constructively as "Please add checksums and digital signatures. Also why not use regular GitHub releases in the installation instructions?"

[0] https://doc.rust-lang.org/book/ch01-01-installation.html [1] https://docs.chef.io/install_omnibus.html [2] https://news.ycombinator.com/item?id=12766049

RVM requires GPG keys which is the way to do it properly: https://rvm.io/

Exactly. A hash to verify the authenticity of the file / binary itself is what’s missing. Https is not enough.

Brew

I really recommend pipethis [1] for these scenarios. It's based on public-key cryptography, so an attacker who gains control of the server can't just update the hash (hosted on the same server).

[1] https://github.com/ellotheth/pipethis

Security concerns aside, a misconfigured gateway in between (say, they use Cloudflare) can easily result in an “HTML” response being piped to my bash. The f-ing mess it could create in my home directory is unimaginable.

Really. I didnt know that was realistically possible. Do you have an example payload to create such a mess?

If their GitHub account gets hacked, so do their customers. What's the fundamental difference?

You have the download at github and the checksum at you webserver. Same effort, but now attackers would have to have both services compromised to plant a malicious download.

So you refuse to download and install any executable unless it's served over https from one source and matches a checksum listed on a different source?

And the argument here is that if you don't do that, you're shit at security?

No, I've said "Same effort, but now attackers would have to have both services compromised to plant a malicious download"

It's already on GitHub, the shell script is just a wrapper to handle automating the download and install of the latest release.

Running random automated scripts from the web is not a good idea

Like 95% of websites with JavaScript? :)

No, because JS runs in the browser sandbox and has no access to the rest of your machine. That's very different to running a bash script from curl.

It's not meaningfully different than downloading software with an installer/install script and running it on your machine. Though obviously, you could just curl it, read it, and then bash it.

A docker image would be much better than a random script.

Why? Then you have to run the whole thing in Docker. That's a wholly unnecessary extra dependency.

Besides, this modality of installation already has precedent with Brew and Rust.

I'm talking about the cryptographically verified part. Either you are using a package manager to manage versions, roll back, lock versions,etc.

Or you use docker.

Not entirely sure if a standalone script with no versioning is the best way to do this in day and age.

Reply on news.ycombinator.com