linux-kernel - Re: Semantic Bug: Privilege Bypass in timerfd for 4.4.y

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <YIvslbdvfnwANjge@kroah.com>
Date:   Fri, 30 Apr 2021 13:40:05 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Kasper Zwijsen <Kasper.Zwijsen@...nt.be>
Cc:     "tglx@...utronix.de" <tglx@...utronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "security@...nel.org" <security@...nel.org>, stable@...r.kernel.org
Subject: Re: Semantic Bug: Privilege Bypass in timerfd for 4.4.y

On Fri, Apr 30, 2021 at 10:57:59AM +0000, Kasper Zwijsen wrote:
> Dear Thomas Gleixner,
> 
> 
> I believe I have found a semantic security bug in the form of a missing capability check in the timerfd_create and timerfd_settime system calls for the 4.4.y LTS kernel.
> 
> In this commit: https://github.com/torvalds/linux/commit/2895a5e5b3ae78d9923a91fce405d4a2f32c4309,
> capability checks for CAP_WAKE_ALARM were added for creating and setting a CLOCK_BOOTTIME_ALARM and CLOCK_REALTIME_ALARM.
> This security patch was applied to all but one LTS kernel, namely 4.4.y.

That is because it showed up in the 4.8 release, there was nothing to
"apply" to any newer kernels :)

> It is therefore still possible for a user process without any privileges to create and set such a timer, resulting in the process being able to wake up the system.
> 
> The man pages state that creating or setting such a timer requires privileges. Similarly, the timer_create system call does check the correct permissions.
> I therefore believe this is unintended and a semantic bug.
> I have tested the original patch and found that it can simply be applied to the latest 4.4.y kernel (4.4.268 as of right now) without any issues.
> The patch: https://lore.kernel.org/patchwork/patch/686888/


I've now queued this up for the next 4.4.y release.  In the future, you
should just email the stable@...r.kernel.org address any git commit ids
that you feel need to be backported.

thanks!

greg k-h