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 [email protected], 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.