On Fri, Oct 19, 2001 at 04:47:13PM +0200, Martin Kacer wrote: > On Thu, 18 Oct 2001, Rafal Wojtczuk wrote: > > # In order for this flaw to be exploitable, /usr/bin/newgrp must be > # setuid root and world-executable. Additionally, newgrp, when run with no > # arguments, should not prompt for password. This These of course are the requirements of the particular exploit only. Many (but not all) distributions include other programs which may be suitable for exploiting the kernel vulnerability. And of course it is possible to install third-party SUID root programs which may be used. Thus, all distribution vendors should treat this issue seriously. We did. > # conditions are satisfied in case of most popular Linux distributions (but > # not Openwall GNU/*/Linux). > > Well, there is a little of inaccuracy in the first sentence. This is > a kernel flaw, NOT a bug in newgrp. Indeed, and I think Nergal has made this clear enough in the rest of his posting. > Other suid programs can be used instead... _Some_ other programs, yes. Quoting myself, "Vendors may wish to review their distributions for binaries which meet all of the following requirements: 1. SUID to root (yes, only to root, or there's no ptrace capability). 2. Are runnable by untrusted users. 3. Let a user execute a program of the user's choice via them (with privileges of the user, of course). 4. Either don't fork or do fork but do the exec in the parent process. newgrp(1) seems to be quite unique here. su(1) _may_ be suitable, too, but PAM'ified versions typically fork; it becomes important which of the two processes does the exec, so be sure to check. sudo is very likely suitable with some sudoers configurations. crontab(1) from Vixie Cron exec's editor in the child, but other implementations may be different." (from private discussions prior to the Bugtraq announcement). Now, thanks to the discussion with Martin Kacer, I can add that at least one PAM'ified version of su(1) is suitable for the attack: the one that is included in the shadow suite and used on Debian. I also add login(1) to the list as some distributions are apparently still installing it SUID root. There may be many other programs in this world which are suitable for the attack. I did review all of Owl for binaries which are (1) supplied with the distribution and (2) meet all of the requirements explained above in a supported configuration. newgrp is the only one, and it is not enabled by default. Of course that isn't an excuse and we don't use it as such. The official statement for Owl is in the changelog entry: 2001/10/18 kernel SECURITY FIX Severity: low to high, local, active A new revision of the Openwall Linux kernel patch, 2.2.19-ow3, is now available. It contains fixes for two Linux kernel vulnerabilities discovered by Rafal Wojtczuk <nergal at owl.openwall.com> and is strongly recommended for use with Owl. One of the vulnerabilities affected SUID/SGID execution by processes being traced with ptrace(2). It was possible to trick the kernel into recognizing an unsuspecting SUID root program as the (privileged) tracer process. Then, if that program would execute a program supplied by the malicious user (with the user's credentials), the user's program would inherit the ability to trace. Fortunately, there's no program that would meet all of the requirements for this attack in the default Owl install. However, certain supported non-default configurations of Owl are affected. In particular, if newgrp(1) is made available to untrusted users (which is a supported owl-control setting) or certain third-party software which contains SUID root binaries is installed, the vulnerability may become exploitable and result in a local root compromise. The other vulnerability allowed for an effective local DoS attack by causing the kernel to spend an almost arbitrary amount of time on dereferencing a single symlink, without giving a chance for processes to run. Note the possible "high" risk impact in the Severity field, referring to non-default configurations. > The main conclusion of my posting is: having other versions of newgrp > or ignoring LD_DEBUG is insufficient! Probably, ANY Linux distribution is > vulnerable without the kernel patches! Of course. The Linux kernel is vulnerable: the interfaces it provides don't always behave as they should, in a way which makes some legitimate uses insecure. This means that even if a distribution isn't exploitable in the default install, its other supported configurations probably are. This is why we handle this as a very important security fix. -- /sd
This archive was generated by hypermail 2b30 : Tue Oct 23 2001 - 07:33:02 PDT