[Project_owners] XPI install still vulnerable to MITM attacks on mozdev.org
Douglas E. Warner
silfreed at silfreed.net
Wed Jul 18 05:30:02 PDT 2007
On Wednesday 18 July 2007, Michael Vincent van Rantwijk, MultiZilla wrote:
> XPI installations initiated from mozdev.org will still be vulnerable to
> MITM attacks... when the XPI isn't *installed* originally from a SSL
> protected server!
> a.m.o is secure, so in that case you can get away with simply signing
> your updates, but each new installation will still be vulnerable to MITM
> attacks, and this will be the next step in this process... to prevent
> you from installing XPI's from insecure http: connections.
> Why is this so hard to understand?
AMO does not provide SSL downloads for it's releases either - it's in the
exact same boat as Mozdev.org is.
(Try for yourself - Addons hosted by AMO are served from
http://releases.mozilla.org/pub/mozilla.org/addons/; you won't be able to use
the HTTPS version).
This is simply a logistical problem due to both organizations relying on
public mirrors for distributing its bandwidth. We can't reasonably expect
these mirrors to support the additional cost of an SSL cert or CPU overhead
of running SSL.
We do understand that the initial process of installing an XPI is susceptable
to a MITM attack, but so far this part has been deemed less important by
Mozilla since it is a user-initiated action and they are prompted for it to
continue, whereas the automatic updates process was not user initiated
therefor could be more easily intercepted.
The exploit you listed was specifically for the update process because it is
much easier to predict - a user installing some random extension is not very
easy to exploit since it's much harder to predict.
Since the updates.rdf file is signed by the same key installed with the XPI
originally and the XPIs referenced in the updates.rdf file have hashes of the
files stored in the updateHash element, the updates process will be safe from
MITM attacks. This has been Mozilla's (not Mozdev's) primary concern for
Firefox 3 - and the one most easily supported without requiring developers
get code-signing certs.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mozdev.org/pipermail/project_owners/attachments/20070718/208b13ed/attachment.bin
More information about the Project_owners