|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
Date: Thu, 04 Jan 2007 20:03:34 +0100 From: Ben Bucksch <news@...ksch.org> To: bugtraq@...urityfocus.com 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 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 ,. 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.
Powered by blists - more mailing lists