numerous free/paid account systems are vulnerable to privledgeselevation attacks

[Michal Zalewski <lcamtuf () TPI PL>]

Brief description:
------------------

This problem is not related to any specific product or solution, but
affects pretty huge part of the ISP installations. The problem is a direct
effect of the default account creation policy launched by OpenBSD, RedHat,
and some other vendors, where every user has it's own, corresponding gid.
This policy is respected both by default system account creation
utilities, and numerous autonomous scripts / applications. I am repeating
- this is not a vulnerability of these systems itself. It is a generic
misconfiguration problem, which, in conjunction with mentioned policy, can
be harmful.

I've thought about such possibility yesterday, but I was almost sure this
vulnerability will be not present at all, or should be present rarely. But
it isn't. About 40% of the ISP installations based on the RedHat and
OpenBSD, and some of installations based on other distributions / systems
are vulnerable (small commercial ISP installations especially).

Background requirements:
------------------------

1) specific Unix system have to allow the attacker to create his account
   automatically (usually via www - both in paid and free ISP
   installations),

2) specific system must offer filesystem access; either intentionally, via
   telnet / ssh shell access, or accidentally - by abusing cgi scripts
   execution or httpd server-side code, abusing ftp access (by putting
   special files honored by MTA/MDA, IMAP server, etc),

3) every user must have separate uid AND gid, and user/group name should
   be user-dependent (eg. based on choosen login); account creation
   code will usually invoke system utilities, queue the request for futher
   processing (eg. from crontab) with system utilities. How portable.

Above requirements are met pretty common (except really huge virtual
installations, where all users are sharing one UID - but it might be
dangerous for other reasons). Next two things should be addressed as a
misconfiguration, but are present in 50% of the installations meeting
above background requirements:

4) /etc/group should contain groups that have no corresponding /etc/passwd
   entries - on Linux boxes, we have kmem (!), disk, tty, floppy, mem (!),
   wheel (!), utmp etc; on BSD, we have less or more similar set of
   groups.

5) at least one of above names should be not rejected by account system
   (oops! but common, apparently not everyone builds "banned words" list
   basing on /etc/group, but /etc/passwd and his own choices, instead),

The impact:
-----------

Because there's no such account in /etc/passwd, account like "kmem" or
"wheel" is assumed to be not present in system. As long as it is not
implictly mentioned as invalid account name (see #5), it will be created.
Both default system utilities (like adduser/useradd) and most of the
automated web scripts will create such account and append corresponding
group name to /etc/group. But if it is already present, it will be used
instead, and no new group will be appended. Ooops!

Obviously, that's bad. After successful shell login, ftp login without
chroot, abusing .procmail, .forward, .qmail or cgi scripts executed via
suexec, attacker will have privledges like:

uid=1832(floppy) gid=19(floppy) groups=19(floppy)
uid=1833(kmem) gid=9(kmem) groups=9(kmem)
uid 1834(wheel) gid=10(wheel) groups=10(wheel)

This, indirectly, allows user to gain higher privledges (eg. by reading
/dev/kmem or /dev/mem, being in wheel group, etc).

Thanks to: peltier, hege, funkysh, console and other #hax ppl for testing
and support.

_______________________________________________________
Michal Zalewski [lcamtuf () tpi pl] [tp.internet/security]
[http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};:
=-----=> God is real, unless declared integer. <=-----=