Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 159542 - app-admin/lsat: Insecure usage of files in /tmp
Summary: app-admin/lsat: Insecure usage of files in /tmp
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Security
Whiteboard: B3? [glsa] jaervosz
Depends on:
Reported: 2006-12-31 01:41 UTC by Vic Fryzel (shellsage) (RETIRED)
Modified: 2007-05-11 06:59 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---

grep for insecure /tmp usage in lsat. (insecure_tmp_usage,12.79 KB, text/plain)
2006-12-31 01:43 UTC, Vic Fryzel (shellsage) (RETIRED)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vic Fryzel (shellsage) (RETIRED) gentoo-dev 2006-12-31 01:41:53 UTC
lsat insecurely writes to files in /tmp, without first checking to see if those files could be symlinks, possibly allowing for the overwriting of arbitrary files upon installing lsat.  Additionally, Gentoo patches lsat before building it to again be insecure by pointing to the same file(s) in /tmp before checking to see if the file is a symlink.  Generally this file is /tmp/lsat1.lsat .
Comment 1 Vic Fryzel (shellsage) (RETIRED) gentoo-dev 2006-12-31 01:43:36 UTC
Created attachment 105029 [details]
grep for insecure /tmp usage in lsat.
Comment 2 Vic Fryzel (shellsage) (RETIRED) gentoo-dev 2006-12-31 02:55:34 UTC
Notified upstream (
Comment 3 Matthias Geerdsen (RETIRED) gentoo-dev 2007-03-07 13:49:06 UTC
any news here?
Comment 4 MATSUU Takuto (RETIRED) gentoo-dev 2007-03-12 15:36:43 UTC
added to package.mask
Comment 5 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2007-03-14 00:39:25 UTC
voting no-glsa
Comment 6 Matt Drew (RETIRED) gentoo-dev 2007-03-14 03:26:18 UTC
/vote no on GLSA - it's ancient, upstream has been sluggish for years and hasn't updated in five months, I can't imagine anyone is using this on Gentoo.  Also, since it is typically used just after install, users will see the mask.
Comment 7 Vic Fryzel (shellsage) (RETIRED) gentoo-dev 2007-03-14 03:31:00 UTC
I vote mask GLSA.
Comment 8 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2007-03-14 07:30:22 UTC
I vote yes(if this actually is working on new Gentoo installs).

To sum it up:
2 NO votes
1(+1) YES votes
Comment 9 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2007-03-15 22:15:56 UTC
2 yes votes --> GLSA
Comment 10 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2007-03-18 22:08:00 UTC
GLSA 200703-20, package masked, and setting Severity to "enhancement"
Comment 11 Matt Drew (RETIRED) gentoo-dev 2007-04-05 15:18:10 UTC
cc'ing treecleaners for removal.
Comment 12 Matt Drew (RETIRED) gentoo-dev 2007-04-05 15:21:33 UTC
assigning to treecleaner.  I will figure this out one day.
Comment 13 Raúl Porcel (RETIRED) gentoo-dev 2007-04-08 13:21:02 UTC
Treecleaners, please vote.

Comment 14 number9 2007-04-08 22:56:28 UTC
I thought this was resolved in conversation via email... the LSAT package does check for previous existence of any file in /tmp before writing, as indicated in the module, and in the code. There is no symlink attack vulnerability (at least in that respect) there. 

As for the file opening on an existing file (symlink attack), please see this
section, which will clarify the flags I have set in open so that particular situation does not occour.

I ask that this bug be moved to INVALID. 

Thank you.
Comment 15 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2007-04-09 20:55:14 UTC
Indeed i am unable to find any insecure open() calls.

- Several race conditions are possible between a successfull open(O_EXCL) and a following fopen() call. See for example checkfiles.c around line 87, the fopen(...,a) could lead to a symlink attack if an attacker manage to create the symlink between open(O_EXCL) and fopen(...,a).

- The informative examples provided in README.modules and modules.html are clearly unsecure since the O_EXCL flag is missing.

Comment 16 number9 2007-04-10 02:55:28 UTC
"Several race conditions are possible between a successfull open(O_EXCL) and a
following fopen() call. See for example checkfiles.c around line 87, the
fopen(...,a) could lead to a symlink attack if an attacker manage to create the
symlink between open(O_EXCL) and fopen(...,a)."

Is this really a serious circumstance? I suppose I could write a script that would look for when lsat was running and then time my execution such that in between those two calls I would create a link from that file to my target, but I get the feeling an attacker clever enough to work out the timing envolved would already have control of the system through other means. 

"The informative examples provided in README.modules and modules.html are
clearly unsecure since the O_EXCL flag is missing."

Thanks for catching that. I started out without then realized a symlink attack was possible, updated the modules but forgot to update the readmes. I have added them in and will update the tarballs. 

Again, and I am being serious, is a symlink attack in between those calls in the same module a serious issue? I am not one to blow off security, but I will have to think harder about this "insecurity" in the code. 
Comment 17 Matt Drew (RETIRED) gentoo-dev 2007-04-10 13:17:51 UTC
The open() calls look ok to me as well, except for things like:

outfile=fopen(filename, "a");

in checkftpusers.c and checkrc.c.  Just because it's a user-specified file doesn't mean it doesn't need to be protected against symlink attacks - what if the user chose /tmp/outfile?

Regardless, it would probably be safer use your own directory in /tmp or put the temp files in some place only writable by the user running lsat, and keep all the safeguards in place just in case.  This stuff is ugly and still shows up on a regular basis ten years it was documented - there's no sense in putting files where one mistake could cause a compromise.
Comment 18 Matt Drew (RETIRED) gentoo-dev 2007-04-10 13:35:51 UTC
Ignore my last comment - I see the protection now (when opening out_file in lsatmain.c).
Comment 19 number9 2007-04-10 18:45:38 UTC
I am open for comments on the condition example given in checkfiles.c
in or around line 87. I see the possibility in theory, but I have a bit
of a time seeing it as a normal user on the system. I note the following
article, on the right hand column of page 6, where they speak of this 
exact race, but have a hard time coming up with a solution.
My next question, which I will be STFW for shortly, is how does everyone
else cope with this insecurity? I would like to resolve this problem 
quickly but with precision. I am working now, but doing this on my breaks,
so I may be slow, but I will keep on this. Any hints or pointers is much

Comment 20 Vic Fryzel (shellsage) (RETIRED) gentoo-dev 2007-04-10 22:06:09 UTC
""Several race conditions are possible between a successfull open(O_EXCL) and a
following fopen() call. See for example checkfiles.c around line 87, the
fopen(...,a) could lead to a symlink attack if an attacker manage to create the
symlink between open(O_EXCL) and fopen(...,a)."

Is this really a serious circumstance?"

Yes, it's a simple bash script to exploit that sort of race condition.  As a normal user I'd just write simple while loop that ran in wait.  It'd be barely detectable and once the conditions were met, take arbitrary actions on the system.
Comment 21 number9 2007-04-15 13:38:56 UTC
This guide gives a few examples of secure writing to temp files,
but I note that even here, I could cause a race condition (with
say the GNOME example)... even creating a random filename in
the do loop is not enough. Even if you could prove that the 
do loop is the critical section, I could be running that instance
of linux/LSAT in a VM and I could timeslice the critical section. 
So I ask... does the gentoo security community have a solution to writing
temp files? It seems that nothing I read is actually secure since I
can always catch the name of the file and cause a race or perform
a symlink attack.

Comment 22 number9 2007-04-27 23:26:58 UTC
New version released. I have taken care of the open problem. The file is only opened once, and then the file descirptor is turned into a pointer instead
of opening the file again. See lsat-0.9.5 at

Comment 23 MATSUU Takuto (RETIRED) gentoo-dev 2007-04-28 01:31:07 UTC
0.9.5 in cvs.
Comment 24 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2007-04-30 12:29:57 UTC
Thx Matsuu, but it's still masked.

Anyway arches please test and mark stable. Target keywords are:

lsat-0.9.5.ebuild:KEYWORDS="amd64 ppc x86"
Comment 25 Markus Meier gentoo-dev 2007-05-01 11:21:51 UTC
1. emerges on x86
2. passes collision test
3. don't know if this package is really ready (but w/o any parameters it seems to work... still checking :))

# lsat -v
*** glibc detected *** lsat: free(): invalid next size (fast): 0x0805b1a0 ***
======= Backtrace: =========
======= Memory map: ========
08048000-0805a000 r-xp 00000000 08:04 2256394    /usr/bin/lsat
0805a000-0805b000 rw-p 00011000 08:04 2256394    /usr/bin/lsat
0805b000-0807c000 rw-p 0805b000 00:00 0          [heap]
b7c00000-b7c21000 rw-p b7c00000 00:00 0
b7c21000-b7d00000 ---p b7c21000 00:00 0
b7de8000-b7df1000 r-xp 00000000 08:04 2194594    /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/
b7df1000-b7df2000 rw-p 00008000 08:04 2194594    /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/
b7df2000-b7df3000 rw-p b7df2000 00:00 0
b7df3000-b7f0f000 r-xp 00000000 08:04 2292824    /lib/
b7f0f000-b7f10000 r--p 0011c000 08:04 2292824    /lib/
b7f10000-b7f12000 rw-p 0011d000 08:04 2292824    /lib/
b7f12000-b7f15000 rw-p b7f12000 00:00 0
b7f15000-b7f1b000 r-xp 00000000 08:04 2301634    /usr/lib/
b7f1b000-b7f1c000 rw-p 00006000 08:04 2301634    /usr/lib/
b7f1c000-b7f1d000 rw-p b7f1c000 00:00 0
b7f3c000-b7f3d000 r-xp b7f3c000 00:00 0          [vdso]
b7f3d000-b7f57000 r-xp 00000000 08:04 2292662    /lib/
b7f57000-b7f58000 r--p 00019000 08:04 2292662    /lib/
b7f58000-b7f59000 rw-p 0001a000 08:04 2292662    /lib/
bfbcf000-bfbe6000 rw-p bfbcf000 00:00 0          [stack]

but this works
# lsat -o test.out -v
Starting LSAT...
Getting system information...
System type is: Linux
Kernel/release level is: 2.6�
Running modules...
 Running checkpkgs module...

Portage (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.5-r0, i686)
System uname: i686 Genuine Intel(R) CPU           T2300  @ 1.66GHz
Gentoo Base System release 1.12.9
Timestamp of tree: Tue, 01 May 2007 09:00:09 +0000
dev-java/java-config: 1.3.7, 2.0.31-r5
dev-lang/python:     2.3.5-r3, 2.4.3-r4
dev-python/pycrypto: 2.0.1-r5
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.61
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.16.1-r3
sys-devel/gcc-config: 1.3.15-r1
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.17-r2
CFLAGS="-O2 -march=prescott -pipe -fomit-frame-pointer"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/php/apache1-php5/ext-active/ /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c"
CXXFLAGS="-O2 -march=prescott -pipe -fomit-frame-pointer"
FEATURES="collision-protect distlocks metadata-transfer parallel-fetch sandbox sfperms strict test userfetch userpriv usersandbox"
LINGUAS="en de en_GB de_CH"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*"
USE="X a52 aac acpi alsa apache2 asf berkdb bitmap-fonts cairo cdr cdrom cli cracklib crypt cups dbus divx dri dts dvd dvdr dvdread eds emboss encode fam ffmpeg firefox flac fortran gdbm gif gnome gpm gstreamer gtk hal iconv ipv6 isdnlog java jpeg kde kdeenablefinal ldap libg++ mad midi mikmod mmx mono mp3 mpeg ncurses nls nptl nptlonly ogg opengl oss pam pcre perl png ppds pppd python qt3 qt4 quicktime readline reflection rtsp ruby samba sdl session smp spell spl sse sse2 sse3 ssl svg tcpd test tetex theora threads truetype truetype-fonts type1-fonts unicode vcd vorbis wifi win32codecs wxwindows x264 x86 xine xml xorg xprint xv xvid zlib" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LINGUAS="en de en_GB de_CH" USERLAND="GNU" VIDEO_CARDS="i810 fbdev vesa"
Comment 26 Andrej Kacian (RETIRED) gentoo-dev 2007-05-02 10:43:50 UTC
x86 done
Comment 27 MATSUU Takuto (RETIRED) gentoo-dev 2007-05-02 15:08:38 UTC
Comment 28 Tobias Scherbaum (RETIRED) gentoo-dev 2007-05-03 18:28:47 UTC
ppc stable
Comment 29 Steve Dibb (RETIRED) gentoo-dev 2007-05-03 18:59:00 UTC
amd64 late, but worth the wait.. and stable
Comment 30 Pierre-Yves Rofes (RETIRED) gentoo-dev 2007-05-03 19:08:24 UTC
ready for GLSA vote. I tend to vote no.
Comment 31 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2007-05-03 19:28:19 UTC
Is this temp file regularily used?
Comment 32 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2007-05-08 18:47:32 UTC
There was already a temporary masking glsa, so i think we should issue a GLSA update, and i don't see why we should vote again.

(i voted no)
Comment 33 Vic Fryzel (shellsage) (RETIRED) gentoo-dev 2007-05-11 02:00:06 UTC
I agree with Falco, the first GLSA was enough I think.
Comment 34 Vic Fryzel (shellsage) (RETIRED) gentoo-dev 2007-05-11 02:00:31 UTC
... So I meant to say I vote no for this round.
Comment 35 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2007-05-11 06:59:22 UTC
GLSA updated, no rerelease.