Date: Tue, 24 Oct 2000 17:06:00 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: Jeroen Ruigrok van der Werven <jruigrok@via-net-works.nl>, audit@FreeBSD.ORG Subject: Re: printjob.c mktemp() problem Message-ID: <v0421010bb61ba7494c89@[128.113.24.47]> In-Reply-To: <20001024222716.B2020@lucifer.bart.nl> References: <20001024140510.G93799@lucifer.bart.nl> <20001024222716.B2020@lucifer.bart.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
At 10:27 PM +0200 10/24/00, Jeroen Ruigrok van der Werven wrote: >New patch at http://lucifer.bart.nl/~asmodai/printjob.c.diff > >However, there are some things I don't like in the current patch. > >I have these feeling that I am missing something. It is pretty easy to miss things in lpr/lpd. While everything they do is pretty simple, the code is so disorganized that often it is not-obvious what is going on. In the general case of mktemp calls, the security issue is that mktemp is called to create a file in /tmp. Due to the window between the call to 'mktemp' and any call to create that file, there is a security exposure that some OTHER task will deliberately try to create a file of the same name. (by trial-and-error, if nothing else). That problem does not arise in the specific case of this mktemp call in lpd. The temp-file in question is being created in the spool directory, and the spool directory is (HOPEFULLY!!) permitted such that untrusted users do not have any ability to create any files in it. If they do have access, then you have serious security problems which have nothing to do with this call to mktemp. However, I did plan to replace this mktemp call, partly on general principles, and partly because the code is just plain wrong. It is wrong because mktemp is called, and then the current directory is changed, and then the filename returned by mktemp is created. What is wrong there is the order of mktemp/chdir calls, and not the template used for the new filename. In practice this isn't a problem, but it isn't right either. Given that this is not a security exposure, it would probably be just as well to leave it alone for now. --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v0421010bb61ba7494c89>