= 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@beonex.com, sorry for the inconvenience 



Update from Full-Disclosure:

Examples of problematic cases:

   * remote contractors like me with their own machine who work for
     many companies and don't feel like having 20 boxen, on separate
     networks.
   * I've seen quite some startup companies who actually required their
     employees to bring their own computers, because the company didn't
     have money yet. Neither had the employees. What about their
     personal data?
   * As far as I can see, the FreeBSD project uses Perforce for some
     project parts [1],[2]. I'm quite sure they don't hand out
     computers to all relevant committers. In fact, that Perforce
     server is running against the Internet
     (perforce.freebsd.org:1666), so anybody cracking that machine
     might break into developers' machines. And, worst case, go on from
     there.
   * There are public Perforce servers for anonymous access. That's
     comparable with public FTP or HTTP servers. Surely you'd be upset,
     if a random FTP server would have access to your files just
     because you downloaded something.