Program updater

[pck1980]

With the release of the latest update, I realized that the updater of AIDA64 downloads the update via http, not https. As this would theoretically allow for man-in-the-middle attacks, I'd like to know whether the updater ensures that the correct update is downloaded and applied, e.g. by verifying its digital signature.

EDIT: I accidentally posted this in the wrong forum - perhaps someone can move the thread to "General discussions" or wherever it seems to match best...

[Fiery]

Yes, our automatic update system verifies the CRC for the downloaded ZIP package before extracting it and moving the files to replace the old files.

Regards,
Fiery

[pck1980]

Thanks for your reply.

But CRC does not suffice to detect deliberate manipulation, e.g. if an attacker would provide his own ZIP package. This could be done by redirecting requests for the "official" download server to some other that is under the control of the attacker, e.g. in a public WiFi. While this probably isn't an attack vector that's exploited on a daily basis, I still think it is something that should be fixed.

[Fiery]

12 hours ago, pck1980 said:

Thanks for your reply.

But CRC does not suffice to detect deliberate manipulation, e.g. if an attacker would provide his own ZIP package. This could be done by redirecting requests for the "official" download server to some other that is under the control of the attacker, e.g. in a public WiFi. While this probably isn't an attack vector that's exploited on a daily basis, I still think it is something that should be fixed.

The CRC for the ZIP package is downloaded (acquired) from our update server, so it's not possible to manipulate the ZIP package.  The CRC is not part of the ZIP package at all, and it doesn't necesserily come from the same download server either.  We don't see a vulnerability there.

[pck1980]

If the CRC is also fetched via http, an attacker could redirect this request as well and provide the correct CRC for his own ZIP - unless you hardcoded the IP(s) of your server(s), which would make such a redirect more difficult (though probably not impossible).

And as CRC doesn't detect all errors, one could probably even craft a ZIP file with different content, but the same CRC. A cryptographic hash such as SHA256 would avoid this.

[Fiery]

On ‎2017‎. ‎06‎. ‎25‎. at 4:46 PM, pck1980 said:

If the CRC is also fetched via http, an attacker could redirect this request as well and provide the correct CRC for his own ZIP - unless you hardcoded the IP(s) of your server(s), which would make such a redirect more difficult (though probably not impossible).

And as CRC doesn't detect all errors, one could probably even craft a ZIP file with different content, but the same CRC. A cryptographic hash such as SHA256 would avoid this.

When I said CRC above, I meant hash (SHA).