-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, A short time ago a "local root" exploit was posted to the full-disclosure mailing list; as the name suggests, this allows a local user to execute arbitrary code as root. Normally it is the policy of the FreeBSD Security Team to not publicly discuss security issues until an advisory is ready, but in this case since exploit code is already widely available I want to make a patch available ASAP. Due to the short timeline, it is possible that this patch will not be the final version which is provided when an advisory is sent out; it is even possible (although highly doubtful) that this patch does not fully fix the issue or introduces new issues -- in short, use at your own risk (even more than usual). The patch is at http://people.freebsd.org/~cperciva/rtld.patch and has SHA256 hash ffcba0c20335dd83e9ac0d0e920faf5b4aedf366ee5a41f548b95027e3b770c1 I expect a full security advisory concerning this issue will go out on Wednesday December 2nd. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAksUbjcACgkQFdaIBMps37LP9ACgljaYCfgVuhD2gd9Natpq4H/9 i48An1mgl+Mih+AWN7J9KZ1rsiEU31IZ =MPXj -----END PGP SIGNATURE----- -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, A short time ago a "local root" exploit was posted to the full-disclosure mailing list; as the name suggests, this allows a local user to execute arbitrary code as root. Normally it is the policy of the FreeBSD Security Team to not publicly discuss security issues until an advisory is ready, but in this case since exploit code is already widely available I want to make a patch available ASAP. Due to the short timeline, it is possible that this patch will not be the final version which is provided when an advisory is sent out; it is even possible (although highly doubtful) that this patch does not fully fix the issue or introduces new issues -- in short, use at your own risk (even more than usual). The patch is at http://people.freebsd.org/~cperciva/rtld.patch and has SHA256 hash ffcba0c20335dd83e9ac0d0e920faf5b4aedf366ee5a41f548b95027e3b770c1 I expect a full security advisory concerning this issue will go out on Wednesday December 2nd. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAksUbjcACgkQFdaIBMps37LP9ACgljaYCfgVuhD2gd9Natpq4H/9 i48An1mgl+Mih+AWN7J9KZ1rsiEU31IZ =MPXj -----END PGP SIGNATURE----- -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid
Colin, Thank you so much for alerting us and providing a temporary patch. I had a user attempt to use the public exploit today, but due to /tmp being noexec, it failed. Luckily I caught him before he modified the script to work though. Now I am patched and can sleep tonight :) Thanks, Bryan FreeBSD Security Officer wrote:> Hi all, > > A short time ago a "local root" exploit was posted to the full-disclosure > mailing list; as the name suggests, this allows a local user to execute > arbitrary code as root. > > Normally it is the policy of the FreeBSD Security Team to not publicly > discuss security issues until an advisory is ready, but in this case > since exploit code is already widely available I want to make a patch > available ASAP. Due to the short timeline, it is possible that this > patch will not be the final version which is provided when an advisory > is sent out; it is even possible (although highly doubtful) that this > patch does not fully fix the issue or introduces new issues -- in short, > use at your own risk (even more than usual). > > The patch is at > http://people.freebsd.org/~cperciva/rtld.patch > and has SHA256 hash > ffcba0c20335dd83e9ac0d0e920faf5b4aedf366ee5a41f548b95027e3b770c1 > > I expect a full security advisory concerning this issue will go out on > Wednesday December 2nd.
At 06:20 PM 11/30/2009, FreeBSD Security Officer wrote:>A short time ago a "local root" exploit was posted to the full-disclosure >mailing list; as the name suggests, this allows a local user to execute >arbitrary code as root.Yargh. Thank you for catching this. --Brett
Colin, *, good day. Tue, Dec 01, 2009 at 01:20:45AM +0000, FreeBSD Security Officer wrote:> A short time ago a "local root" exploit was posted to the full-disclosure > mailing list; as the name suggests, this allows a local user to execute > arbitrary code as root. > > [...] > > The patch is at > http://people.freebsd.org/~cperciva/rtld.patch > and has SHA256 hash > ffcba0c20335dd83e9ac0d0e920faf5b4aedf366ee5a41f548b95027e3b770c1Just to ease other's life: for 7.1 (and 7.0, but it seems to be at EoL now, so there is already no support for it), one should use another patch: ----- http://codelabs.ru/fbsd/patches/vulns/freebsd-7.0-rtld-unsetenv.diff SHA256 (freebsd-7.0-rtld-unsetenv.diff) = e5ebbea24073bf644d3bc0c1ba37674a387af656b4c7e583a564a83598930897 SHA1 (freebsd-7.0-rtld-unsetenv.diff) = 24a79be52be0ea00ed0ea279f25efbf597f9c850 ----- Actually, every system that has rtld.c with r190323 or lower, should use this variant -- clearing of LD_ELF_HINTS_PATH was introduced only in r190324. By the way, if people are using NO_DYNAMIC_ROOT and all setuid executables come from the system itself (no sudo and other stuff from ports or manual installations), such system is obviously safe from this issue -- no dynamic loading takes place. I don't mean that people with such systems shouldn't upgrade, but they probably can do it with a least urgency. Thanks for posting the patch! -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ #
yeah noexec /tmp is nice cat /tmp/shellscript | bash same with executables It is good against level0 kiddies and bots On Tue, Dec 1, 2009 at 4:28 AM, Bryan Drewery <bryan@xzibition.com> wrote:> Colin, > > Thank you so much for alerting us and providing a temporary patch. I had > a user attempt to use the public exploit today, but due to /tmp being > noexec, it failed. Luckily I caught him before he modified the script to > work though. Now I am patched and can sleep tonight :) > > Thanks, > Bryan > > FreeBSD Security Officer wrote: > > Hi all, > > > > A short time ago a "local root" exploit was posted to the full-disclosure > > mailing list; as the name suggests, this allows a local user to execute > > arbitrary code as root. > > > > Normally it is the policy of the FreeBSD Security Team to not publicly > > discuss security issues until an advisory is ready, but in this case > > since exploit code is already widely available I want to make a patch > > available ASAP. Due to the short timeline, it is possible that this > > patch will not be the final version which is provided when an advisory > > is sent out; it is even possible (although highly doubtful) that this > > patch does not fully fix the issue or introduces new issues -- in short, > > use at your own risk (even more than usual). > > > > The patch is at > > http://people.freebsd.org/~cperciva/rtld.patch > > and has SHA256 hash > > ffcba0c20335dd83e9ac0d0e920faf5b4aedf366ee5a41f548b95027e3b770c1 > > > > I expect a full security advisory concerning this issue will go out on > > Wednesday December 2nd. > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org > " >-- the sun shines for all http://l1xl1x.blogspot.com
* Eygene Ryabinkin schrieb:> Colin, *, good day. > > Tue, Dec 01, 2009 at 01:20:45AM +0000, FreeBSD Security Officer wrote: > > A short time ago a "local root" exploit was posted to the full-disclosure > > mailing list; as the name suggests, this allows a local user to execute > > arbitrary code as root.I am new to patching systems, so forgive "stupid" questions. We have some 6.1 systems. Are or will there be a patch for them or are they not involved in this problem? I am new to patching systems, so forgive me any stupid questions. We have some 6.1 and 6.3 systems. Are or will there be patches fro them or are they not involved in this problem? How do i apply such a patch? With freebsd-update? As far as i know is this tool only for systems >= 6.3 or? Thx Alex
Hi,> I am new to patching systems, so forgive "stupid" questions. We have some 6.1 > systems. Are or will there be a patch for them or are they not involved in > this problem? > > I am new to patching systems, so forgive me any stupid questions. We have some > 6.1 and 6.3 systems. Are or will there be patches fro them or are they not > involved in this problem? > > How do i apply such a patch? With freebsd-update? As far as i know is this > tool only for systems >= 6.3 or? >Patches are patches for the source code, so you'll have to apply them with the patch(1) program and then re-compile. I'd be greatly surprised if the affected code looked different in 6.x. The bug itself is fairly interesting actually, if only for the reason that it displays what can happen if you don't check return values - other prime example of this causing security issues that I can think of off the top of my head are Windows impersonation bugs. stealth wrote this up: http://xorl.wordpress.com/2009/12/01/freebsd-ld_preload-security-bypass/ Maybe that sheds some light. Cheers, Jan
On Tue, 1 Dec 2009, Dan Lukes wrote:> Dag-Erling Sm?rgrav napsal/wrote, On 12/01/09 14:12: >> As to the second: yes, 6.1 is most likely affected. > > Probably no. > > The older algorithm used in 6.1 looks like > ----------------- > if (trusted) { > variable = getenv(NAME); > .... > ----------------- > > The affected algorithm looks like: > ----------------- > if (!trusted) { > unsetenv(NAME); > ... > }; > variable = getenv(NAME); > ----------------- > > As far as I know such change has been MFCed into 6.3, 6.4, 7.x but not > into 6.1. So 6.1 should not be affected by this bug (but remain > vulnerable to problem that triggered the change of old algorithm to > new).That is correct. 6.x should not be affected. The security issue exists with the combination of the getenv() to unsetenv() change in rtld.c and the addition of the new env code. The unsetenv() in 6.x would not stop if environ was corrupted. Sean -- scf@FreeBSD.org
http://twitter.com/spendergrsec/status/6223864530 http://xorl.wordpress.com/2009/12/01/freebsd-ld_preload-security-bypass/ On 12/1/09, Sean C. Farley <scf@freebsd.org> wrote:> On Tue, 1 Dec 2009, Dan Lukes wrote: > >> Dag-Erling Sm?rgrav napsal/wrote, On 12/01/09 14:12: >>> As to the second: yes, 6.1 is most likely affected. >> >> Probably no. >> >> The older algorithm used in 6.1 looks like >> ----------------- >> if (trusted) { >> variable = getenv(NAME); >> .... >> ----------------- >> >> The affected algorithm looks like: >> ----------------- >> if (!trusted) { >> unsetenv(NAME); >> ... >> }; >> variable = getenv(NAME); >> ----------------- >> >> As far as I know such change has been MFCed into 6.3, 6.4, 7.x but not >> into 6.1. So 6.1 should not be affected by this bug (but remain >> vulnerable to problem that triggered the change of old algorithm to >> new). > > That is correct. 6.x should not be affected. The security issue exists > with the combination of the getenv() to unsetenv() change in rtld.c and > the addition of the new env code. The unsetenv() in 6.x would not stop > if environ was corrupted. > > Sean > -- > scf@FreeBSD.org
>> I'd be greatly surprised if the affected code looked different in 6.x. >> > > There is No unsetenv in 6.2-RELEASE/src/libexec/rtld-elf/rtld. > There Is unsetenv in 6.[34]-RELEASE/src/libexec/rtld-elf/rtld. >Yeah, I already saw that (and am surprised :) ). My comment was just based on looking at my own 8.0-release, thought I had made that clear. Sorry if that mislead anyone.
On Dec 1, 2009, at 2:20 AM, FreeBSD Security Officer wrote:> A short time ago a "local root" exploit was posted to the full-disclosure > mailing list; as the name suggests, this allows a local user to execute > arbitrary code as root.Dr. Strangelove, or How I learned to love the MAC subsystem. # uname -a FreeBSD test 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri Nov 20 13:20:06 CET 2009 root@test:/usr/obj/usr/src/sys/TEST amd64 $ gcc -o program.o -c program.c -fPIC $ gcc -shared -Wl,-soname,w00t.so.1 -o w00t.so.1.0 program.o -nostartfiles $ ./env /libexec/ld-elf.so.1: environment corrupt; missing value for /libexec/ld-elf.so.1: environment corrupt; missing value for /libexec/ld-elf.so.1: environment corrupt; missing value for /libexec/ld-elf.so.1: environment corrupt; missing value for /libexec/ld-elf.so.1: environment corrupt; missing value for ALEX-ALEX # id uid=1001(user) gid=1001(user) euid=0(root) groups=1001(portero),0(wheel) # /usr/sbin/getpmac biba/high(low-high) And of course it's root. Now, $ setpmac biba/low\(low-low\) csh %pwd /tmp %./env /libexec/ld-elf.so.1: environment corrupt; missing value for /libexec/ld-elf.so.1: environment corrupt; missing value for /libexec/ld-elf.so.1: environment corrupt; missing value for /libexec/ld-elf.so.1: environment corrupt; missing value for /libexec/ld-elf.so.1: environment corrupt; missing value for ALEX-ALEX # ** OMG!! IT WORKED!!. BUT # touch /etc/testing_the_exploit touch: /etc/testing_the_exploit: Permission denied # ls -l /usr/sbin/getpmac -r-xr-xr-x 1 root wheel 7144 May 1 2009 /usr/sbin/getpmac # /usr/sbin/getpmac biba/low(low-low) OOHHHHH, we have a toothless root. Maybe a "riit"? Pity these serious security mechanisms don't get a widespread usage. Borja.