On Wed, Apr 3, 2013 at 5:02 PM, Dennis E. Hamilton <orc...@apache.org>wrote:
> My sense of this is that there is a desire to reduce the "threat surface" > of the SVN by requiring committers to opt-in. (I assume there is some way > to decide which committers to grandfather.) Apparently, that is a one-time > act and it doesn't alter being relatively inactive. So I guess this will > have to be a periodic ceremonial requirement. > > I take it that this means an attacker breaks into an existing committer's > account in some manner, impersonating that committer in a manner that (1) > the committer doesn't notice (possible) and that (2) it doesn't attract > attention on the commit logs (i.e., CTR fails at R). It seems to me that > new activity by an inactive committer (that orcmid fellow, for example) > would be noticed and it would be difficult to do anything that looked > suspicious. (Orcmid did make a commit recently, but it was to fix > something on the web site and it was done via the CMS.) > > I also don't understand how phishing would work. I can't imagine > receiving anything that requires me to use my @apache credentials anywhere > without attracting great concern. If there's a successful > Man-in-the-Middle exploit against the SVN, it is not the inactive > committers that are going to be hacked. > And I can't imagine that you would fall for a phishing attack either. I'm not thinking of you. But remember, when we first started as a poding we handed out a committer rights to anyone who had a pulse. Every one of their accounts has exactly the same permission set yours does. This is not the place to teach hacking, but getting 5-10% of committers to enter their Apache credentials into a webform linked to by a spoofed email purporting to come from a trusted party would be rather easy, -Rob > > As far as I know, the only successful attacks against the ASF (and Apache > committers) involved compromising servers and stealing password hashes, > making them vulnerable to off-line password discovery. The mitigation > seems to have worked. > > I think an use it or lose it approach to committer authorization might be > more effective. It won't get the account off the books (as far as I know), > but it would shrink the authz surface of the individual project code base. > Fortunately, that will not disturb the bugzilla or authorization to edit > on Planet Apache, afaik. > > - Dennis > > -----Original Message----- > From: Rob Weir [mailto:robw...@apache.org] > Sent: Wednesday, April 03, 2013 13:17 > To: dev@openoffice.apache.org; <orc...@apache.org> > Subject: Re: Proposal: Improve security by limiting committer access in SVN > > [ ... ] > It is not about trusting the committers. It is about reducing the > exposures to hackers. Trust of the committer has nothing to do with it. > Every active authorization in SVN is a vulnerable opening for a hacker, who > can gain access, via any number of phishing methods in common use today. > It us only prudent that a committer not have that authorization unless they > are using it. > > -Rob > > > [ ... ] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
