From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <200105261954.f4QJsmj04287@ducky.net> To: 9fans@cse.psu.edu From: Mike Haertel Subject: [9fans] Plan 9 (in)security Date: Sat, 26 May 2001 12:54:48 -0700 Topicbox-Message-UUID: a87baa32-eac9-11e9-9e20-41e7f4b1d025 While writing a small Plan 9 file server tonight, I got to thinking about various exceptional conditions that the server might have to deal with, for example will the server ever see walks to ".", or will the kernel handle those for me? Then it hit me that a robustly written 9P server shouldn't depend on its client being the well-behaved Plan 9 kernel. At least, not if it's going to be accessible via the network. There is no guarantee that your remote client is, in fact, a real Plan 9 kernel. This led to wondering about what kind of input validation existing Plan 9 servers do. One obvious thing is making sure that names that are required to be nul-terminated strings of length NAMELEN-1 or less do, in fact, meet these requirements. Well, it turns out that convM2S() doesn't even enforce this. It uses memmove() to move exactly NAMELEN bytes from the input buffer to the Fcall structure--whether or they contain a nul-terminated string or anything else. It won't overrun its destination Fcall structure, but a clever attacker could probably arrange for data to be written into the Fcall structure that might later cause a file server using a strcpy() family function to go out of bounds and do who knows what. A similar caveat applies to convM2D(). For example, you might be able to crash or corrupt a file server by sending a wstat request in which the name, uid, gid, and perhaps following fields all contained no zero bytes. I'm sure there are fancier attacks; these just struck me as immediately obvious. 9P servers will not be secure unless they are written to behave sanely in the presence of an arbitrarily badly-behaved client. Unfortunately this would seem to make writing servers a good deal more difficult, and one of the advantages of Plan 9 is supposed to be that writing file servers is a relatively lightweight undertaking. Perhaps additional library support can help with this problem.