[17686] in bugtraq

home help back first fref pref prev next nref lref last post

Re: vixie cron...

daemon@ATHENA.MIT.EDU (Szilveszter Adam)
Fri Nov 17 13:53:58 2000

Mail-Followup-To: Szilveszter Adam <sziszi@petra.hos.u-szeged.hu>,
                  BUGTRAQ@SECURITYFOCUS.COM
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <20001117111438.C29176@petra.hos.u-szeged.hu>
Date:         Fri, 17 Nov 2000 11:14:38 +0100
Reply-To: Szilveszter Adam <sziszi@PETRA.HOS.U-SZEGED.HU>
From: Szilveszter Adam <sziszi@PETRA.HOS.U-SZEGED.HU>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To:  <Pine.LNX.4.21.0011170517470.13016-200000@nimue.tpi.pl>; from
              lcamtuf@TPI.PL on Fri, Nov 17, 2000 at 05:41:32AM +0100

On Fri, Nov 17, 2000 at 05:41:32AM +0100, Michal Zalewski wrote:
>
> Attached shell-script exploits fopen() + preserved umask vulnerability in
> Paul Vixie's cron code. It will work on systems where /var/spool/cron is
> user-readable (eg. 0755) - AFAIR Debian does so. RedHat (at least 6.1 and
> previous) have mode 0700 on /var/spool/cron, and thus it isn't exploitable
> in its default configuration... (ahmm, but this does NOT mean it is a
> problem of o+rx bits, but of insecure umask() and fopen() calls).
>
> I have no information about other distributions or systems - this exploit
> should automagically detect if you are vulnerable or not (checking
> /var/spool/cron, looking for Paul Vixie's crontab, etc). Please report
> your findings to me and/or to BUGTRAQ.

Hello everybody!

Upon testing and inspection of the CVS repository, I have found that FreeBSD
2.1.x, 2.2.x, 3.x, 4.x and -CURRENT are not vulnerable to this exploit if it
is launched by normal users, since the /var/cron directory is 0750 by
default. Members of the wheel group may still launch it successfully,
though. If this is a big risk in itself can be debated.

Note1: The script will not work by default on FreeBSD, because here /bin/sh
is *not* bash, bash is not even installed by default. Directory location is
also different. This in itself does not mean much though:-)

Note2: I do not speak for the FreeBSD Security Officer, but just wanted to
let you know fast.

--
Regards:

Szilveszter ADAM
Szeged University
Szeged Hungary

home help back first fref pref prev next nref lref last post