Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 135974 - {x11-base/xorg-x11|x11-terms/xterm} Unchecked set*uid() calls
Summary: {x11-base/xorg-x11|x11-terms/xterm} Unchecked set*uid() calls
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Gentoo Security
Whiteboard: A1 [glsa] DerCorny
: 138458 (view as bug list)
Depends on:
Blocks: 143647
  Show dependency tree
Reported: 2006-06-07 12:30 UTC by Sune Kloppenborg Jeppesen (RETIRED)
Modified: 2019-12-25 20:03 UTC (History)
7 users (show)

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

Most of modular (setuid-modular-1.diff,8.26 KB, patch)
2006-06-14 09:13 UTC, Donnie Berkholz (RETIRED)
no flags Details | Diff
libX11 (setuid-modular-2.diff,420 bytes, patch)
2006-06-14 09:14 UTC, Donnie Berkholz (RETIRED)
no flags Details | Diff
Monolith 6.9 (setuid-Xorg-6.9.diff,13.57 KB, patch)
2006-06-14 09:14 UTC, Donnie Berkholz (RETIRED)
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-06-07 12:30:32 UTC
Dirk Mueller and I have been checking for setuid/seteuid without return

One offender who is exploitable we think is X. Both X.Org and XFree86.

For the readers who just joined a brief summary:

  In kernel 2.6 it is possible that setuid(user_uid); can fail even
  if done from root a process.

  Reason is that there is the maximum processes "ulimit" which is 
  honoured by setuid(), seteuid(), set*uid().
  If you do not check the return value and continue as-is you have
  not dropped the privilege, but run as root.

  An example of this has been released in "vixie-cron".

  Since ulimits on maximum processes are set by the kernel by default,
  any Linux 2.6 system is default affected.

  Fix: Check the return value of setuid() and handle it and/or
  check with getuid() right after the setuid() if it worked.

My evaluation might be off and it might not be exploitable in these

If this is exploitable I would propose an embargo of 2 weeks.
(Tue June 20th 12:00 UTC would be a nice date)

Critical MUST FIX problems:
./programs/Xserver/hw/xfree86/common/xf86Init.c:          setuid(getuid());
        Security relevant and critical.
        After this "sh -c "vtinit"" is called, which might be exploitable.

        (SUSE has the X Server setuid root, so this would affect us.)

./programs/Xserver/hw/xfree86/parser/write.c:                   setuid(getuid());
        Security relevant and critical.
        Can corrupt any file on the system, like /etc/shadow.
        (I think via: Xorg -configure --... /etc/shadow)

./programs/Xserver/hw/xfree86/os-support/shared/libc_wrapper.c:        setuid(getuid());
        Security relevant and critical.
        In xf86execl(), which I do not know who calls it.

./programs/Xserver/os/utils.c:  setuid(getuid());
./programs/Xserver/os/utils.c:  setuid(getuid());
./programs/Xserver/os/utils.c:  setuid(getuid());
        Security relevant and critical.
        These are in Popen(), Fopen(), System().

        Leak file content, start called programs as root.

All of them above are in the XServer.

Normal problems, but should be fixed probably:

