Today, I did some digging around with respect to a different project and I 
noticed a vulnerability that had not been discussed:

 1. Assume that the credentials of an Apache OpenOffice Committer are 
compromised (or the committer goes rogue).
 2. This allows the compromised/rogue credentials to be used to change the 
forwarding e-mail address and add/replace the PGP public key fingerprint of the 
committer.
 3. A rogue public key will then end up in 
<https://people.apache.org/keys/group/openoffice.asc>.  This is the file that 
users are instructed to import keys from in order to check signatures on AOO 
releases and binary distributions.  See 
<http://www.openoffice.org/download/checksums/3.4.1_checksums.html#howto>.
 4. Note that all Apache OpenOffice committers who have provided PGP 
fingerprints will have their public key show up in that file.  Not just release 
managers, *all* AOO committers who have provided PGP fingerprints.
 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.  

I don't think this is a high risk vulnerability.  There are too many easier 
ways to distribute counterfeit binaries.  The use of OS-verified code signing 
(for Windows and Apple builds, at least) will mitigate all of them to the 
extent that users come to rely on and be vigilant about signed installs.

 - Dennis

-----Original Message-----
From: Andrea Pescetti [mailto:pesce...@apache.org] 
Sent: Thursday, April 04, 2013 10:44
To: dev@openoffice.apache.org
Subject: Re: Proposal: Improve security by limiting committer access in SVN

Rob Weir wrote:
> On Thu, Apr 4, 2013 at 11:57 AM, Andrea Pescetti wrote:
>> 2) The only possible solution would be an authz rule like suggested by
>> Dave here; however, Infra quite discourages it, mainly for maintenance
>> reasons. This leads me to think we would need some good justifications for
>> implementing this.
> Would Infra need to maintain the authz , or would that be something that
> you do?

According to Infra, it's something that I can manage directly, even 
though I've never looked into this recently (I just needed to make some 
changes immediately after graduation). And I'm available to take care of 
this if there is consensus on making write access to /trunk (and other 
subtrees) optional.

Regards,
   Andrea.

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


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

Reply via email to