4 ms·

Can someone explain how this is a security problem? While GPG key verification would be the best way to ensure authenticity, it's doing nothing different from w

Can someone explain how this is a security problem? While GPG key verification would be the best way to ensure authenticity, it's doing nothing different from what almost everyone does: download the ISO from the distro's own HTTPS site. It then goes beyond what most people do and validates that the hashes matche.

repelsteeltje 3y ago
Absolutely true, but one additional factor (or vector) is that this adds a level of indirection. That is, you're trusting the Quickemu people to take the same diligence you yourself would do when downloading an ISO from, say ubuntu.com for each and every target I can conveniently install with Quickemu. It's a subtle difference, but the trust-chain could indeed be (mildly) improved by re-distributing the upstream gpg keys.
- Joker_vD 3y ago
  Eh, you can fetch the GPG keys from some GPG keyserver, it's not like those keys are just random files from the Internet. They're cross-signed, after all!
  - IshKebab 3y ago
    How do you know which keys to get? Let me guess... you read their website.
st3fan 3y ago
Because you wrote HTTPS in italic .. HTTPS doesn't mean anything. Both the good and bad actors can have perfectly valid HTTPS configured. It is not a good indicator of trustworthiness of the actual thing you download.
- hn_throwaway_99 3y ago
  > HTTPS doesn't mean anything. That's not accurate at all. HTTPS should mean "we've validated that the content you're receiving comes from the registered domain that you've hit". Yes, it's possible that the domain host itself was compromised, or that the domain owner himself is malicious, but at the end of the day you have to trust the entity you're getting the content from. HTTPS says, importantly, "You're getting the content from whom you think you're getting it from."
  - electroly 3y ago
    > HTTPS says, importantly, "You're getting the content from whom you think you're getting it from." You need certificate pinning to know this for sure, due to the existence of MITM HTTPS spoofing in things like corporate firewalls. HTTPS alone isn't enough; you have to confirm the certificate is the one you expected. (You can pin the CA cert rather than the leaf certificate if you want, if you trust the CA; that still prevents MITM spoofing.)
    - brirec 3y ago
      I’m not aware of any HTTPS MITM that can function properly without adding its own certificate to the trusted roots on your system (or dismissing a big red warning for every site), so I don’t think certificate pinning is necessary in such an environment (if the concern is MITM by a corporate firewall). An attacker would still need to either have attacked the domain in question, or be able to forge arbitrary trusted certificates.
    - yjftsjthsd-h 3y ago
      If an attack requires compromising my operating system certificate store, I'm reasonably comfortable excluding it from most of my threat models.
      - electroly 3y ago
        Obviously you choose your own relevant threat models, but it's common to do in iOS apps--many apps are including it in their threat models. Pinning the CA cert is what Apple recommends to app developers. It's not an unreasonable thing to do. https://developer.apple.com/news/?id=g9ejcf8y https://developer.apple.com/news/?id=g9ejcf8y
JeremyNT 3y ago
IMO you're exactly right. I just looked at the shell script and it's not "random" at all, it's getting both the checksum and the ISO from the official source over TLS. The only way this technique is going to fail is if the distro site is compromised, their DNS lapses, or if there's a MITM attack combined with an incorrectly issued certificate. GPG would be more robust but it's hardly like what this tool is doing is some unforgivable failure either. It's not that the OP is wrong but I think they give a really dire view of what's happening here.
EasyMark 3y ago
Trust is an input into any security equation. Do you trust all sources of these files? I don't think anyone was challenging gpg
npteljes 3y ago
Getting the signature and the file from the same place is questionable practice in itself. If the place is hacked, then all the hacker needs to do is to just hash his own file, which has happened in at least one high profile case [0]. And this practice doesn't even offer any extra protection if the resource was accessed with HTTPS in the first place. [0] https://www.zdnet.com/article/hacker-hundreds-were-tricked-into-installing-linux-mint-backdoor/ https://www.zdnet.com/article/hacker-hundreds-were-tricked-i...
funcDropShadow 3y ago
> It then goes beyond what most people do and validates that the hashes matche. It might go above and beyond what most people are doing, but not what most tools are doing. Old school package managers are still a step ahead in this area, because they use GPG to check the authenticity of the data files, independent of the transportation channel. A website to download files and checksums is one such channel. This enables supporting multiple transportation channels, then it was a mirror of ftp mirrors. Today, it might be bittorent or ipfs or a CDN. And GPG supports revoking the trust. Checksums that are hardcoded into a tool cannot be revoked. As soon as we start to codify practices into tools, they become easier to game and attack. Therefore tools should be held to higher security standards than humans.
fsflover 3y ago
https://www.qubes-os.org/security/verifying-signatures/#what-digital-signatures-can-and-cannot-prove https://www.qubes-os.org/security/verifying-signatures/#what...
Zuiii 3y ago
I wouldn't be sure about most. I and everyone I worked with took gpg verification seriously. I always verify isos. Always. People who are responding to you with "you are absolutely right" might not represent the silent majority (within our field, not talking about normal users).

