Home / vulnerabilities perforce.txt
Posted on 04 January 2007
Source : packetstormsecurity.org Link
= 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
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
