bugtraq - Re: Perforce client: security hole by design

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 5 Jan 2007 14:34:56 +0000
From: The Fungi <fungi@...goth.org>
To: bugtraq@...urityfocus.com
Subject: Re: Perforce client: security hole by design

On Thu, Jan 04, 2007 at 08:03:34PM +0100, Ben Bucksch wrote:
[...]
> = Proposed fix =
> 
> The problem at hand could be easily fixed by letting the client check 
> out only in the current directory (or one specified by the user on the 
> commandline or GUI, preferences stored locally), no matter what the 
> server says. It may put files anywhere underneath that directory, but 
> never higher or otherwise outside. It must never adhere to absolute 
> paths from the server. This does require some changes to how client 
> specs work, though.
[...]

Having not used the product, it's hard to say, but it sounds like
chrooting the client differently for each project on which you're
using it would be a suitable hack to provide a workaround, if a
slightly inefficient one. Of course, I agree this is no substitute
for fixing the application design (and likewise the behavior of the
developers responsible).
-- 
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fungi@...goth.org); IRC(fungi@....yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fungi@...goth.org);
MUD(fungi@...arsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }