[391] in linux-security and linux-alert archive
Re: cron 3.0pl1-20: URGENT SECURITY FIX
daemon@ATHENA.MIT.EDU (Ian Jackson)
Mon Sep 25 12:28:16 1995
Date: Mon, 25 Sep 95 03:08 BST
From: Ian Jackson <iwj10@cus.cam.ac.uk>
To: Aleph One <aleph1@dfw.net>, linux-security@tarsier.cv.nrao.edu
Aleph One <aleph1@dfw.net> writes (in email to me, which I hope he
won't mind me quoting):
> Ian I been looking into this to make an ALERT and send it out on the
> linux-alert and linux-security lists. Yet for all my tests under
> slackware and debian all I can see is that the fact that initgroups is
> not being called is that certain software may not work because all of it
> groups are not loaded. Could you explain why you belive this is a
> security problem? Running id and groups from a non-root crontab showed no
> strange groups or ids.
Most crons run with a supplementary groups list that contains one
entry, for the group `0'. If this is not reset then the users can
access files which are readable/writeable by group `0' even if they
are not members of the group (and make things setgid to `0' or
whatever).
Aleph One writes ("cron 3.0pl1-20: URGENT SECURITY FIX (fwd)"):
> Anyone know anything more?
> - ---------- Forwarded message ----------
> Date: Thu, 21 Sep 95 01:58 BST
> From: Ian Jackson <iwj10@cus.cam.ac.uk>
> To: Debian package announcements <debian-changes@pixar.com>
> Subject: cron 3.0pl1-20: URGENT SECURITY FIX
It would have been a good idea to read some of the other traffic I
sent to the Debian lists about this, or to mail me asking for
information, rather than asking linux-security.
[Mod: I posted Aleph's message to linux-security mainly because he was
forwarding your announcement, which was the first word we'd heard in
this form regarding the issue. The question that he was asking ("Anyone
know anything more?") was really secondary... --Jeff.]
do_command.c in Vixie-Cron 3.0pl1 contains the code:
# if defined(BSD)
initgroups(env_get("LOGNAME", e->envp), e->gid);
# endif
If compiled naively this will omit the initgroups call under Linux,
and so users will not have their cron jobs' supplementary groups set
correctly.
As noted above, this can allow users access to group `0' when they
should not be allowed it. (On my system, for example, this would get
them root access quite easily.)
The message you quoted was my announcement to debian-changes of the
fixed Debian binary and source packages. Both of those are available
from ftp.debian.org and its mirror sites, in
binary/admin/cron-3.0pl1-20.deb and source/admin/cron-3.0pl1-20.tar.gz
respectively. -19.deb and -19.tar.gz are the old, broken versions.
All Debian users should upgrade immediately in the standard way (type
`dpkg --install cron-3.0pl1-20.deb').
I don't know whether Slackware's cron is vulnerable. Debian's cron is
probably unsuitable for use on Slackware because of different
conventions about uid-numbering; also, Slackware's cron probably has a
slightly different layout for the cron jobs (Debian is frequently
more FSSTND-compliant than Slackware).
Ian.
