You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by "Dennis E. Hamilton" <or...@apache.org> on 2013/04/29 19:31:14 UTC
RE: Proposal: Improve security by limiting committer access in SVN -- KEYS Compromise Exposure
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:pescetti@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-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
Re: Proposal: Improve security by limiting committer access in SVN --
KEYS Compromise Exposure
Posted by Kay Schenk <ka...@gmail.com>.
On Tue, Apr 30, 2013 at 5:59 AM, Daniel Shahaf <da...@apache.org> wrote:
> (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
>
Thanks Daniel -- copying private@openoffice on this reply so the PMC makes
note of this.
> > (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
>
>
--
----------------------------------------------------------------------------------------
MzK
"There's no upside in screwing with things you can't explain."
-- Captain Roy Montgomery, "Castle"
Re: Proposal: Improve security by limiting committer access in SVN
-- KEYS Compromise Exposure
Posted by 'Daniel Shahaf' <da...@apache.org>.
(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
Re: Proposal: Improve security by limiting committer access in SVN -- KEYS Compromise Exposure
Posted by Dave Fisher <da...@comcast.net>.
On Apr 29, 2013, at 6:56 PM, Dennis E. Hamilton wrote:
> @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 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? (Note that it is the binaries that are compromised, there is no messing with the source tarballs.)
When I vote on a release I am looking at the fingerprint. This is where looking for a fingerprint that is on the "Web of Trust" is important.
http://people.apache.org/~henkp/trust/
I like Henk's opinion here:
> what can I trust, ultimately ?
>
> The short answer is nothing.
> For the ultra sceptics there is no hope.
>
> • you can't trust the things you did yesterday, because you can't trust your memory
> • you can't trust software you didn't write or hardware you didn't build
> • you can't overlook the possibility that apache.org is a fake, set up especialy to lure you into using bad software
>
Regards,
Dave
>
> - 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
RE: Proposal: Improve security by limiting committer access in SVN -- KEYS Compromise Exposure
Posted by "Dennis E. Hamilton" <or...@apache.org>.
@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 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? (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
Re: Proposal: Improve security by limiting committer access in SVN
-- KEYS Compromise Exposure
Posted by Daniel Shahaf <da...@apache.org>.
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