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. <=-----=