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 attachment 105029 [details] 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.
