Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 66358

Summary: sys-libs/glibc: Insecure tempfile handling
Product: Gentoo Security Reporter: Luke Macken (RETIRED) <lewk>
Component: VulnerabilitiesAssignee: Gentoo Security <security>
Severity: normal CC: brant, tigger, toolchain
Priority: High    
Version: unspecified   
Hardware: All   
OS: All   
Whiteboard: A3 [glsa] lewk
Package list:
Runtime testing required: ---
Description Flags
glibc ebuilds tarball none

Description Luke Macken (RETIRED) gentoo-dev 2004-10-04 15:15:01 UTC
Problem description:

  Trustix Security Engineers identified that all these packages had one or
  more script(s) that handled temporary files in an insecure manner.  While
  it is not believed that any of these holes could lead to privilege
  escalation, it would be possible to trick the scripts to overwrite data
  writable by the user that invokes the script.

  These problems can only be exploited by local users, and they would have to
  wait for someone else, preferably root, to run the vulnerable scripts.
Comment 1 Luke Macken (RETIRED) gentoo-dev 2004-10-04 15:15:36 UTC
Created attachment 41097 [details, diff]

Trustix patch to fix insecure tempfile handling
Comment 2 Luke Macken (RETIRED) gentoo-dev 2004-10-04 15:17:08 UTC
toolchain herd,

please verify and apply patch if necessary.  

After quickly skimming through it, it seems that our stable glibc- is vulnerable.
Comment 3 solar (RETIRED) gentoo-dev 2004-10-04 21:19:52 UTC
Well. I can confirm that it patches clean. But overall that revision of glibc is pretty old and it's advised to never downgrade your glibc so I can't test this on behalf of the toolchain herd.

Should we attempt to apply to other versions of glibc? 
Do you have patches for any other revision of glibc?
Comment 4 Luke Macken (RETIRED) gentoo-dev 2004-10-04 21:41:17 UTC
I think it's probably safe to patch other versions as well.  After comparing it to the stable version, the file is *exactly* the same as in 2.3.2, the file doesn't exist, and there is a minor 1 line difference in the oldtmpfile.c code.

The patch was written by Trustix for their stable version of gcc, but seems to be safe for ours.  It's totally your call though.
Comment 5 Luke Macken (RETIRED) gentoo-dev 2004-10-04 22:43:44 UTC
Created attachment 41123 [details, diff]

Modified tempfile patch for glibc-2.3.3
Comment 6 solar (RETIRED) gentoo-dev 2004-10-05 10:32:42 UTC
Created attachment 41157 [details, diff]

I want somebody to test this before it gets committed to the tree.
Comment 7 solar (RETIRED) gentoo-dev 2004-10-05 10:37:41 UTC
glibc-2.2.5 (was not patched)
Comment 8 Travis Tilley (RETIRED) gentoo-dev 2004-10-07 12:53:40 UTC
damnit dude. can you attach the actual ebuilds.

File to patch: glibc-2.3.2-r12.ebuild
glibc-2.3.2-r12.ebuild: No such file or directory
Skip this patch? [y]

Comment 9 Travis Tilley (RETIRED) gentoo-dev 2004-10-07 12:55:15 UTC
...or at least diffs between ebuilds?
Comment 10 solar (RETIRED) gentoo-dev 2004-10-07 14:33:48 UTC
Damnit what? 
I'm not in the mood to take shit from you or anybody else. I'm not attaching a bunch of little files. I can attach a tarball. Or you can do the same darn thing I did. I added the patches to every ebuild in roughly the same spot. 
If you would of not touched the glibc like you said you wouldnt till this security problem was resolved it would of patched clean.
Comment 11 solar (RETIRED) gentoo-dev 2004-10-07 14:36:51 UTC
Created attachment 41323 [details]
glibc ebuilds tarball

sys-libs/glibc tarball
Comment 12 Travis Tilley (RETIRED) gentoo-dev 2004-10-07 15:24:19 UTC bad.

