CVE-2017-9525

2017-06-0900:00:00

ubuntu.com

6.9 Medium

CVSS2

Attack Vector

LOCAL

Attack Complexity

MEDIUM

Authentication

NONE

Confidentiality Impact

COMPLETE

Integrity Impact

COMPLETE

Availability Impact

COMPLETE

AV:L/AC:M/Au:N/C:C/I:C/A:C

6.7 Medium

CVSS3

Attack Vector

LOCAL

Attack Complexity

LOW

Privileges Required

HIGH

User Interaction

NONE

Scope

UNCHANGED

Confidentiality Impact

HIGH

Integrity Impact

HIGH

Availability Impact

HIGH

CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H

0.001 Low

EPSS

Percentile

26.8%

JSON

In the cron package through 3.0pl1-128 on Debian, and through
3.0pl1-128ubuntu2 on Ubuntu, the postinst maintainer script allows for
group-crontab-to-root privilege escalation via symlink attacks against
unsafe usage of the chown and chmod programs.

Bugs

<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864466>
<https://bugs.launchpad.net/ubuntu/+source/cron/+bug/1971895 (regression)>
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892720 (regression)>

Notes

Author	Note
jj	This appears to be mitigated by kernel symlink restrictions. The crontabs dir has the sticky bit set drwx-wx–T root crontab crontabs which means symlinks within the dir must have the same uid as the target. It is still possible that a cron package update could trigger this race.
seth-arnold	I believe that actually exploiting the bug requires updating the cron package. So long as there’s no updates for cron, the vulnerable code doesn’t run. So if we find a second bug in cron then we really should fix the race condition at the same time, but so long as we don’t push a cron update, the vulnerable code just plain doesn’t run. the patch just narrows the time window for the race condition.

Author

Note

This appears to be mitigated by kernel symlink restrictions. The crontabs dir has the sticky bit set drwx-wx–T root crontab crontabs which means symlinks within the dir must have the same uid as the target. It is still possible that a cron package update could trigger this race.

seth-arnold

I believe that actually exploiting the bug requires updating the cron package. So long as there’s no updates for cron, the vulnerable code doesn’t run. So if we find a second bug in cron then we really should fix the race condition at the same time, but so long as we don’t push a cron update, the vulnerable code just plain doesn’t run. the patch just narrows the time window for the race condition.

OSVersionArchitecturePackageVersionFilename
ubuntu18.04noarchcron< 3.0pl1-128.1ubuntu1.2UNKNOWN
ubuntu14.04noarchcron< anyUNKNOWN
ubuntu16.04noarchcron< 3.0pl1-128ubuntu2+esm2UNKNOWN