openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From 'Daniel Shahaf' <danie...@apache.org>
Subject Re: Proposal: Improve security by limiting committer access in SVN -- KEYS Compromise Exposure
Date Tue, 30 Apr 2013 12:59:44 GMT
(note CC list)

Dennis E. Hamilton wrote on Mon, Apr 29, 2013 at 18:56:01 -0700:
> @Daniel,
> 
> Right, this is about poisoning the committer keys but not touching the
> SVN, instead, counterfeiting a binary release downstream, but faking
> the asc, md5, and sha1 too.  (These would not be at dist, and depend

ASF mirrors do not contain .asc, .md5, .sha1 files.  We should probably
verify that in our regular checks, if we don't do so already.

Assuming "real mirrors have no .md5/.asc files" holds, assuming a user
downloads a rogue .md5 means either the user is using a rogue download
page or there's a rogue .md5 in https://www.apache.org/dist/openoffice/
--- these are both acceptable risks (the latter because it will have
generated a commit mail which the PMC is supposed to catch).

> on folks not noticing because the instructions for how to check
> correctly are so obscure.  It is very far-fetched, since there are
> easier exploits that rely on user's not being equipped to verify what
> they are getting and not relying on the authentic download location.
> 

> Another way would be to attack the release candidate in the release
> manager's ASF FreeBSD account, although someone who checks the
> signature might notice that it is by an unexpected committer.  Again,
> reasonably far-fetched.  Two committers would have to be compromised,
> or the Release Manager would have to be compromised and not notice
> that there is a new fingerprint in the RM's profile.  I like that last
> one.  It has a certain movie-plot plausibility.  Who ever looks for
> funny business in their profile, or odd materials in their keys entry?

Everyone.  The PMC is REQUIRED to verify the .asc files in a release
before voting on it.  That means verifying it's signed by the correct
key, too.

Daniel

> (Note that it is the binaries that are compromised, there is no
> messing with the source tarballs.)
> 
>  - Dennis
> 
> -----Original Message-----
> From: Daniel Shahaf [mailto:danielsh@apache.org] 
> Sent: Monday, April 29, 2013 15:58
> To: Dennis E. Hamilton
> Cc: dev@openoffice.apache.org; pescetti@apache.org
> Subject: Re: Proposal: Improve security by limiting committer access in SVN -- KEYS Compromise
Exposure
> 
> Dennis E. Hamilton wrote on Mon, Apr 29, 2013 at 10:31:14 -0700:
> >  5. This is sufficient to poison a download mirror site with
> >  a counterfeit download so long as the ASC, SHA1, and MD5 locations
> >  can also be spoofed without the user noticing.  
> 
> Right.  The normal answer here is "They will have to commit to the dist/
> repository which will cause a post-commit mail which someone will
> notice".  I'd be interested in hearing (on infra-dev@) how you break
> this without assuming a mirror gets compromised (if _that_ happens,
> it's game over for users who don't verify PGP sigs).
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org


Mime
View raw message