Bugzilla Bug 159542

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 .

Created an attachment (id=105029) [edit]
grep for insecure /tmp usage in lsat.

Notified upstream (triode@users.sourceforge.net).

any news here?

added to package.mask

voting no-glsa

/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.

I vote mask GLSA.

I vote yes(if this actually is working on new Gentoo installs).

To sum it up:
2 NO votes
1(+1) YES votes

2 yes votes --> GLSA

GLSA 200703-20, package masked, and setting Severity to "enhancement"

cc'ing treecleaners for removal.

assigning to treecleaner.  I will figure this out one day.

Treecleaners, please vote.

++

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.

http://www.opengroup.org/onlinepubs/007908775/xsh/open.html

I ask that this bug be moved to INVALID. 

Thank you.

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.

"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. 

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.

Ignore my last comment - I see the protection now (when opening out_file in
lsatmain.c).

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. 
http://www.stanford.edu/~talg/papers/traps/traps-ndss03.pdf
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
appreciated. 

""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.

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. 

http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO.html#TEMPORARY-FILES

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 http://www.dimlight.org/lsat

0.9.5 in cvs.

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"

app-admin/lsat-0.9.5
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: =========
/lib/libc.so.6[0xb7e55427]
/lib/libc.so.6(__libc_free+0x7a)[0xb7e569d4]
lsat[0x80498ee]
======= 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/libgcc_s.so.1
b7df1000-b7df2000 rw-p 00008000 08:04 2194594   
/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libgcc_s.so.1
b7df2000-b7df3000 rw-p b7df2000 00:00 0
b7df3000-b7f0f000 r-xp 00000000 08:04 2292824    /lib/libc-2.5.so
b7f0f000-b7f10000 r--p 0011c000 08:04 2292824    /lib/libc-2.5.so
b7f10000-b7f12000 rw-p 0011d000 08:04 2292824    /lib/libc-2.5.so
b7f12000-b7f15000 rw-p b7f12000 00:00 0
b7f15000-b7f1b000 r-xp 00000000 08:04 2301634    /usr/lib/libpopt.so.0.0.0
b7f1b000-b7f1c000 rw-p 00006000 08:04 2301634    /usr/lib/libpopt.so.0.0.0
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/ld-2.5.so
b7f57000-b7f58000 r--p 00019000 08:04 2292662    /lib/ld-2.5.so
b7f58000-b7f59000 rw-p 0001a000 08:04 2292662    /lib/ld-2.5.so
bfbcf000-bfbe6000 rw-p bfbcf000 00:00 0          [stack]
Aborted

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 2.1.2.2 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.5-r0,
2.6.20.10 i686)
=================================================================
System uname: 2.6.20.10 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
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=prescott -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
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"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--nospinner"
FEATURES="collision-protect distlocks metadata-transfer parallel-fetch sandbox
sfperms strict test userfetch userpriv usersandbox"
GENTOO_MIRRORS="http://mirror.switch.ch/mirror/gentoo/ http://gentoo.inode.at/"
LINGUAS="en de en_GB de_CH"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
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-*"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
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"
Unset:  CTARGET, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_COMPRESS,
PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY

x86 done

package.unmasked.

ppc stable

amd64 late, but worth the wait.. and stable

ready for GLSA vote. I tend to vote no.

Is this temp file regularily used?

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)

I agree with Falco, the first GLSA was enough I think.

... So I meant to say I vote no for this round.

GLSA updated, no rerelease.