./lib/X11/lcFile.c:         if (seteuid(0) != 0) {
./lib/X11/lcFile.c:             seteuid(oldeuid);

./lib/xtrans/Xtranslcl.c:       setuid( getuid() ); /** sets the euid to the actual/real uid **/
        Obscure, not used in modern systems.

./config/util/chownxterm.c:    setuid(getuid());
./config/util/chownxterm.c:    setuid(getuid());
        No setuid/setgid xterm used, we have utempter and devpts.

./programs/xdm/session.c:       setuid (verify.uid);
        This needs to be fixed, but is not security critical.

        It is called before the KRB5 tickets are dropped
        and the user auth is removed.

./programs/xdm/xdmshell.c:    setuid (geteuid());
        Should be fixed. In common use scenarios it is not setuid-root,
        so not critical.

./programs/xinit/xinit.c:               setuid(getuid());
        Security relevant.
        Must be fixed. This is critical when xinit is setuid-root,
        but I do not know if anyone has it so.

./programs/xload/xload.c:    setuid(getuid());
        Security relevant.
        No one ships xload setuid root anymore, but it should be fixed.

./programs/xterm/main.c:    seteuid(getuid());
./programs/xterm/main.c:    setuid(getuid());
./programs/xterm/main.c:    seteuid(getuid());
./programs/xterm/main.c:    setuid(getuid());
./programs/xterm/main.c:        seteuid(0);
./programs/xterm/main.c:        seteuid(getuid());
./programs/xterm/main.c:        setuid(screen->uid);
./programs/xterm/main.c:            if (setuid(screen->uid)) {
./programs/xterm/misc.c:        setuid(uid);
./programs/xterm/misc.c:            setuid(screen->uid);
./programs/xterm/os2main.c:     setuid(screen->uid);
./programs/xterm/os2main.c:         setuid(screen->uid);
./programs/xterm/print.c:           setuid(screen->uid);
        No one ships xterm setuid root anymore, but it should be fixed
        for those who do.

./programs/xf86dga/dga.c:   setuid(getuid());
        The old DGA binary, not shipped setuid root at SUSE.
        It does not do much exploitable afterwards, but it usually
        destroys your X session anyway, so it is better to not run it.

Ciao, Marcus
Comment 1 Stefan Cornelius (RETIRED) gentoo-dev 2006-06-13 02:34:00 UTC
heya spyderous, this is from v-s, please have a look and recommend what you would like to do here.
Comment 2 Donnie Berkholz (RETIRED) gentoo-dev 2006-06-13 08:59:16 UTC
From the looks of it, it's certainly real bugs. I'll leave the question of how exploitable they are to upstream. For reference, the upstream bug is although none of you will have access to it. =) There have been no comments on it since June 5, but it does contain patches.
Comment 3 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-06-14 03:46:23 UTC
Setting it to upstream until we have the patches.
Comment 4 Donnie Berkholz (RETIRED) gentoo-dev 2006-06-14 09:13:10 UTC
Created attachment 89172 [details, diff]
Most of modular
Comment 5 Donnie Berkholz (RETIRED) gentoo-dev 2006-06-14 09:14:09 UTC
Created attachment 89173 [details, diff]

Note, the modular patches lack the patches against xterm. But they are in the monolith patch.
Comment 6 Donnie Berkholz (RETIRED) gentoo-dev 2006-06-14 09:14:56 UTC
Created attachment 89174 [details, diff]
Monolith 6.9

With luck, will apply to 6.8 as well. Can pull xterm diff out of here.
Comment 7 Donnie Berkholz (RETIRED) gentoo-dev 2006-06-14 09:18:43 UTC
btw, exg should probably be on here as xterm maintainer.
Comment 8 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-06-14 09:23:55 UTC
Adding Emanuele.
Comment 9 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-06-15 09:17:28 UTC
@Thomas: could you post a mail to vendor-sec saying when you will announce the new version (and give access to it so that vendors have a bit of time to prepare a package?) Alternatively you can let me know and I'll forward the information. 
Comment 10 Donnie Berkholz (RETIRED) gentoo-dev 2006-06-20 06:39:47 UTC
Recommend no GLSA. From the advisory:

"This can be used by a malicious local user to
overwrite files and possibly elevate privileges in some corner
Comment 11 Tavis Ormandy (RETIRED) gentoo-dev 2006-06-20 13:03:37 UTC
hmm, I'm not sure what you're trying to point out spyderous, I've seen a demonstration of an unprivileged user trashing /etc/shadow via X -configure, which certainly merits a GLSA, imho.
Comment 12 Donnie Berkholz (RETIRED) gentoo-dev 2006-06-20 13:14:32 UTC
Eh, whatever makes you happy. Link to advisory:

Ebuilds in portage for all issues now, with the exception of xterm because I don't maintain it. xorg-x11-6.8.2-r8 will require stabling on all arches, the rest were ~arch before.

Complete list of "safe" versions:
&& ( >=xorg-server-1.0.2-r6 <xorg-server-1.1 )
&& ( >=xorg-x11-6.8.2-r8 <xorg-x11-6.9 )
Comment 13 Emanuele Giaquinta (RETIRED) gentoo-dev 2006-06-20 14:34:22 UTC
xterm-215, which is fixed wrt the issue, is in the tree now.
Comment 14 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-06-21 08:25:47 UTC
Opening since this is public now.

Arches please test and mark stable.
Comment 15 Donnie Berkholz (RETIRED) gentoo-dev 2006-06-21 08:33:26 UTC
To clarify, xorg-x11-6.8.2-r8 and xterm-215 need stabling.
Comment 16 Gustavo Zacarias (RETIRED) gentoo-dev 2006-06-21 15:23:35 UTC
sparc stable.
Comment 17 Joshua Jackson (RETIRED) gentoo-dev 2006-06-21 22:35:43 UTC
xterm is stable..however xorg has at least one depend that needs to go first.

x11-base/xorg-x11/xorg-x11-6.8.2-r8.ebuild: x86(hardened/x86) ['x11-misc/linuxwacom']

please advise.
Comment 18 Joshua Jackson (RETIRED) gentoo-dev 2006-06-21 22:36:07 UTC
didn't mean to remove x86 ^.^;;
Comment 19 Donnie Berkholz (RETIRED) gentoo-dev 2006-06-21 23:05:03 UTC
The hardened/x86 2.4 kernel profile is currently broken wrt X because of this issue. I recommend you temporarily remove it from your profiles.desc, as it was just added earlier this month. Work is in progress to fix this.
Comment 20 Chris Gianelloni (RETIRED) gentoo-dev 2006-06-22 09:23:27 UTC
I think I'd rather just fix the problem.  Removing -input_devices_wacom from use.mask on the hardened profile solves the issue.

xorg-x11-6.8.2-r8 stable on x86
Comment 21 Donnie Berkholz (RETIRED) gentoo-dev 2006-06-22 10:30:14 UTC
That just masks the breakage, it will still be pulled in on INPUT_DEVICES="" because we don't have a way to do dep strings depending on kernel in profile.
Comment 22 Markus Rothe (RETIRED) gentoo-dev 2006-06-24 01:58:45 UTC
stable on ppc64
Comment 23 Tobias Scherbaum (RETIRED) gentoo-dev 2006-06-25 02:42:24 UTC
ppc stable
Comment 24 Thomas Dickey 2006-06-25 08:35:39 UTC
Emanuele Giaquinta pointed this out to me (there's some problem with
email from this bugzilla to, so I subscribed from
Comment 25 Guy Martin (RETIRED) gentoo-dev 2006-06-27 00:53:10 UTC
Stable on hppa.
Comment 26 Peter Weller (RETIRED) gentoo-dev 2006-06-29 04:32:57 UTC
Stable on amd64
Comment 27 Simon Stelling (RETIRED) gentoo-dev 2006-06-29 04:41:05 UTC
xterm is stable on amd64, but i can't stablize xorg-x11 for some reason, repoman gives me a huge load of RDEPEND.bad errors for modular X on all arches. can someone else from amd64 give it a try please?
Comment 28 Simon Stelling (RETIRED) gentoo-dev 2006-06-29 04:41:13 UTC
*** Bug 138458 has been marked as a duplicate of this bug. ***
Comment 29 Donnie Berkholz (RETIRED) gentoo-dev 2006-06-29 06:34:09 UTC
(In reply to comment #27)
> xterm is stable on amd64, but i can't stablize xorg-x11 for some reason,
> repoman gives me a huge load of RDEPEND.bad errors for modular X on all arches.
> can someone else from amd64 give it a try please?

Run cvs up in the other directories you're getting errors from (probably x11-drivers), and profiles and eclass.
Comment 30 Donnie Berkholz (RETIRED) gentoo-dev 2006-06-29 06:35:07 UTC
FYI libX11 1.0.2 missed one of the security fixes, so please don't GLSA this until I release and add 1.0.3.
Comment 31 Thomas Cort (RETIRED) gentoo-dev 2006-06-29 08:42:21 UTC
(In reply to comment #27)
> xterm is stable on amd64, but i can't stablize xorg-x11 for some reason,
> repoman gives me a huge load of RDEPEND.bad errors for modular X on all arches.
> can someone else from amd64 give it a try please?

I didn't get any RDEPEND.bad errors.
xorg-x11-6.8.2-r8 stable on amd64.
Comment 32 Thomas Cort (RETIRED) gentoo-dev 2006-06-30 06:06:02 UTC
alpha stable.
Comment 33 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-06-30 08:48:20 UTC
Back to ebuild status awaiting libX11 1.0.3
Comment 34 Joshua Kinard gentoo-dev 2006-07-08 21:07:57 UTC
xterm-215 is stable on mips, and I believe we're de-keywording 6.*, since 7.1 is stable for us.  Leaving on CC until resolved.
Comment 35 Thierry Carrez (RETIRED) gentoo-dev 2006-08-12 03:29:21 UTC
AFAICT libX11-1.0.3 is in, time to mark stable, I guess.
Comment 36 Andrej Kacian (RETIRED) gentoo-dev 2006-08-12 05:41:55 UTC
What exactly it is you want arches to test and stabilize? I haven't been following this issue.
Comment 37 Markus Rothe (RETIRED) gentoo-dev 2006-08-12 08:09:38 UTC
libX11-1.0.3 and xproto-7.0.7 (dependency) stable on ppc64
Comment 38 Christian Faulhammer (RETIRED) gentoo-dev 2006-08-12 12:49:02 UTC
x86 needs x11-proto/xproto-7.0.7 and x11-libs/libX11-1.0.3

1) both emerge fine
2) pass collision test
3) libX11 passes test suite
4) X starts with Gnome, KDE and XSession
5) and please change subjects to the desired packages or give a useful cc comment

