Security issue - Insecure use of files in /tmp

Hi,

unfortunately I got a bug report about insecure handling of temp files
in Radiance:

radiance_3R9+20080530-3 dayfact /tmp/gsf$$ (pipe)
                                    /tmp/tl$$.pic (pipe)
                                    /tmp/ds$$.pic (pipe)
                                    /tmp/tfa$$ (pipe)
                        optics2rad /tmp/opt.fmt (pipe)
                                    /tmp/out$$.fmt (pipe)
                        raddepend /tmp/sed$$ (pipe)

Temp files need to be created with a non-predictable way, otherwise
other users could create a link or file with the same name to trick you
into overwriting files, which could (in the worse case) result into a
compromise of the system.
In case you know about similar problems in other scripts or even in the
C code, please let me know, so they can be fixed, too.
Regarding Debian, such bugs are considered 'grave'. I'll have to upload
a fix soon for Lenny, otherwise the package will be removed.

Best regards,

Bernd

···

--
Bernd Zeimetz Debian GNU/Linux Developer
GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79

Hi Bernd,

How do you create a file with an "unpredictable" name? Why is this even an issue unless a script or program has the suid bit enabled? Radiance programs should never have permission to do anything a user couldn't, unless they're being run by root.

There are quite a few scripts that create temporary files this way in Radiance:

% grep -l '/tmp' */*.csh
cv/optics2rad.csh
gen/genbackg.csh
gen/genpine.csh
gen/genwindow.csh
gen/markpath.csh
px/falsecolor.csh
px/normpat.csh
px/pacuity.csh
px/pbilat.csh
px/pdelta.csh
px/phisteq.csh
px/phisto.csh
px/psquish.csh
px/pveil.csh
px/ran2tiff.csh
px/vlpic.csh
px/xyzimage.csh
util/compamb.csh
util/dayfact.csh
util/objline.csh
util/objpict.csh
util/objview.csh
util/raddepend.csh

-Greg

···

From: Bernd Zeimetz <[email protected]>
Date: August 13, 2008 4:07:07 AM PDT

Hi,

unfortunately I got a bug report about insecure handling of temp files
in Radiance:

radiance_3R9+20080530-3 dayfact /tmp/gsf$$ (pipe)
                                    /tmp/tl$$.pic (pipe)
                                    /tmp/ds$$.pic (pipe)
                                    /tmp/tfa$$ (pipe)
                        optics2rad /tmp/opt.fmt (pipe)
                                    /tmp/out$$.fmt (pipe)
                        raddepend /tmp/sed$$ (pipe)

Temp files need to be created with a non-predictable way, otherwise
other users could create a link or file with the same name to trick you
into overwriting files, which could (in the worse case) result into a
compromise of the system.
In case you know about similar problems in other scripts or even in the
C code, please let me know, so they can be fixed, too.
Regarding Debian, such bugs are considered 'grave'. I'll have to upload
a fix soon for Lenny, otherwise the package will be removed.

Best regards,

Bernd

Hi Greg,

How do you create a file with an "unpredictable" name? Why is this even
an issue unless a script or program has the suid bit enabled? Radiance
programs should never have permission to do anything a user couldn't,
unless they're being run by root.

Files with an unpredictable and unique name are generated by using
random letters and numbers within the filename *and* - preferable in an
atomic way - create the file and open it for reading/writing.
This is also the reason why gcc warns about the use of mktemp(3). It
requires a filename ending with an extension of XXXXXX (six x's). When
the temporary file is generated, the name of the file is generated by
taking the predetermined name in the program, and filling the field of
X's with a random value. However, some operating systems fill the first
five X's in the field with the process number, and the last X with one
of twenty-six lower case letters in the alphabet. Even worse, mktemp(3)
does not create and open the file, so if you call mktemp(3) twice, you
could end up with the same predictable filename.

But why is this bad?
If I'm an evil person and know, that a program creates a file in /tmp in
an insecure (== predictable) way, I can
- create the file on my own, so - depending on the program of course -
I'm able to feed the program with my data or let it execute stuff with
the rights of the user who runs the program.
- use a symlink attack and create a symlink which points to some other
file - for example to destroy files of the user running the program.
Imagine you're rendering something for hours, and while rendering the
last piece of the image I trick one of the programs/scripts into writing
it's temporary junk into the result of hours of rendering - your work is
lost.
So this is not really related to being root or not, but it's a good way
to gain more priviledges on a system on the way to become root :wink:

Although the impact of this kind of vulnerability is low, it is still
bad enough to get a CVE id for it and end up with fixes by security
uploads and the according announcements in the distributions....

For shell scripts the best thing to use is the mktemp(1) utility (if
it's available, which is the case for most platforms these days, afaik),
otherwise a file name with at least enough random letters/numbers needs
to be used.

There are quite a few scripts that create temporary files this way in
Radiance:

% grep -l '/tmp' */*.csh
cv/optics2rad.csh
gen/genbackg.csh
gen/genpine.csh
gen/genwindow.csh
gen/markpath.csh
px/falsecolor.csh
px/normpat.csh
px/pacuity.csh
px/pbilat.csh
px/pdelta.csh
px/phisteq.csh
px/phisto.csh
px/psquish.csh
px/pveil.csh
px/ran2tiff.csh
px/vlpic.csh
px/xyzimage.csh
util/compamb.csh
util/dayfact.csh
util/objline.csh
util/objpict.csh
util/objview.csh
util/raddepend.csh

