Jump to content

Program updater


pck1980
 Share

Recommended Posts

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...

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...