Portage 2.1-r1 (default-linux/x86/2006.0, gcc-3.4.6, glibc-2.3.6-r4, 2.6.17-gentoo-r4 i686)
System uname: 2.6.17-gentoo-r4 i686 AMD Athlon(tm) XP 2500+
Gentoo Base System version 1.6.15
app-admin/eselect-compiler: [Not Present]
dev-lang/python:     2.4.3-r1
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     [Not Present]
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.16.1-r3
sys-devel/gcc-config: 1.3.13-r3
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r2
CONFIG_PROTECT="/etc /usr/share/X11/xkb"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/splash /etc/terminfo"
FEATURES="autoconfig ccache collision-protect distlocks metadata-transfer parallel-fetch sandbox sfperms strict test"
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'"
USE="x86 3dnow 3dnowext X Xaw3d a52 alsa arts artworkextra asf audiofile avi bash-completion beagle berkdb bidi bitmap-fonts bootsplash branding bzip2 cairo cdda cddb cdparanoia cdr cli cracklib crypt css cups curl custom-cflags dbus dga directfb divx4linux dlloader dri dts dvd dvdr dvdread dvi eds emacs emboss encode esd evo exif expat fam fat fbcon ffmpeg firefox foomaticdb fortran ftp gb gcj gdbm gif gnome gpm gstreamer gtk gtk2 gtkhtml hal icq idn imagemagick imap imlib ipv6 isdnlog java javascript jikes jpeg jpeg2k ldap leim libg++ libwww lm_sensors mad maildir matroska mbox mikmod mime mmx mmxext mng mono motif mp3 mpeg mpeg2 mule nautilus ncurses nforce2 nls nocardbus nptl nptlonly nsplugin nvidia objc ogg opengl pam pcre pdf pdflib perl plotutils pmu png ppds pppd preview-latex print python qt3 qt4 quicktime readline reflection reiserfs samba sdk session slang spell spl sse ssl svg svga t1lib tcltk tcpd theora thunderbird tiff truetype truetype-fonts type1-fonts udev usb vcd videos vorbis win32codecs wmf wxwindows xine xml xorg xosd xv xvid zlib elibc_glibc input_devices_mouse input_devices_keyboard kernel_linux linguas_de userland_GNU video_cards_radeon video_cards_vesa video_cards_fbdev"
Comment 39 René Nussbaumer (RETIRED) gentoo-dev 2006-08-12 13:15:20 UTC
remove us from cc.
Comment 40 René Nussbaumer (RETIRED) gentoo-dev 2006-08-12 13:16:17 UTC
damn. that was the wrong bug. Readded.
Comment 41 Donnie Berkholz (RETIRED) gentoo-dev 2006-08-12 15:56:45 UTC
libX11 1.0.1-r1 is fine, so is libX11 1.0.3 -- 1.0.3 has lots of changes though, so please test carefully if you're stabilizing.
Comment 42 Simon Stelling (RETIRED) gentoo-dev 2006-08-14 09:53:32 UTC
1.0.1-r1 is already stable on amd64, as it's secure we're out
Comment 43 Tobias Scherbaum (RETIRED) gentoo-dev 2006-08-14 10:13:39 UTC
(In reply to comment #42)
> 1.0.1-r1 is already stable on amd64, as it's secure we're out

Same for ppc.
Comment 44 Thomas Cort (RETIRED) gentoo-dev 2006-08-14 10:24:26 UTC
(In reply to comment #42)
> 1.0.1-r1 is already stable on amd64, as it's secure we're out

Same for alpha
Comment 45 Joshua Jackson (RETIRED) gentoo-dev 2006-08-14 20:50:38 UTC
x86 stable and gone ^.^;;
Comment 46 René Nussbaumer (RETIRED) gentoo-dev 2006-08-15 04:27:39 UTC
stable on hppa also.
Comment 47 Gustavo Zacarias (RETIRED) gentoo-dev 2006-08-17 17:18:30 UTC
sparc is clean since we don't have modular stable yet.
Comment 48 Donnie Berkholz (RETIRED) gentoo-dev 2006-08-17 17:41:16 UTC
It would be helpful if you could say in the GLSA that it's actually been available and stable for most architectures since 30 June, and the release has just been held up.
Comment 49 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2006-08-18 03:04:33 UTC
Thanks teams

(In reply to comment #48)
> It would be helpful if you could say in the GLSA that it's actually been
> available and stable for most architectures since 30 June, and the release has
> just been held up.

mmm, we'll try to add that. Thanks.
Comment 50 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-08-19 11:15:03 UTC
Accepting bug.
Comment 51 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2006-08-28 10:04:07 UTC
GLSA 200608-25