"minutely external verification of the download packages"

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

"minutely external verification of the download packages"

Jonathan Watt-3
Do we have systems in place to stop this sort of thing from happening:

http://wordpress.org/development/2007/03/upgrade-212/
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: "minutely external verification of the download packages"

Gervase Markham
Jonathan Watt wrote:
> Do we have systems in place to stop this sort of thing from happening:
>
> http://wordpress.org/development/2007/03/upgrade-212/

You mean apart from those normal security mechanism (passwords etc.)
which prevent random people uploading builds to our download servers? :-)

The article linked above mentions a problem, but not an attack vector.
Did you have one in mind?

Gerv
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: "minutely external verification of the download packages"

Michael Lefevre
On 2007-03-05, Gervase Markham <[hidden email]> wrote:

> Jonathan Watt wrote:
>> Do we have systems in place to stop this sort of thing from happening:
>>
>> http://wordpress.org/development/2007/03/upgrade-212/
>
> You mean apart from those normal security mechanism (passwords etc.)
> which prevent random people uploading builds to our download servers? :-)
>
> The article linked above mentions a problem, but not an attack vector.
> Did you have one in mind?

Well, it seems that someone somehow got user-level access to one of their
download servers.  Given the quantity and diversity of Mozilla download
mirrors, I imagine it would be pretty hard for Mozilla to directly keep
track of the security of every download server (but correct me if I'm
wrong).

I guess the questions to answer would be what steps Mozilla takes to
ensure that the mirrors are managed well by the third parties that manage
them, and, in the event that a mirror somewhere got hacked, is there some
system in place to protect people from getting bad stuff.

I guess answers to that may include the Windows builds being signed, md5
checksums (although if the place to get those is just from ftp mirrors
that doesn't help much - are they on the website or a non-mirrored host?),
and maybe even what you blogged about
http://weblogs.mozillazine.org/gerv/archives/2007/03/wordpress_download_tarball_com.html

--
Michael
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: "minutely external verification of the download packages"

Gervase Markham
Michael Lefevre wrote:
> I guess the questions to answer would be what steps Mozilla takes to
> ensure that the mirrors are managed well by the third parties that manage
> them, and, in the event that a mirror somewhere got hacked, is there some
> system in place to protect people from getting bad stuff.

This is probably not the right group for these questions; try
mozilla.dev.build or something similar. I don't know if the IT team has
a newsgroup to call its own.

Gerv
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: "minutely external verification of the download packages"

Daniel Veditz
Gervase Markham wrote:
> Michael Lefevre wrote:
>> I guess the questions to answer would be what steps Mozilla takes to
>> ensure that the mirrors are managed well by the third parties that manage
>> them, and, in the event that a mirror somewhere got hacked, is there some
>> system in place to protect people from getting bad stuff.
>
> This is probably not the right group for these questions;

This probably is the right group. We do several things, we can probably do
more.

1) the bits are signed. People generally don't check, but they are. When
you download the windows version using IE you are presented with a dialog
showing the MoCo signature, would be nice to do that from Firefox as well
(we could put some platform-specific code in to call the sig-checking
windows APIs).

On other platforms people would have to have GPG to check the detached
sigs, and/or hash-checking utilities.

2) we publish the md5 and sha1 sums of all the bits. Again people don't
generally check, but it's there.

3) "Bouncer" is supposed to re-download the bits periodically and validate
them. I don't think this feature is being used yet and it's going to put a
big load back on us. Doesn't help against a malicious server -- they'd be
able to figure out our IP range and return the right bits -- but would help
prevent someone hacking into a mirror and dropping a hacked version of the
file.

updates are somewhat more secure. The update.xml file is served over SSL
from our own mozilla server (on the down side that makes it a single point
of failure). The update.xml includes a hash of the .mar files the client
will download from the mirrors and that hash is verified before applying
the update. I think we're currently using SHA1 for the hash, we should
switch to SHA-256 or something better.

Addons are also served from our mirror network. If you get the file from
AMO itself by clicking on the Install Now link and have not disabled
JavaScript then AMO sends a hash to the client and the downloaded file is
verified before installing. .xpi files can also be signed but none actually
are AFAIK, and unless they were all signed by Mozilla--which we're
reluctant to do since we didn't write them--it'd be hard for users to
distinguish between stuff signed by the right author and stuff with a valid
signature from the wrong author. The hash at least says it's the file AMO
intended to serve.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security