https://bugzilla.novell.com/show_bug.cgi?id=706670 https://bugzilla.novell.com/show_bug.cgi?id=706670#c0 Summary: $LD_LIBRARY_PATH evaluates ':' incorrectly as '.' leading to a vulnerability Classification: openSUSE Product: openSUSE 11.3 Version: Final Platform: All OS/Version: openSUSE 11.3 Status: NEW Severity: Critical Priority: P5 - None Component: Security AssignedTo: security-team@suse.de ReportedBy: external.martin.konold@de.bosch.com QAContact: qa@suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.2.17) Gecko/20110420 SUSE/3.6.17-0.2.1 Firefox/3.6.17 A $LD_LIBRARY_PATH which ends with ":" is treated like a '.' in some cases. This leads to a potential exploit. The problem was discovered on OpenSUSE 11.3 (uptodate) and it is verified that it does not happen with SLES10SP4. Further systems can be easily examined upon request. Reproducible: Always Steps to Reproduce: 1. as user nobody copy /lib/libc.so.6 to /tmp 2. as user someuser verify that $LD_LIBRARY_PATH is empty 3. as user someuser execute "export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH 4. as user someuser $LD_LIBRARY_PATH using "printenv LD_LIBRARY_PATH" 5. the result look like someuser@machine:~> printenv LD_LIBRARY_PATH /usr/local/lib/: 6. as user someuser execute "ldd /bin/ls" in $HOME 7. verify that the result will look like someuser@machine:~> ldd /bin/ls linux-vdso.so.1 => (0x00007fffe29ff000) librt.so.1 => /lib64/librt.so.1 (0x00002b464f03d000) libacl.so.1 => /lib64/libacl.so.1 (0x00002b464f146000) libc.so.6 => /lib64/libc.so.6 (0x00002b464f24d000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b464f48e000) /lib64/ld-linux-x86-64.so.2 (0x00002b464ef21000) libattr.so.1 => /lib64/libattr.so.1 (0x00002b464f5a7000) 8. This is fine 9. as user someuser change to directory /tmp (cd /tmp) 10. 6. as user someuser execute "ldd /bin/ls" in $HOME 7. verify that the result will on SLES10SP4 look like someuser@machine:tmp> ldd /bin/ls linux-vdso.so.1 => (0x00007fff45dff000) librt.so.1 => /lib64/librt.so.1 (0x00002ac2f283d000) libacl.so.1 => /lib64/libacl.so.1 (0x00002ac2f2946000) libc.so.6 => /lib64/libc.so.6 (0x00002ac2f2a4d000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00002ac2f2c8e000) /lib64/ld-linux-x86-64.so.2 (0x00002ac2f2721000) libattr.so.1 => /lib64/libattr.so.1 (0x00002ac2f2da7000) But on OpenSUSE 11.3 (did not check other versions sofar) it will look like: someuser@machine:tmp> ldd /bin/ls linux-gate.so.1 => (0xb783e000) librt.so.1 => /lib/librt.so.1 (0xb77f3000) libselinux.so.1 => /lib/libselinux.so.1 (0xb77d4000) libcap.so.2 => /lib/libcap.so.2 (0xb77ce000) libacl.so.1 => /lib/libacl.so.1 (0xb77c4000) libc.so.6 (0xb7658000) libpthread.so.0 => /lib/libpthread.so.0 (0xb763d000) /lib/ld-linux.so.2 (0xb7820000) libdl.so.2 => /lib/libdl.so.2 (0xb7638000) libattr.so.1 => /lib/libattr.so.1 (0xb7632000) Actual Results: With OpenSUSE 11.3 a LD_LIBRARY_PATH=/some/trusted/path: leads to cwd to be prepended in the search path for shared libraries. someuser@machine:tmp> ldd /bin/ls linux-gate.so.1 => (0xb783e000) librt.so.1 => /lib/librt.so.1 (0xb77f3000) libselinux.so.1 => /lib/libselinux.so.1 (0xb77d4000) libcap.so.2 => /lib/libcap.so.2 (0xb77ce000) libacl.so.1 => /lib/libacl.so.1 (0xb77c4000) libc.so.6 (0xb7658000) libpthread.so.0 => /lib/libpthread.so.0 (0xb763d000) /lib/ld-linux.so.2 (0xb7820000) libdl.so.2 => /lib/libdl.so.2 (0xb7638000) libattr.so.1 => /lib/libattr.so.1 (0xb7632000) The problem does not exist with SLES10SP4 Expected Results: someuser@machine:tmp> ldd /bin/ls linux-gate.so.1 => (0xb783e000) librt.so.1 => /lib/librt.so.1 (0xb77f3000) libselinux.so.1 => /lib/libselinux.so.1 (0xb77d4000) libcap.so.2 => /lib/libcap.so.2 (0xb77ce000) libacl.so.1 => /lib/libacl.so.1 (0xb77c4000) libc.so.6 => /lib/libc.so.6 (0xb7658000) libpthread.so.0 => /lib/libpthread.so.0 (0xb763d000) /lib/ld-linux.so.2 (0xb7820000) libdl.so.2 => /lib/libdl.so.2 (0xb7638000) libattr.so.1 => /lib/libattr.so.1 (0xb7632000) I think that this change in semantics is security relevant as many installations have stuff like "export LD_LIBRARY_PATH=/some/trusted/path/lib:$LD_LIBRARY_PATH" in the local shell environments by default. If really required provide a test script and test on more SUSE platforms including SLES11. In addition I can trivially provide an exploit. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.