Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 71311 - sys-apps/fcron: Multiple vulnerabilities
Summary: sys-apps/fcron: Multiple vulnerabilities
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All All
: High normal (vote)
Assignee: Gentoo Security
Whiteboard: A3 [glsa] lewk
Depends on:
Reported: 2004-11-15 12:10 UTC by Luke Macken (RETIRED)
Modified: 2004-11-18 14:04 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Luke Macken (RETIRED) gentoo-dev 2004-11-15 12:10:08 UTC
Multiple Security Vulnerabilities in Fcron

iDEFENSE Security Advisory 11.15.04
November 15, 2004


Fcron is a periodical command scheduler which aims at replacing Vixie
Cron, and implements most of its functionalities. More information about
Fcron is available from


Multiple vulnerabilities have been found in Fcron.

**** ISSUE 1 - File contents disclosure ****

Local exploitation of a design error vulnerability in the fcronsighup 
component of Fcron may allow users to view the contents of root owned 

The vulnerability specifically exists within the set user id (setuid) 
root program fcronsighup. When the filename of a root owned file is 
passed as an argument to this program, it attempts to parse the file as 
a configuration file. Any lines in the file that are not parsable will 
be output as error messages. The following example demonstrates how an 
attacker can abuse this vulnerability to glean sensitive information 
from the /etc/shadow password file:

bash$ fcronsighup /etc/shadow
14:33:09 Unknown var name at line
root:<password-hash>:12475:0:99999:7::: : line ignored

**** ISSUE 2 - Configuration Bypass Vulnerability ****

Local exploitation of a design error vulnerability in the fcronsighup 
component of Fcron may allow users to bypass access restrictions.

The problem specifically exists in the checking performed by the
fcronsighup utility on the file passed as a configuration file. It
checks if the file is root owned, and not writable by any other users.

When a setuid process is run by an ordinary user the /proc filesystem
pseudofiles associated with it are owned by root and the contents of the

"cmdline" and "evironment" files are controllable by the user.

By pointing the fcronsighup configuration file to a /proc entry owned by

root, such as /proc/self/cmdline or /proc/self/environ, it is possible 
for a user to supply their own configuration settings.

**** ISSUE 3 - File Removal and Empty File Creation Vulnerability****

Local exploitation of a design error vulnerability in the fcronsighup 
component of Fcron may allow users to remove arbitrary files or create 
arbitrary empty files.

The vulnerability specifically exists in the fcronsighup utility which 
does signaling of the running fcron daemon. Fcronsighup creates a file 
named in part from a value read from configuration file. This file is 
created using open() with O_RDWR|O_CREAT and 0644 parameters while 
running with full root privileges. After some time has passed the file 
is removed. The filename string is generated by the following code:

snprintf(sigfile, sizeof(sigfile), "%s/fcrontab.sig", fcrontabs);

By padding the front of the filename with a large number of slash 
symbols ("/") it is possible to create or remove a file in an arbitrary 
location. For example: to create the file /tmp/owned, the configuration
option which sets the value for "fcrontabs" can be set to contain
(sizeof(sigfile)-strlen("/tmp/owned")) "/" characters, followed by the
string "/tmp/owned". The code will attempt to append the string
"/fcrontab.sig" to this string, but the limitation imposed on it by the
call to snprintf() will cause it to fail. When the filename is resolved,
the extra "/"s in the filename are ignored, resulting in an absolute
reference to the file /tmp/owned.

**** ISSUE 4 -  Information Disclosure Vulnerability ****

Local exploitation of a design error vulnerability in the fcrontab 
component of Fcron may allow users to view the contents of fcron.allow 
and fcron.deny.

The problem specifically exists because Fcron leaks the file descriptors

of the opened files /etc/fcron.allow and /etc/fcron.deny to the invoked 
editor. The default permissions on these files do not allow them to be 
read by unprivileged users:

-rw-r----- 1 root fcron 253 Jul 29 12:45 /etc/fcron.allow
-rw-r----- 1 root fcron 255 Jul 29 12:45 /etc/fcron.deny

An attacker can exploit this vulnerability by setting the EDITOR 
environment variable to a program which outputs the contents of the open

file descriptor; descriptor 3 to view the contents of fcron.allow and 
descriptor 4 to view the contents of fcron.deny.


Local users can bypass configuration settings, remove arbitrary files, 
create files with root permissions, read the contents of root owned 
files and send a SIGHUP to any process, potentially killing it. These 
actions may allow them to perform a denial of service or potentially 
elevate their privileges.


iDEFENSE has confirmed that Fcron versions 2.0.1 and 2.9.4 are
vulnerable. It is suspected that earlier versions are also affected.


Consider changing the permissions on the fcronsighup binary to only 
allow trusted users access. Make the binary only executable by users 
in the 'trusted' group by performing the following commands as root:

# chown root:trusted /usr/bin/fcronsighup
# chmod 4110 /usr/bin/fcronsighup

Also consider performing the same operation on the fcrontab binary to
prevent exploitation of Issue 4.


The following releases are available to address these vulnerabilities:

