5710885 2000-11-10 15:37 +0100 /87 rader/ Michal Zalewski <lcamtuf@TPI.PL>
Importerad: 2000-11-10 20:02 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: lcamtuf@TPI.PL
Mottagare: Bugtraq (import) <13685>
Ärende: numerous free/paid account systems are vulnerable to
------------------------------------------------------------
privledgeselevation attacks
From: Michal Zalewski <lcamtuf@TPI.PL>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <Pine.LNX.4.21.0011101321440.21368-100000@nimue.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. <=-----=
(5710885) --------------------------------(Ombruten)
Kommentar i text 5711281 av Bernhard Rosenkraenzer <bero@REDHAT.DE>
5711281 2000-11-10 19:45 +0100 /45 rader/ Bernhard Rosenkraenzer <bero@REDHAT.DE>
Importerad: 2000-11-10 22:27 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: bero@REDHAT.DE
Mottagare: Bugtraq (import) <13692>
Kommentar till text 5710885 av Michal Zalewski <lcamtuf@TPI.PL>
Ärende: Re: numerous free/paid account systems are vulnerable to
------------------------------------------------------------
privledgeselevation attacks From: Bernhard Rosenkraenzer
<bero@REDHAT.DE> To: BUGTRAQ@SECURITYFOCUS.COM Message-ID:
<Pine.LNX.4.21.0011101942120.14596-100000@bochum.redhat.de>
On Fri, 10 Nov 2000, Michal Zalewski wrote:
> 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.
If the standard system tools are used in the scripts mentioned in the
description, Red Hat Linux is not vulnerable because it checks for
this behavior.
[root@bero /root]# adduser kmem adduser: group kmem exists - if you
want to add this user to that group, use -g.
Here's the patch to (linux) shadow-utils we're using:
--- shadow-19990827/src/useradd.c.group Wed Jan 19 17:40:48 2000
+++ shadow-19990827/src/useradd.c Wed Jan 19 17:42:04 2000
@@ -1929,6 +1929,19 @@
}
/*
+ * Don't blindly add a user to a group that already exists...
+ * If you already have a group username, and want to add the user
+ * to that group, use useradd -g username username.
+ * --bero
+ */
+ if (! (nflg || gflg)) {
+ if (getgrnam(user_name)) {
+ fprintf(stderr, _("%s: group %s exists - if you want to add this user to that group, use -g.\n"), Prog, user_name);
+ exit(E_NAME_IN_USE);
+ }
+ }
+
+ /*
* Do the hard stuff - open the files, create the user entries,
* create the home directory, then close and update the files.
*/
(5711281) --------------------------------(Ombruten)
5716418 2000-11-11 00:23 +0100 /35 rader/ Michal Zalewski <lcamtuf@DIONE.IDS.PL>
Importerad: 2000-11-12 19:35 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: lcamtuf@DIONE.IDS.PL
Mottagare: Bugtraq (import) <13700>
Kommentar till text 5716301 av Alexander Schreiber <alexander.schreiber@INFORMATIK.TU-CHEMNITZ.DE>
Ärende: Re: numerous free/paid account systems are vulnerable to
------------------------------------------------------------
privledgeselevation attacks
From: Michal Zalewski <lcamtuf@DIONE.IDS.PL>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <Pine.LNX.4.21.0011110014570.30343-100000@dione.ids.pl>
On Sat, 11 Nov 2000, Alexander Schreiber wrote:
> Debian 2.2 (potato) default install checks for this:
Mkey. During futher investigations I've found recent RH releases (6.2
and 7.0) seems to be not affected by this problem. But, as numerous
systems are still based on older releases, and there were no security
advisories on this silently fixed problem, shadow-utils might be
still used in previous versions. I am, in fact, still using the old
package, and haven't checked for the updates (sorry). This does not
change the fact numerous systems are vulnerable.
- Debian 2.2 - not vulnerable
- RedHat below 6.2 - vulnerable
- RedHat 6.2, 7.0 - not vulnerable
- Cobalt Linux - vulnerable
- other distros? I would suspect Corel Linux, SuSE, Mandrake...
- OpenBSD - seems to be vulnerable, no details
Yes, recent installations might be not vulnerable. Distros with
RH-alike shadow-utils configuration and without the patch mentioned
here by Bernhard Rosenkraenzer, are vulnerable. Other systems, like
OpenBSD, might allow such attacks.
_______________________________________________________
Michal Zalewski [lcamtuf@tpi.pl] [tp.internet/security]
[http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};:
=-----=> God is real, unless declared integer. <=-----=
(5716418) --------------------------------(Ombruten)
5720500 2000-11-12 20:53 -0600 /35 rader/ Jeff Bachtel <sebastion@IRELANDMAIL.COM>
Importerad: 2000-11-13 18:00 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: sebastion@IRELANDMAIL.COM
Mottagare: Bugtraq (import) <13720>
Kommentar till text 5710885 av Michal Zalewski <lcamtuf@TPI.PL>
Ärende: Re: numerous free/paid account systems are vulnerable to
------------------------------------------------------------
privledges elevation attacks
From: Jeff Bachtel <sebastion@IRELANDMAIL.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20001112205306.U5027@cepheid.nu>
> 1) specific Unix system have to allow the attacker to create his account
> automatically (usually via www - both in paid and free ISP
> installations),
Starting off with this, I know of no distribution (of OpenBSD, of
RedHat, of Debian etc.) that has any sort of automatic account
generation built in. This is a function of the application software
used to create the user, and therefore this advisory should be
specifically targeted at applications broken in this regard.
Additionally, the useradd tool on OpenBSD is not vulnerable, if the
proper syntax is used.
For automatic account creation, the command that should be used to
create a user and the group to go with it (according to manpage for
useradd) would be:
useradd -g=uid kmem
To add a user kmem (again, assuming the auto generation application is
dumb enough to accept something like that).
The user kmem will be created, and assigned to a gid equal to his uid,
however no line will be added to /etc/groups, because a group of that
name already exists.
Improper use of useradd is, again, a function of the web account
interface, and is beyond the scope of a general unix vulnerability.
jeff
(5720500) ------------------------------------------
5720745 2000-11-12 23:12 +0100 /44 rader/ =?ISO-8859-2?Q?Tomasz_K=B3oczko?= <kloczek@RUDY.MIF.PG.GDA.PL>
Importerad: 2000-11-13 18:35 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: kloczek@RUDY.MIF.PG.GDA.PL
Mottagare: Bugtraq (import) <13725>
Kommentar till text 5716418 av Michal Zalewski <lcamtuf@DIONE.IDS.PL>
Ärende: Re: numerous free/paid account systems are vulnerable to
------------------------------------------------------------
privledgeselevation attacks From: =?ISO-8859-2?Q?Tomasz_K=B3oczko?=
<kloczek@RUDY.MIF.PG.GDA.PL> To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID:
<Pine.LNX.4.21.0011122254270.32206-100000@rudy.mif.pg.gda.pl>
On Sat, 11 Nov 2000, Michal Zalewski wrote:
> On Sat, 11 Nov 2000, Alexander Schreiber wrote:
>
> > Debian 2.2 (potato) default install checks for this:
>
> Mkey. During futher investigations I've found recent RH releases (6.2 and
> 7.0) seems to be not affected by this problem. But, as numerous systems
> are still based on older releases, and there were no security advisories
> on this silently fixed problem, shadow-utils might be still used in
> previous versions.
Short info about shadow package because few weeks ago maintainer was
changed:
- latest shadow package is 20001016,
- main ftp site for shadow is ftp://ftp.pld.org.pl/software/shadow/,
- cvs repository is on cvs.pld.org.pl:
:pserver:cvs@cvs.pld.org.pl:/cvsroot shadow module (with empty password)
- browseable cvsweb interface is on:
http://cvsweb.pld.org.pl/index.cgi/shadow/ or
http://cvs.pld.org.pl/shadow/
If anyone have some remarks to maintainer please mail me.
kloczek
--
-----------------------------------------------------------
*Ludzie nie maj± problemów, tylko sobie sami je stwarzaj±*
-----------------------------------------------------------
Tomasz K³oczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*
--
Please respect the privacy of this mailing list.
To UNSUBSCRIBE, email to debian-private-request@lists.debian.org with
a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org
(5720745) --------------------------------(Ombruten)
5721036 2000-11-13 10:44 +0100 /22 rader/ Michal Zalewski <lcamtuf@DIONE.IDS.PL>
Sänt av: joel@lysator.liu.se
Importerad: 2000-11-13 19:14 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: lcamtuf@DIONE.IDS.PL
Mottagare: Bugtraq (import) <13726>
Kommentar till text 5720500 av Jeff Bachtel <sebastion@IRELANDMAIL.COM>
Ärende: Re: numerous free/paid account systems are vulnerable to
------------------------------------------------------------
privledges elevation attacks
From: Michal Zalewski <lcamtuf@DIONE.IDS.PL>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <Pine.LNX.4.21.0011131039280.31869-100000@dione.ids.pl>
On Sun, 12 Nov 2000, Jeff Bachtel wrote:
> Starting off with this, I know of no distribution (of OpenBSD, of
> RedHat, of Debian etc.) that has any sort of automatic account
> generation built in.
That's why I am not saying this vulnerability is a problem of
specific distribution, but of a numerous account creation utils -
this problem seems to be generic, you could use any search engine to
locate dozens of adduser.cgi, adduser.pl amd similar scripts invoking
system utilities.
_______________________________________________________
Michal Zalewski [lcamtuf@tpi.pl] [tp.internet/security]
[http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};:
=-----=> God is real, unless declared integer. <=-----=
(5721036) --------------------------------(Ombruten)