Bugtraq mailing list archives
Re: /bin/ksh creates insecure tmp files
From: "Greg A. Woods" <woods () weird com>
Date: Thu, 21 Dec 2000 16:10:11 -0500
[ On Thursday, December 21, 2000 at 09:11:37 (+1100), Paul Szabo wrote: ]
Subject: /bin/ksh creates insecure tmp files At the time I also tested the Korn shell ksh, and it seemed safe... but no, ksh is in fact also vulnerable. (Is this all shells? We have seen tcsh, bash, sh and now ksh fail...) [[....]] Demonstration (ksh is vulnerable if the size of silly.1 is changed):
You don't say exactly which *version* OR which *variant* of which shells are vulnerable (nor have many others when talking about this particular issue, unfortunately). I see that at least one version (and presumably those that preceded it) of David Korn's KSH is indeed vulnerable. I tested the version in SunOS-5.6, i.e. Version M-11/16/88i. As to whether or not all shells might have this problems, no, they don't. This "bug" does not exist in PD KSH v5.2.14 99/07/13.2, nor has it for a significant amount of time, if ever. From examination of the code of 5.2.12 (i.e. at least as early as 1997) it probably doesn't exist there either (though I've not re-compiled the older versions and done actual tests to prove it...). Similarly /bin/sh on NetBSD is not vulnerable, nor should any /bin/sh shell based on any 4BSD freeware release (i.e. 4.3-net2 or later) because of course this means it is based on Kenneth Almquist's "ash". Ash uses fork() to feed "here docs" to itself, and the only use of temporary files, at least in the in the NetBSD version, is with the more recently added command-line history editor, which was added recently enough to use mkstemp() [~1994], and in DEBUG-only tracing code. Any really ancient true Bourne shell (eg. those based on the original Seventh Edition Unix) won't be vulnerable either because they use the creat(2) system call to try creating any temporary file. That probably includes any more recent AT&T UNIX System V (derived) /bin/sh too.... Note that PD-KSH has the following call to do the open(): /* Mode 0600 to be paranoid, O_TRUNC in case O_EXCL isn't * really there. */ fd = open(path, O_RDWR|O_CREAT|O_EXCL|O_TRUNC, 0600); The pathname is indeed formed in a very predictable way so, on systems where O_EXCL does nothing and O_CREAT|O_TRUNC doesn't have the desired effect then the shell might be tricked into truncating any file that the user has write permissions to. However any system where those conditions are true isn't going to be very secure from any point of view.... I suppose it's possible for O_TRUNC to take precedence on O_CREAT, but such an implementation would be broken, by definition. So, this vulnerability is a *new* problem in *some* Bourne-shell *clones*, and perhaps in csh and/or some csh clones and/or derivatives. (I've permanently removed csh and it's cones and derivatives from my entire life, so I have no desire to even learn of their status.) Indeed this is a really *old* kind of problem, generically speaking, and one that I'm continually surprised re-appears, particularly in any runtime interpreter of any kind! Must all programmers learn good programming practices the hard way? Perhaps eliminating creat(2) by merging it into open(2) with O_CREAT was a mistake? (I sort of wondered about that at the time!) In fact I was very surprised to learn that any version of David Korn's KSH was vulnerable to this style of attack. I once had source access to it but I can no longer verify the reason why in the code that it's vulnerable.... I do note from examination of the PD KSH code that it should be possible to perform a DoS style attack against any script that uses "here docs" though since there's no way out of the loop that searches for a valid temporary file except by successfully creating it, or by encountering some error other than EINTR, EEXIST, or EISDIR, so if a malicious program were to pre-create all possible temporary files that some other interpreter instance were to try then it could never succeed but would never stop trying.... I'll now try fixing that bug and notifying the PD KSH maintainer and at least one of the vendors using it.... -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods () acm org> <robohack!woods> Planix, Inc. <woods () planix com>; Secrets of the Weird <woods () weird com>
Current thread:
- /bin/ksh creates insecure tmp files Paul Szabo (Dec 20)
- Re: /bin/ksh creates insecure tmp files J.A. Gutierrez (Dec 21)
- Re: /bin/ksh creates insecure tmp files Greg A. Woods (Dec 21)