2.0.2 : stable branch (France)
   or (USA) : dev branch  (France)
   or (USA)


The Common Vulnerabilities and Exposures (CVE) project has assigned the
following names to these issues:

ISSUE 1 - File contents disclosure

ISSUE 2 - Configuration Bypass Vulnerability

ISSUE 3 - File Removal and Empty File Creation Vulnerability

ISSUE 4 -  Information Disclosure Vulnerability

These are candidates for inclusion in the CVE list
(, which standardizes names for security problems.


10/21/2004  Initial vendor notification
10/21/2004  Initial vendor response
11/15/2004  Coordinated public disclosure


Karol Wiesek is credited with discovering these vulnerabilities.

Get paid for vulnerability research


Copyright (c) 2004 iDEFENSE, Inc.

Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDEFENSE. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically, please
email for permission.

Disclaimer: The information in the advisory is believed to be accurate
at the time of publishing based on currently available information. Use
of the information constitutes acceptance for use in an AS IS condition.
There are no warranties with regard to this information. Neither the
author nor the publisher accepts any liability for any direct, indirect,
or consequential loss or damage arising from use of, or reliance on,
this information.
Comment 1 Luke Macken (RETIRED) gentoo-dev 2004-11-15 12:14:52 UTC
cron herd,

Please bump stable branch to 2.0.2.  The dev branch has also been bumped to to fix this issue.

Comment 2 Aaron Walker (RETIRED) gentoo-dev 2004-11-15 16:56:39 UTC
I was going to do these bumps before going to work, but looks like one of the patches doesn't apply cleanly, so I'll have to take a look at it while at work tonight, and will bump these first thing in the morning.
Comment 3 Aaron Walker (RETIRED) gentoo-dev 2004-11-16 02:45:43 UTC
2.0.2 and are in CVS. 2.0.2 marked stable on x86.

Could the CC'd archs please mark 2.0.2 stable?

The following versions are vulnerable and will be removed as soon as all archs mark 2.0.2 stable: 2.0.0-r4, 2.0.1, 2.9.4, and 2.9.5.
Comment 4 Simon Stelling (RETIRED) gentoo-dev 2004-11-16 03:40:21 UTC
the check for a valid EDITOR doesn't work:

 * Attempting to deduce absolute path of

!!! ERROR: sys-apps/fcron-2.0.2 failed.
!!! Function pkg_setup, Line 30, Exitcode 0
!!! Please set the EDITOR env variable to the path of a valid executable.
!!! If you need support, post the topmost build error, NOT this status message.

blubb@aqua ~/gentoo/gentoo-x86/sys-apps/fcron $ echo $EDITOR

of course /usr/bin/vim is executable
Comment 5 Jochen Maes (RETIRED) gentoo-dev 2004-11-16 04:58:28 UTC
both stable on ppc
Comment 6 Gustavo Zacarias (RETIRED) gentoo-dev 2004-11-16 05:25:25 UTC
sparc stable.
Comment 7 Aaron Walker (RETIRED) gentoo-dev 2004-11-16 06:17:54 UTC
blubb, are you sure there's nothing wrong on your end?  I must've built fcron a couple dozen times last night with various EDITOR settings, and it always worked as expected.  I've talked to both the sparc and ppc devs that tested it, and they didn't have any problems.

I'm trying to figure out how [[ "${EDITOR}" != */* ]] could ever fail if EDITOR="/usr/bin/vim".  That's the only way it would ever get to the rest of pkg_setup.
Comment 8 Simon Stelling (RETIRED) gentoo-dev 2004-11-16 08:09:29 UTC
if i emerge it as root, it works :) seems like the problem is my sudo-entry for emerge. stable on amd64
Comment 9 Hardave Riar (RETIRED) gentoo-dev 2004-11-16 16:52:19 UTC
Stable on mips.
Comment 10 Matthias Geerdsen (RETIRED) gentoo-dev 2004-11-17 00:38:54 UTC
It might be a good idea to get verification for the possible impact (elevation of privileges, DoS) as described in the Analysis section of the advisory.
Does issue 2 allow one to file cronjobs which will be run as root for example?

cron team, can you comment?
Comment 11 Matthias Geerdsen (RETIRED) gentoo-dev 2004-11-17 00:46:50 UTC

OSVDB: #11834..11837
Debian Bug:
Comment 12 Thierry Carrez (RETIRED) gentoo-dev 2004-11-17 02:24:04 UTC
Looking at it I see no obvious way of elevating privs. Looks like Local/Normal (A3) to me.
Comment 13 Aaron Walker (RETIRED) gentoo-dev 2004-11-17 06:07:25 UTC
2.0.2 is stable on hppa and vulnerable versions have been removed.

Mathias, I agree with Koon wrt to root escalation.  Doesn't look very probable, but of course anything is possible.  As far as DoS and the other stuff mentioned in the Analysis section, I'd say most certainly.
Comment 14 Luke Macken (RETIRED) gentoo-dev 2004-11-18 14:04:58 UTC
GLSA 200411-27