Re: Perforce client: security hole by design

["Dave \"No, not that one\" Korn" <davek_throwaway () hotmail com>]

Ben Bucksch wrote:
> Anders B Jansson wrote:
> > I'd say that it's a design decition, not sure that it's a design
> > flaw.
> > It's all down to what you try to protect.
> > ... connecting any device not 100% controlled by the company to a
> > company network is strictly forbidden, doing so would be regarded as
> > intended sabotage.
>
> OK, so this bug is not a problem in your company or some Perforce
> setups. That's fine. However, I hope it was clear from my description
> that it's *not* fine in other cases:

  I think it's a bad enough design flaw to call a bug, or at any rate a 
wide-open security hole.  The client should not alter anything that is not 
*below* the current working directory where it's invoked from.  This is 
exactly the same bug as path traversal on webservers or in (un)archiving 
programs, all of which have been fixed to prevent "../.." and absolute paths 
from being allowed; exactly the same reasoning applies to p4.

> I understand the reasoning of Perforce's design, and I understand that
> most companies think that their *own* servers are fine and never pose
> a problem to *anybody*, why *would* they, but that's just not a valid
> assumption for the rest of the world.

  This is always an *assumption*, and for that reason it's bad. 
Defense-in-depth says neither end should "just trust" the other.

  I don't use p4 myself, but wouldn't running the client in a chroot'd 
sandbox be the quickest way to use it safely in these circumstances?

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today.... 



_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/