Message-ID: <459BC5A2.6030903@bucksch.org>
Date: Wed, 03 Jan 2007 16:02:58 +0100
From: Ben Bucksch <news@...ksch.org>
To: full-disclosure@...ts.grok.org.uk
Subject: Perforce client: security hole by design

= Abstract =

The Perforce client has a huge gapping security hole by design. It 
totally trusts the Perforce server and does whatever the server tells 
it, writing arbitrary files.

= Disclaimer =

This is so terribly obvious that I'd be surprised that this is news, but 
I couldn't find anything. Or I'm missing something.

= Problem =

The Perforce server stores a "client config", which contains the local 
pathnames on the *client* machine (the machine fetching source). Of 
course, that information on the server can change any time. The problem 
is: the Perforce client adheres to it without a second thought. That 
means the p4 server can tell the p4 client to overwrite my ~/.bashrc, 
and *it will just do it*.

In fact, the client cannot even do "p4 help" on its own, even that comes 
from the server. Apparently, there is a very fundamental design problem 
of overly relying on the server, nor checking its input, there are 
probably more bugs of this kind. I am completely new to Perforce, so the 
"p4 sync" problem described above may well not be the only one.

= Reproduction =

   1. Let your Perforce admin set up your client workspace, and in it
      "/tmp/foo/" as local directory name.
   2. Get the Linux commandline client from perforce.com
   3. Do
      cd /usr/src/
      P4CLIENT=your-client-workspace-name P4PORT=servername:port p4 sync
   4. p4 will write files to /tmp/foo/ instead of /usr/src/.


= Risk =

Critical. The server has full access to *all* files that *any* of its 
users has.

"We can trust the server" is not an appropriate answer:

    * I am a contractor and have access to many companies' sources, and
      I do *not* allow any company I work for to have full access to all
      files on my computer, including the source of the all other
      companies I work for and even personal files.
    * Also, there are many ways to fool DNS, so that your client goes to
      another, hostile server.
    * And, lastly, a server is not 100% bulletproof either.


= Versions affected =

Probably all affected.

= Vendor notification =

Vendor has not been given secret advance notification, due to the nature 
of the bug.

= 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.

But to believe that this would fix the client would be naive. The nature 
of the bug, that this is a design problem, and a terribly obvious one at 
that, points to a very serious attitude problem, that there's no 
consideration for security at all (when it comes to client vs. server). 
This usually reflects in many places in the design and code and is often 
very hard or impossible to remove, because this often results in 
hundreds or thousands of security holes. I've seen code with critical 
security holes on every third line, for similar reasons. Thus, the only 
way that Perforce could reassure the security of the client vs. server 
would be to make the client source open for review (preferably as Open 
Source) and make the protocol available for everybody to implement their 
own clients.


Ben Bucksch
http://www.bucksch.org
Emails please to firstname.lastname@...nex.com, sorry for the inconvenience

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

Powered by blists - more mailing lists