the patch has been added in cvs.
...has it been submitted upstream?
Comment 13 Brant Gurganus 2004-10-08 08:44:12 UTC
I am updating to sys-libs/glibc- from sys-libs/glibc-  Several times now, the build routine has been broken and mentions a stack smashing attack.

CPP='gcc -E -x c-header'  /var/tmp/portage/glibc- --library-path /var/tmp/portage/glibc- /var/tmp/portage/glibc- -Y ../scripts -c rpcsvc/bootparam_prot.x -o /var/tmp/portage/glibc-
rpcgen: stack smashing attack in function __guard_setup()
.././scripts/mkinstalldirs /var/tmp/portage/glibc-
.././scripts/mkinstalldirs /var/tmp/portage/glibc-
mkdir /var/tmp/portage/glibc-
make[2]: *** [/var/tmp/portage/glibc-] Aborted
make[2]: *** Waiting for unfinished jobs....
make[2]: *** Waiting for unfinished jobs....
CPP='gcc -E -x c-header'  /var/tmp/portage/glibc- --library-path /var/tmp/portage/glibc- /var/tmp/portage/glibc- -Y ../scripts -c rpcsvc/nlm_prot.x -o /var/tmp/portage/glibc-
rpcgen: stack smashing attack in function __guard_setup()
make[2]: *** Waiting for unfinished jobs....
make[2]: *** Waiting for unfinished jobs....
CPP='gcc -E -x c-header'  /var/tmp/portage/glibc- --library-path /var/tmp/portage/glibc- /var/tmp/portage/glibc- -Y ../scripts -h rpcsvc/bootparam_prot.x -o /var/tmp/portage/glibc-
rpcgen: stack smashing attack in function __guard_setup()
make[2]: *** Waiting for unfinished jobs....
CPP='gcc -E -x c-header'  /var/tmp/portage/glibc- --library-path /var/tmp/portage/glibc- /var/tmp/portage/glibc- -Y ../scripts -h rpcsvc/nlm_prot.x -o /var/tmp/portage/glibc-
rpcgen: stack smashing attack in function __guard_setup()
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [/var/tmp/portage/glibc-] Aborted
make[2]: *** [/var/tmp/portage/glibc-] Aborted
make[1]: *** [sunrpc/others] Error 2
make[1]: Leaving directory `/var/tmp/portage/glibc-'
make: *** [all] Error 2

!!! ERROR: sys-libs/glibc- failed.
!!! Function src_compile, Line 592, Exitcode 2
!!! (no error message)

I have never had this problem building glibc before.  Here is the portage information:
Portage 2.0.50-r11 (default-x86-2004.2, gcc-3.3.4, glibc-, 2.6.8-gentoo-r3)
System uname: 2.6.8-gentoo-r3 i686 Pentium III (Katmai)
Gentoo Base System version 1.4.16
distcc 2.16 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled]
ccache version 2.3 [enabled]
Autoconf: sys-devel/autoconf-2.59-r4
Automake: sys-devel/automake-1.8.5-r1
CFLAGS="-O3 -march=pentium3 -mcpu=pentium3 -fprefetch-loop-arrays -fomit-frame-pointer -pipe -ftracer -fstack-protector"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O3 -march=pentium3 -mcpu=pentium3 -fprefetch-loop-arrays -fomit-frame-pointer -pipe -ftracer -fstack-protector"
FEATURES="autoaddcvs buildpkg ccache distcc fixpackages sandbox strict"
USE="apm arts avi berkdb bitmap-fonts cjk crypt cups encode foomaticdb gdbm gif gpm gtk2 imlib jpeg justify kde libg++ libwww mad mikmod mmx mpeg ncurses nls nptl oggvorbis opengl oss pam parse-clocks pdflib perl pic png python qt quicktime readline sdl slang spell sse ssl tcpd truetype unicode x86 xml2 xmms xprint xv zlib"
Comment 14 Peter S. Mazinger 2004-10-08 09:01:01 UTC
that does not have to do w/ this bug, remove -fstack-protector from CFLAGS/CXXFLAGS. If you want a hardened setup, use the hardened use flag instead (and rebuild gcc)
Comment 15 Simon Strandman 2004-10-08 12:25:47 UTC
The upgrade from glibc- to r2 makes things segmentation fault. :( Recompiling those applications doesn't solve it.

nxsty@Isidor nxsty $ xmms
nxsty@Isidor nxsty $ mplayer

X doesn't start either. 

Portage 2.0.50-r11 (default-x86-2004.2, gcc-3.4.1, glibc-, 2.6.9-rc3-ck2)
System uname: 2.6.9-rc3-ck2 i686 AMD Athlon(tm) XP 2800+
Gentoo Base System version 1.4.16
Autoconf: sys-devel/autoconf-2.59-r4
Automake: sys-devel/automake-1.8.5-r1
CFLAGS="-O2 -march=athlon-xp -pipe -fomit-frame-pointer -ffast-math -g0 -DNO_DEBUG -DNDEBUG"
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=athlon-xp -pipe -fomit-frame-pointer -ffast-math -g0 -DNO_DEBUG -DNDEBUG -fvisibility-inlines-hidden -fno-enforce-eh-specs"
FEATURES="autoaddcvs ccache sandbox"
USE="3dnow X aalib alsa apm avi berkdb bitmap-fonts caps cdr crypt dga dvd dvdr encode esd esound f77 fbcon foomaticdb gdbm gif gnome gphoto2 gpm gtk gtk2
imlib jack jack-tmpfs java jpeg libg++ libwww linguas_sv mad mikmod mmx mng motif mozilla mpeg ncurses nls nptl objc offensive oggvorbis opengl pam pdflib
perl pic png pnp python qt quicktime readline samba sdl slang spell sse ssl svg svga tcpd tiff truetype unicode usb userlocales video_cards_radeon x86 xine
xml xml2 xmms xprint xv xvid zlib"
Comment 16 Simon Strandman 2004-10-08 15:04:02 UTC
Ignore my previous post. The problems where probably caused by some weird filesystem error trigered by my glibc update. There is a lot of xfs changes in 2.6.9-rc* and I use xfs on my / so I should report this to lkml instead.
Comment 17 solar (RETIRED) gentoo-dev 2004-10-09 07:22:12 UTC
Using -DNDEBUG in CFLAGS is a really bad idea. Don't do it. Your opening yourself to all sorts of holes and we wont take anything you report seriously.
Comment 18 Travis Tilley (RETIRED) gentoo-dev 2004-10-12 05:09:49 UTC
so... what does upstream think/say about this patch? lewk?
Comment 19 Luke Macken (RETIRED) gentoo-dev 2004-10-13 20:49:48 UTC
This issue still exists in the current libc cvs tree, and I have been unable to find any news regarding this issue on any of their mailing lists.  I'm pretty sure this issue never made it upstream from Trustix, so I helped.
Comment 20 Luke Macken (RETIRED) gentoo-dev 2004-10-17 12:57:14 UTC
Upstream shot down patch because there wasn't enough information about what exactly the problems that the patch fixes are.  I don't know much more about the patches, so I couldn't put anything else really.

Well, that was a waste of time.

Toolchain, it's your call what to do next.
Comment 21 Thierry Carrez (RETIRED) gentoo-dev 2004-10-20 04:38:53 UTC
This is CAN-2004-0968
Comment 23 Thierry Carrez (RETIRED) gentoo-dev 2004-10-20 07:28:32 UTC
In cvs, keywords maintained, upstream looks ok (from RedHat bug) :
This is all ready for a GLSA.
Comment 24 Luke Macken (RETIRED) gentoo-dev 2004-10-21 06:45:39 UTC
GLSA 200410-19