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

Bug 117116

Summary: media-libs/libdv-0.102: insecure RUNPATH
Product: Gentoo Security Reporter: Abraham Marin Perez <abraham>
Component: Runpath IssuesAssignee: media-video herd <media-video>
Status: RESOLVED FIXED    
Severity: minor CC: vapier
Priority: High    
Version: unspecified   
Hardware: x86   
OS: Linux   
Whiteboard: [ebuild]
Package list:
Runtime testing required: ---
Bug Depends on: 118073    
Bug Blocks: 81745    

Description Abraham Marin Perez 2005-12-29 12:18:32 UTC
I was running revdep-rebuild and one of the packages with broken dependencies was libdv. revdep-rebuild began to re-emerge libdv and, when making the executable file, this error appeared:

making executable: /usr/lib/libdv.so.4.0.0

QA Notice: the following files contain insecure RUNPATH's
 Please file a bug about this at http://bugs.gentoo.org/
 For more information on this issue, kindly review:
 http://bugs.gentoo.org/81745
/var/tmp/portage/libdv-0.102/image//usr/lib usr/bin/dubdv
/var/tmp/portage/libdv-0.102/image//usr/lib usr/bin/encodedv
/var/tmp/portage/libdv-0.102/image//usr/lib usr/bin/playdv
Comment 1 Abraham Marin Perez 2005-12-29 12:19:43 UTC
emerge info:

Portage 2.0.53 (default-linux/x86/2005.0, gcc-3.3.6, glibc-2.3.5-r1, 2.6.11-gentoo-r6 i686)
=================================================================
System uname: 2.6.11-gentoo-r6 i686 AMD Athlon(tm) XP 1700+
Gentoo Base System version 1.6.13
distcc 2.16 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]
ccache version 2.3 [disabled]
dev-lang/python:     2.3.5-r2, 2.4.2
sys-apps/sandbox:    1.2.12
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.15.92.0.2-r10
sys-devel/libtool:   1.5.20
virtual/os-headers:  2.6.8.1-r1, 2.6.11-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -pipe -march=athlon-xp -fomit-frame-pointer -fforce-addr -frerun-loop-opt -floop-optimize -frerun-cse-after-loop -falign-functions=4"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -pipe -march=athlon-xp -fomit-frame-pointer -fforce-addr -frerun-loop-opt -floop-optimize -frerun-cse-after-loop -falign-functions=4"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://linuv.uv.es/mirror/gentoo ftp://ftp.rediris.es/pub/linux/distributions/gentoo ftp://ftp.gentoo-pt.org/pub/gentoo/ ftp://mir.zyrianes.net/gentoo/ ftp://ftp.caliu.info/pub/gentoo/ http://mir.zyrianes.net/gentoo/"
LANG="es_ES.UTF-8"
LC_ALL="es_ES.UTF-8"
LINGUAS="es en ja"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="3dnow X acpi alsa apache2 audiofile avi bash-completion bidi bitmap-fonts browserplugin bzip2 bzlib canna cdr cjk crypt cups curl dga directfb divx4linux doc dvb dvd dvdr eds emboss encode esd ethereal evo exif expat fam fbcon ffmpeg fftw flac foomaticdb freewnn ftp gb gcj gd gdbm gif glut gmp gnome gstreamer gtk gtk2 gtkhtml hal iconv idn imagemagick imlib iodbc java jikes jpeg lcms libg++ libwww mad memlimit mikmod mime mmx mng motif mozilla mp3 mpeg msn nas nls nptl odbc offensive ogg oggvorbis openal opengl pam pcre pdflib perl png pnp posix ppds quicktime readline samba sdl sharedmem simplexml spell ssl svg svga sysvipc szip tcltk tcpd tetex theora threads tiff truetype truetype-fonts type1-fonts udev unicode usb userlocales videos vorbis wmf x86 xml xmms xv xvid zlib video_cards_nvidia linguas_es linguas_en linguas_ja userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, LDFLAGS, PORTDIR_OVERLAY
Comment 2 Stefan Cornelius (RETIRED) gentoo-dev 2005-12-29 13:45:08 UTC
mholzer, pls provide fixed ebuilds.
d'oh, rpath issues are becoming a serious annoyance ...
Comment 3 SpanKY gentoo-dev 2005-12-29 15:14:34 UTC
can you test 0.104 ?
Comment 4 solar (RETIRED) gentoo-dev 2005-12-29 21:11:35 UTC
(In reply to comment #2)
> d'oh, rpath issues are becoming a serious annoyance ...

I expect that with the recent addition of the pax-utils depend to portage 
we are going to see a flood of them for a month or two then 
hopefully we will see it slow down then trickle away to almost never again.

Comment 5 Thierry Carrez (RETIRED) gentoo-dev 2005-12-30 00:40:30 UTC
Any chance we could make this warning non-blocking (or easily unblockable) ? I don't mind the bugs so that we remember to fix it (although I would prefer to file them in a specific subcomponent) but they are usually minor risk (group portage needed) and their resolution delays are a little too large...
Comment 6 Abraham Marin Perez 2005-12-30 07:01:40 UTC
(In reply to comment #3)
> can you test 0.104 ?
> 

Hum... I tried with 0.104-r1 and it worked perfectly... But still I have a problem that (I thoght) could be related with this issue: new packages are apparently being installed with absolute references to files that belong to the same package; this causes problems after merging into /, since the path isn't right.

What I mean is, to mention a couple of examples, that gnome-terminal points to

/var/tmp/portage/gnome-terminal-2.10.0/image//usr/share/gnome-terminal/glade/gnome-terminal.glade2

where that file's right path is

/usr/share/gnome-terminal/glade/gnome-terminal.glade2

And the same happened with gnome-games, shall I report a new bug with this? Is it a problem of my configuration? Is it related with the RUNPATH problem (since it also included the path of the compilation dir)?
Comment 7 solar (RETIRED) gentoo-dev 2005-12-30 08:37:11 UTC
(In reply to comment #5)
> Any chance we could make this warning non-blocking (or easily unblockable) ? 

We could but I dont think that it would be a very wise or responsible thing todo for a distro.

> I don't mind the bugs so that we remember to fix it (although I would prefer 
> to file them in a specific subcomponent) but they are usually minor risk 
> (group portage needed) and their resolution delays are a little too large...

Thats tricky. There are several classes of RPATH checks that take place.
The logic is as follows.

-------------------------------------------------------------------------------
static void rpath_security_checks(elfobj *elf, char *item) {
        struct stat st;
        switch (*item) {
                case '/': break;
                case '.':
                        warnf("Security problem with relative RPATH '%s' in %s", item, elf->filename);
                        break;
                case '\0':
                        warnf("Security problem NULL RPATH in %s", elf->filename);
                        break;
                case '$':
                        if (fstat(elf->fd, &st) != -1)
                                if ((st.st_mode & S_ISUID) || (st.st_mode & S_ISGID))
                                        warnf("Security problem with RPATH='%s' in %s with mode set of %o",
                                                item, elf->filename, st.st_mode & 07777);
                        break;
                default:
                        warnf("Maybe? sec problem with RPATH='%s' in %s", item, elf->filename);
                        break;
        }
}
-------------------------------------------------------------------------------

Case 0 is the one you mention koon.
But 1 & 2 '.' & '\0' are the two really bad ones that we must abort on.
Comment 8 Thierry Carrez (RETIRED) gentoo-dev 2006-01-01 03:23:27 UTC
Then we should not abort on the /var/tmp/portage case, which represents 95% of the rpath problem cases and that 95% of our users don't care about.

This is breaking large parts of stable portage packages, lots of bugs are created but only a few are fixed, so this needs to be changed asap... I agree to break on the null cases which are evil, but certainly not on the /var/tmp/portage thing.

I'll file a specific bug about this. Not sure who we should assign it to though. 
Comment 9 Thierry Carrez (RETIRED) gentoo-dev 2006-01-01 03:40:51 UTC
See bug 117335 for followup on this off-topic discussion
Comment 10 Thierry Carrez (RETIRED) gentoo-dev 2006-01-15 09:53:11 UTC
media-video / vapier, could you have a look at comment #6 about absolute refs ?
Comment 11 Diego Elio Pettenò (RETIRED) gentoo-dev 2006-01-15 10:03:31 UTC
Now if vapier can tell me why he blocked 0.104-r1 stable marking (bug #118073) we can solve this problem, i think?
Comment 12 Thierry Carrez (RETIRED) gentoo-dev 2006-01-15 10:11:53 UTC
Yes, "0.104-r1 should not be stable" needs some explanation.
Comment 13 solar (RETIRED) gentoo-dev 2006-03-05 08:02:53 UTC
The next ~arch portage revision will auto repair evil rpaths and not bail. 
Maintainers should still fix the packages they maintain as portage will only die
with FEATURES=stricter (but that is a maintainer & QA problem) no longer security@

http://bugs.gentoo.org/show_bug.cgi?id=124962
Comment 14 SpanKY gentoo-dev 2006-03-05 20:21:23 UTC
> Now if vapier can tell me why he blocked 0.104-r1 stable marking (bug #118073)
> we can solve this problem, i think?

look at Bug 121871

i havent gotten around to fixing the PIC patch
Comment 15 Jakub Moc (RETIRED) gentoo-dev 2006-09-21 03:37:39 UTC
No longer a security issue with current stable portage, re-assigning to maintainer.
Comment 16 SpanKY gentoo-dev 2006-09-24 06:01:53 UTC
0.104 works fine
Comment 17 Abraham Marin Perez 2006-09-26 01:39:37 UTC
0.104-r1 also merged successfully, shall it be marked as stable?
Comment 18 SpanKY gentoo-dev 2006-09-26 14:19:47 UTC
go to Bug 118073