Hacker News Reader

Comment by peanut-walrus | Hacker News Reader

Not to downplay this vulnerability, but I feel like relying on (valid tls cert+domain name) combination as the only line of defense for code paths which allow remote code exec is a recipe for disaster. At a minimum, if your application is downloading and executing some artifact from the internet, it should always be fixed to a particular version of the artifact and it should verify the hash of the downloaded artifact before executing.

View on HN

>At a minimum, if your application is downloading and executing some artifact from the internet, it should always be fixed to a particular version of the artifact and it should verify the hash of the downloaded artifact before executing.

so auto-updaters are out?

Gut instinct I was with you, but actually yes--there's some places I definitely want to be aware and/or involved when software updates and the torrent client is one of them. Not that it should force you to go download and install your own updates, I'd just prefer it to notify me and wait for approval.

Edit to note I don't quite agree with GP either, I see their point but cert-based security is pretty much the best we've got as far as I'm aware, likely what I'd use if designing this system.

A cryptographic signature (e.g. pgp) seems prudent. In addition to tls, I mean.

I think verifying a signature is the lowest bar. If you update the software often enough you should have plenty of chances to do key rotation.

On windows at least you can use a code signing certificate in your build tooling and ask the OS to verify any binaries that you download. Just make sure you use a timestamping server for your code signing or things will break when the certificate expires.

I think that would be challenging due to the nature of a potential man-in-the-middle attack here. An attacker could view and change contents of the request therefore making the hash check useless (other than for integrity)

Automatic updates and/or checks to a domain from a desktop app is a security angle that doesn't seem to be given as much attention overall. There are other scenarios like a hostile domain takeover (e.g. the original author stops renewing) which I haven't found a good solution to.

You can sign updates with an offline key (ideally like a hardware key), this is what APT based repositories do/allow

Sure, but how do you deal with expiration or revocation of that key? If someone is using an old version which doesn't know about the new key then you're back at square one right?

Linux package managers like apt and dnf deal with this as well. When a key is getting old, you generate a new key with an updated expiration and push it out using the old key to verify it.

If the old key expires before a new key is delivered, then you have a problem. This has happened to me a few times and it is a pain in the butt. You basically have to disable key checking in order to receive the new key, which breaks the security.

I would say it doesn't break it, it means you must manually inspect it to verify it Is indeed a key being published from the source you expect. But that's kind of the point right? If automated checks don't work, then you have to rely on the user doing a manual inspection.

A good solution to this is to have multiple roles and use threshold signatures: https://theupdateframework.io/

Reply on news.ycombinator.com