ouch...

I'll see what's the best way to fix this in Debian - which needs to be
done before Lenny is released (==soon).

Cheers,

Bernd

···

--
Bernd Zeimetz Debian GNU/Linux Developer
GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79

I don't understand the reasoning, here. Unless you're running Security-Enhanced Linux, if an "evil person" has an account on your system, system security is toast anyway--as the implementation of mktemp(3) (among many other features) shows, Unix was never designed to be secure against a determined attack by a malicious user.

Randolph

···

On Wed, 13 Aug 2008, Bernd Zeimetz wrote:

Hi Greg,

How do you create a file with an "unpredictable" name? Why is this even
an issue unless a script or program has the suid bit enabled? Radiance
programs should never have permission to do anything a user couldn't,
unless they're being run by root.

Files with an unpredictable and unique name are generated by using
random letters and numbers within the filename *and* - preferable in an
atomic way - create the file and open it for reading/writing.
This is also the reason why gcc warns about the use of mktemp(3). It
requires a filename ending with an extension of XXXXXX (six x's). When
the temporary file is generated, the name of the file is generated by
taking the predetermined name in the program, and filling the field of
X's with a random value. However, some operating systems fill the first
five X's in the field with the process number, and the last X with one
of twenty-six lower case letters in the alphabet. Even worse, mktemp(3)
does not create and open the file, so if you call mktemp(3) twice, you
could end up with the same predictable filename.

But why is this bad?
If I'm an evil person and know, that a program creates a file in /tmp in
an insecure (== predictable) way, I can
- create the file on my own, so - depending on the program of course -
I'm able to feed the program with my data or let it execute stuff with
the rights of the user who runs the program.
- use a symlink attack and create a symlink which points to some other
file - for example to destroy files of the user running the program.
Imagine you're rendering something for hours, and while rendering the
last piece of the image I trick one of the programs/scripts into writing
it's temporary junk into the result of hours of rendering - your work is
lost.
So this is not really related to being root or not, but it's a good way
to gain more priviledges on a system on the way to become root :wink:

Although the impact of this kind of vulnerability is low, it is still
bad enough to get a CVE id for it and end up with fixes by security
uploads and the according announcements in the distributions....

For shell scripts the best thing to use is the mktemp(1) utility (if
it's available, which is the case for most platforms these days, afaik),
otherwise a file name with at least enough random letters/numbers needs
to be used.

There are quite a few scripts that create temporary files this way in
Radiance:

% grep -l '/tmp' */*.csh
cv/optics2rad.csh
gen/genbackg.csh
gen/genpine.csh
gen/genwindow.csh
gen/markpath.csh
px/falsecolor.csh
px/normpat.csh
px/pacuity.csh
px/pbilat.csh
px/pdelta.csh
px/phisteq.csh
px/phisto.csh
px/psquish.csh
px/pveil.csh
px/ran2tiff.csh
px/vlpic.csh
px/xyzimage.csh
util/compamb.csh
util/dayfact.csh
util/objline.csh
util/objpict.csh
util/objview.csh
util/raddepend.csh

ouch...

I'll see what's the best way to fix this in Debian - which needs to be
done before Lenny is released (==soon).

Cheers,

Bernd

--
Bernd Zeimetz Debian GNU/Linux Developer
GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

Randolph Fritz wrote:

I don't understand the reasoning, here. Unless you're running Security-Enhanced Linux, if an "evil person" has an account on your system, system security is toast anyway--as the implementation of mktemp(3) (among many other features) shows, Unix was never designed to be secure against a determined attack by a malicious user.

These times are gone.... and gcc warns about the use of mktemp these
days. Even for an evil user it should not be possible to mess with
anything but his own account....

Bernd

···

--
Bernd Zeimetz Debian GNU/Linux Developer
GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79

But it's going to be possible, even if this particular thing is changed. Is this really more of a risk than a hundred other exploits? Or just one particular one that's been closed off? I'd hate to see Linux start running on Schneier's patch treadmill.

···

On Thu, 14 Aug 2008, Bernd Zeimetz wrote:

Randolph Fritz wrote:

I don't understand the reasoning, here. Unless you're running Security-Enhanced Linux, if an "evil person" has an account on your system, system security is toast anyway--as the implementation of mktemp(3) (among many other features) shows, Unix was never designed to be secure against a determined attack by a malicious user.

These times are gone.... and gcc warns about the use of mktemp these
days. Even for an evil user it should not be possible to mess with
anything but his own account....

Randolph Fritz wrote:

···

On Thu, 14 Aug 2008, Bernd Zeimetz wrote:
But it's going to be possible, even if this particular thing is
changed. Is this really more of a risk than a hundred other exploits?
Or just one particular one that's been closed off? I'd hate to see
Linux start running on Schneier's patch treadmill.

So which other exploit (which is as trivial as abusing /tmp) do you know?

Bernd

--
Bernd Zeimetz Debian GNU/Linux Developer
GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79

Denial of service by gobbling system resources. It strikes me that this particular security measure is more useful in transaction-processing environments, where I agree it has some value. That is not, however, a very common use of Radiance components.

Randolph

···

On Thu, 14 Aug 2008, Bernd Zeimetz wrote:

Randolph Fritz wrote:

On Thu, 14 Aug 2008, Bernd Zeimetz wrote:
But it's going to be possible, even if this particular thing is
changed. Is this really more of a risk than a hundred other exploits?
Or just one particular one that's been closed off? I'd hate to see
Linux start running on Schneier's patch treadmill.

So which other exploit (which is as trivial as abusing /tmp) do you know?

Bernd Zeimetz wrote:

Hi Greg,

How do you create a file with an "unpredictable" name? Why is this even
an issue unless a script or program has the suid bit enabled? Radiance
programs should never have permission to do anything a user couldn't,
unless they're being run by root.

Files with an unpredictable and unique name are generated by using
random letters and numbers within the filename *and* - preferable in an
atomic way - create the file and open it for reading/writing.

Please let's not advocate the "security through obscurity" snake
oil here. Fortunately, mktemp(1) does indeed quite a bit better
than that, and actually creates the file before anyone else can
(presumably using mkstemp(3)). If the shell scripts can be fixed
that way with reasonable effort, I'm all for it.
In fact, this will make the scripts more secure (with regards to
this specific, and for Radiance probably minor, aspect) than the
few remaining mktemp(3) instances in the C code.

-schorsch

···

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

OK, so it sounds like we have consensus. When I have some time, I'll work on applying the mktemp(1) utility to all the shell scripts, and check it in to CVS. It might take a week or two for me to get to it.

-Greg

···

From: Georg Mischler <[email protected]>
Date: August 17, 2008 3:10:37 AM PDT

Bernd Zeimetz wrote:

Hi Greg,

How do you create a file with an "unpredictable" name? Why is this even
an issue unless a script or program has the suid bit enabled? Radiance
programs should never have permission to do anything a user couldn't,
unless they're being run by root.

Files with an unpredictable and unique name are generated by using
random letters and numbers within the filename *and* - preferable in an
atomic way - create the file and open it for reading/writing.

Please let's not advocate the "security through obscurity" snake
oil here. Fortunately, mktemp(1) does indeed quite a bit better
than that, and actually creates the file before anyone else can
(presumably using mkstemp(3)). If the shell scripts can be fixed
that way with reasonable effort, I'm all for it.
In fact, this will make the scripts more secure (with regards to
this specific, and for Radiance probably minor, aspect) than the
few remaining mktemp(3) instances in the C code.

-schorsch

Gregory J. Ward wrote:

OK, so it sounds like we have consensus. When I have some time, I'll
work on applying the mktemp(1) utility to all the shell scripts, and
check it in to CVS. It might take a week or two for me to get to it.

I won't be much around this week and not used to csh, but I could work
on a patch, too.

Cheers,

Bernd

···

--
Bernd Zeimetz Debian GNU/Linux Developer
GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79

No sense both of us working on it. I can manage -- but thanks for the offer to help.

-Greg

···

From: Bernd Zeimetz <[email protected]>
Date: August 17, 2008 12:34:33 PM PDT

Gregory J. Ward wrote:

OK, so it sounds like we have consensus. When I have some time, I'll
work on applying the mktemp(1) utility to all the shell scripts, and
check it in to CVS. It might take a week or two for me to get to it.

I won't be much around this week and not used to csh, but I could work
on a patch, too.

Cheers,

Bernd