repelsteeltje 3y ago

Absolutely true, but one additional factor (or vector) is that this adds a level of indirection. That is, you're trusting the Quickemu people to take the same diligence you yourself would do when downloading an ISO from, say ubuntu.com for each and every target I can conveniently install with Quickemu. It's a subtle difference, but the trust-chain could indeed be (mildly) improved by re-distributing the upstream gpg keys.

Joker_vD 3y ago
Eh, you can fetch the GPG keys from some GPG keyserver, it's not like those keys are just random files from the Internet. They're cross-signed, after all!
- IshKebab 3y ago
  How do you know which keys to get? Let me guess... you read their website.

st3fan 3y ago

Because you wrote HTTPS in italic .. HTTPS doesn't mean anything. Both the good and bad actors can have perfectly valid HTTPS configured. It is not a good indicator of trustworthiness of the actual thing you download.

hn_throwaway_99 3y ago
> HTTPS doesn't mean anything. That's not accurate at all. HTTPS should mean "we've validated that the content you're receiving comes from the registered domain that you've hit". Yes, it's possible that the domain host itself was compromised, or that the domain owner himself is malicious, but at the end of the day you have to trust the entity you're getting the content from. HTTPS says, importantly, "You're getting the content from whom you think you're getting it from."
- electroly 3y ago
  > HTTPS says, importantly, "You're getting the content from whom you think you're getting it from." You need certificate pinning to know this for sure, due to the existence of MITM HTTPS spoofing in things like corporate firewalls. HTTPS alone isn't enough; you have to confirm the certificate is the one you expected. (You can pin the CA cert rather than the leaf certificate if you want, if you trust the CA; that still prevents MITM spoofing.)
  - brirec 3y ago
    I’m not aware of any HTTPS MITM that can function properly without adding its own certificate to the trusted roots on your system (or dismissing a big red warning for every site), so I don’t think certificate pinning is necessary in such an environment (if the concern is MITM by a corporate firewall). An attacker would still need to either have attacked the domain in question, or be able to forge arbitrary trusted certificates.
  - yjftsjthsd-h 3y ago
    If an attack requires compromising my operating system certificate store, I'm reasonably comfortable excluding it from most of my threat models.
    - electroly 3y ago
      Obviously you choose your own relevant threat models, but it's common to do in iOS apps--many apps are including it in their threat models. Pinning the CA cert is what Apple recommends to app developers. It's not an unreasonable thing to do. https://developer.apple.com/news/?id=g9ejcf8y https://developer.apple.com/news/?id=g9ejcf8y

JeremyNT 3y ago

IMO you're exactly right. I just looked at the shell script and it's not "random" at all, it's getting both the checksum and the ISO from the official source over TLS. The only way this technique is going to fail is if the distro site is compromised, their DNS lapses, or if there's a MITM attack combined with an incorrectly issued certificate. GPG would be more robust but it's hardly like what this tool is doing is some unforgivable failure either. It's not that the OP is wrong but I think they give a really dire view of what's happening here.

EasyMark 3y ago

Trust is an input into any security equation. Do you trust all sources of these files? I don't think anyone was challenging gpg

npteljes 3y ago

Getting the signature and the file from the same place is questionable practice in itself. If the place is hacked, then all the hacker needs to do is to just hash his own file, which has happened in at least one high profile case [0]. And this practice doesn't even offer any extra protection if the resource was accessed with HTTPS in the first place. [0] https://www.zdnet.com/article/hacker-hundreds-were-tricked-into-installing-linux-mint-backdoor/ https://www.zdnet.com/article/hacker-hundreds-were-tricked-i...

funcDropShadow 3y ago

> It then goes beyond what most people do and validates that the hashes matche. It might go above and beyond what most people are doing, but not what most tools are doing. Old school package managers are still a step ahead in this area, because they use GPG to check the authenticity of the data files, independent of the transportation channel. A website to download files and checksums is one such channel. This enables supporting multiple transportation channels, then it was a mirror of ftp mirrors. Today, it might be bittorent or ipfs or a CDN. And GPG supports revoking the trust. Checksums that are hardcoded into a tool cannot be revoked. As soon as we start to codify practices into tools, they become easier to game and attack. Therefore tools should be held to higher security standards than humans.

fsflover 3y ago

https://www.qubes-os.org/security/verifying-signatures/#what-digital-signatures-can-and-cannot-prove https://www.qubes-os.org/security/verifying-signatures/#what...

Zuiii 3y ago

I wouldn't be sure about most. I and everyone I worked with took gpg verification seriously. I always verify isos. Always. People who are responding to you with "you are absolutely right" might not represent the silent majority (within our field, not talking about normal users).