3 ms·
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 r
by peanut-walrus 2y ago
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.
- hypeatei 2y agoI 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.
- dinosaurdynasty 2y agoYou can sign updates with an offline key (ideally like a hardware key), this is what APT based repositories do/allow
- hypeatei 2y agoSure, 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?
- freedomben 2y agoLinux 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.
- Sleaker 2y agoI 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.
- ramchip 2y agoA good solution to this is to have multiple roles and use threshold signatures: https://theupdateframework.io/ https://theupdateframework.io/
- gruez 2y ago>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?
- xelamonster 2y agoGut 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.
- im3w1l 2y agoA cryptographic signature (e.g. pgp) seems prudent. In addition to tls, I mean.
- bjoli 2y agoI 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.
- Negitivefrags 2y agoOn 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.