Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

Dirk Mueller and I have been checking for setuid/seteuid without return
checks.

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

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);
        Obscure.

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

heya spyderous, this is from v-s, please have a look and recommend what you
would like to do here.

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
https://bugs.freedesktop.org/show_bug.cgi?id=7116 although none of you will
have access to it. =) There have been no comments on it since June 5, but it
does contain patches.

Setting it to upstream until we have the patches.

Created an attachment (id=89172) [details]
Most of modular

Created an attachment (id=89173) [details]
libX11

Note, the modular patches lack the patches against xterm. But they are in the
monolith patch.

Created an attachment (id=89174) [details]
Monolith 6.9

With luck, will apply to 6.8 as well. Can pull xterm diff out of here.

btw, exg should probably be on here as xterm maintainer.

Adding Emanuele.

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

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

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.

Eh, whatever makes you happy. Link to advisory:
http://lists.freedesktop.org/archives/xorg/2006-June/016146.html

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:
>=libX11-1.0.1-r1
>=xdm-1.0.4-r1
>=xf86dga-1.0.1-r1
>=xinit-1.0.2-r6
>=xload-1.0.1-r1
&& ( >=xorg-server-1.0.2-r6 <xorg-server-1.1 )
>=xorg-server-1.1.0-r1
>=xtrans-1.0.0-r1
&& ( >=xorg-x11-6.8.2-r8 <xorg-x11-6.9 )
>=xorg-x11-6.9.0-r2

xterm-215, which is fixed wrt the issue, is in the tree now.

Opening since this is public now.

Arches please test and mark stable.

To clarify, xorg-x11-6.8.2-r8 and xterm-215 need stabling.

sparc stable.

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.

didn't mean to remove x86 ^.^;;

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.

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

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.

stable on ppc64

ppc stable

Emanuele Giaquinta pointed this out to me (there's some problem with
email from this bugzilla to radix.net, so I subscribed from his.com).

Stable on hppa.

Stable on amd64

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?

*** Bug 138458 has been marked as a duplicate of this bug. ***

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

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.

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

alpha stable.

Back to ebuild status awaiting libX11 1.0.3

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.

AFAICT libX11-1.0.3 is in, time to mark stable, I guess.

What exactly it is you want arches to test and stabilize? I haven't been
following this issue.

libX11-1.0.3 and xproto-7.0.7 (dependency) stable on ppc64

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
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/X11/xkb"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/splash
/etc/terminfo"
CXXFLAGS="-O2"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache collision-protect distlocks metadata-transfer
parallel-fetch sandbox sfperms strict test"
GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo/"
LANG="de_DE@euro"
LC_ALL="de_DE@euro"
LINGUAS="de"
MAKEOPTS="-j2"
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'"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.informatik.rwth-aachen.de/gentoo-portage"
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"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS,
PORTAGE_RSYNC_EXTRA_OPTS

remove us from cc.

damn. that was the wrong bug. Readded.

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.

1.0.1-r1 is already stable on amd64, as it's secure we're out

(In reply to comment #42)
> 1.0.1-r1 is already stable on amd64, as it's secure we're out

Same for ppc.

(In reply to comment #42)
> 1.0.1-r1 is already stable on amd64, as it's secure we're out

Same for alpha

x86 stable and gone ^.^;;

stable on hppa also.

sparc is clean since we don't have modular stable yet.

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.

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.

Accepting bug.

GLSA 200608-25