User without read permission on cron.allow can execute crontab

[Brandon Mintern]

/etc/cron.allow is meant to list the users who are allowed to execute crontab. For a user who is not listed, the output should be:

$ crontab -e
You (ubuntu) are not allowed to use this program (crontab)
See crontab(1) for more information

When /etc/cron.allow is not readable by that user, though, it's treated as though the file doesn't exist at all:

$ sudo chmod o-r /etc/cron.allow
$ crontab -e
<opens the crontab editor; on exit: >
crontab: installing new crontab

The obvious workaround is to ensure that /etc/cron.allow is world readable, but unfortunately there are a lot of security tools and documentation out there that explicitly require both using cron.allow and also setting the permission on cron-related files to 600. Examples include https://secscan.acron.pl/ubuntu1604/5/1/8 and the CIS Level 1 benchmark for Ubuntu.

The result of this bug is that a sysadmin attempting to lock down cron by following standard security guidance will fail to do so.

[Seth Arnold (seth-arnold)]

Hello Brandon, thanks for the report. It'll take us a little while to figure out the ideal behavior.

Thanks

[Seth Arnold (seth-arnold)]

Hello Brandon,

I wasn't able to use an untrusted user account to induce this behaviour. So, I'm making this bug public so that more people can be made aware of the misconfiguration that is being encouraged.

It's unfortunate that the providers of this advice never actually tested it themselves.

It's unfortunate that the cron manpages don't detail proper permissions for these files.

It's unfortunate that crontab(1) doesn't perform this access control check while it has root privileges.

It's perhaps most especially unfortunate that this check isn't actually performed by cron(8) at all -- a user listed in /etc/cron.deny isn't actually denied running cron jobs, but is denied managing cron jobs. Existing configurations would keep working. (Probably this is not news to most sysadmins but I'd long since forgotten this detail.)

So now, the question is what remediation do we take?

- adjusting cron(8) feels like a good idea but would take a fair chunk of effort to not be silly about the implementation. It might also break configurations using the 'gatekeeping' feature of crontab(1).

- adjusting crontab(1). I'm not sure how much work this would take but feels like a good approach.

- fixing the manpages to describe the correct permissions. This feels like a good idea regardless of changes we may make to crontab(1).

Thanks

[Launchpad Janitor (janitor)]

This bug was fixed in the package cron - 3.0pl1-133ubuntu1

---------------
cron (3.0pl1-133ubuntu1) eoan; urgency=low

  * Merge from Debian unstable. Remaining changes:
    - debian/control:
      + Move MTA to Suggests field.
    - d/cron.default: change to a deprecated message to make it clear
      that the file is no longer in use.
  * Dropped changes, no longer needed:
    - Drop upstart system jobs; transition completed as of 18.04.
    - Handle /etc/init.d/cron symlink→ real file transition; completed as of
      18.04.

cron (3.0pl1-133) unstable; urgency=medium

  * SECURITY: Fix bypass of /etc/cron.{allow,deny} on failure to open
    If these files exist, then they must be readable by the user executing
    crontab(1). Users will now be denied by default if they aren't.
    (LP: #1813833)
  * SECURITY: Fix for possible DoS by use-after-free
    A user reported a use-after-free condition in the cron daemon, leading to a
    possible Denial-of-Service scenario by crashing the daemon.
    (Closes: #809167)
  * SECURITY: DoS: Fix unchecked return of calloc()
    Florian Weimer discovered that a missing check for the return value of
    calloc() could crash the daemon, which could be triggered by a very
    large crontab created by a user.
  * Enforce maximum crontab line count of 1000 to prevent a malicious user
    from creating an excessivly large crontab. The daemon will log a warning
    for existing files, and crontab(1) will refuse to create new ones.
  * Add d/NEWS altering to the new 1000 lines limit.
  * Move /var/run/crond.reboot to /run/crond.reboot.
  * crontab.5: Reverse the info on tilde expansion. When setting PATH, most
    shells will not expand a tilde. Thanks, Tim Landscheidt, for the analysis.
    (Closes: #801328)
  * Fixes for numerous man page issues. Remove trailing whitespace, use proper
    escapes, etc. Thanks, Bjarni Ingi Gislason! (Closes: #893575, #893579)
  * crontab.1: Drop duplicate DIAGNOSTICS header.
  * daemon: Only support the 'x' debug option in debug builds.

cron (3.0pl1-132) unstable; urgency=medium

  [ Christian Kastner ]
  * postinst: Properly test for regular file
    cron.postinst checked for a regular file by parsing the stat output,
    instead of simply relying on test(1)
  * Mark package cron as Multi-Arch: foreign (Closes: #878363)

  [ Stéphane Blondon ]
  * Add forgotten '\n' to a line in the crontab header (Closes: #898119)

cron (3.0pl1-131) unstable; urgency=medium

  [ Boyuan Yang ]
  * debian/control:
    - Merge duplicated build-dependency entry for debhelper
    - Update Vcs-* fields and use git repo under Salsa Debian group
      (Closes: #913484)
    - Add dependency to sensible-utils (Closes: #913483)
  * debian/rules: Do not explicitly invoke dpkg-architecture for architecture
    variables. Instead we are now using /usr/share/dpkg/architecture.mk to
    provide them

  [ Bjarni Ingi Gislason ]
  * crontab.1: Some format fixes in the manual. (Closes: #893576)

  [ Christian Kastner ]
  * d/control:
    - Switch Build-Depends from debhelper to debhelper-compat
    - Add Rules-Requires-Root: no
      We don't need (fake)root for building the package
    - Drop ancient dpkg...