Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
Re: [Full-disclosure] Perforce client: security hole by design
From: Dave \ (davek_throwawayhotmail.com)
Date: Mon Jan 08 2007 - 08:43:42 CST
Ben Bucksch wrote:
> Anders B Jansson wrote:
>> I'd say that it's a design decition, not sure that it's a design
>> 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?
Can't think of a witty .sigline today....
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia - http://secunia.com/