Re: /bin/ksh creates insecure tmp files

["Greg A. Woods" <woods () weird com>]

[ 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>