search

xiaojianwu / update-engine

Automatically exported from code.google.com/p/update-engine
Apache License 2.0
0 stars 0 forks source link

Hashing is not sufficient security for updater #3

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
Consider adding a mechanism where public/private keys are used to sign and 
validate (using 
openssl) the downloaded files. With just a hash, you are totally open to a 
man-in-the-middle 
attack.

Example validation:

openssl dgst -sha1 -binary < "/path/to/downloaded/image.dmg" | openssl dgst -ds
s1 -verify /path/to/public_key.pem -signature /path/to/signature.txt

Original issue reported on code.google.com by philippe...@gmail.com on 30 Sep 2008 at 12:00

GoogleCodeExporter commented 8 years ago 
The idea is that you would fetch the plist from the server over SSL to avoid 
the MiM. The hashing is simply to 
verify the integrity of the downloaded binary. The hash is not intended to 
solve the authentication issue; we use 
SSL for that.

Original comment by dev...@gmail.com on 30 Sep 2008 at 12:13

GoogleCodeExporter commented 8 years ago 
I'm going to mark this as a "won't fix" because I don't see anything that needs 
to be fixed at this point.

That said, Update Engine is very configurable and it can be configured to talk 
to any type of server. Right now 
the server it talks to is a "plist server" (KSPlistServer), but it could be 
configured to talk to a different server, 
say, one that encrypts the plist response using public key cryptography. In 
this case, the encrypted blob could 
be fetched from anywhere, it could be validated by Update Engine on the client 
side using the public key, and 
then the decrypted blob could be interpreted as a plist. This would all work 
without any modification to 
Update Engine itself.

Actually, we have a class that's very similar to this now. Maybe we'll try to 
add it to the available sources here. 
*Although*, I don't actually recommend it. Managing the public/private keys 
yourself will be much more 
cumbersome than using SSL. If possible, I'd recommend you just fetch the plist 
from an https URL and not 
worry about this.

Original comment by dev...@gmail.com on 30 Sep 2008 at 12:32

GoogleCodeExporter commented 8 years ago 
I don't think that using ssl to fetch the plist solves the mitm attack. The man 
in the middle could still be a 
fraudulent https url, complete with valid certificate, and the update-engine 
would not be the wiser. I believe you 
place too much trust on your servers :-)

I don't disagree if you don't want to fix it. I just wanted to raise the issue.

Original comment by philippe...@gmail.com on 30 Sep 2008 at 12:51

GoogleCodeExporter commented 8 years ago 
"I don't think that using ssl to fetch the plist solves the mitm attack. The 
man in
the middle could still be a fraudulent https url, complete with valid 
certificate"

How would an attacker obtain a valid certificate for a domain you own? The 
attacker
can't change the URL an application is contacting, so it's not enough to have 
some
random site with a valid cert, then need to have a valid cert for *your* domain.

Original comment by stuart.morgan on 30 Sep 2008 at 4:09

GoogleCodeExporter commented 8 years ago 
More info about Update Engine and security has been added to a wiki: 
http://code.google.com/p/update-
engine/wiki/UpdateEngineAndSecurity

Original comment by dev...@gmail.com on 1 Oct 2008 at 12:44