Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 18 Feb 2021 15:52:54 +0000
From: Felix Kosterhon <felix.kosterhon@...uinfra.com>
To: Steve Grubb <sgrubb@...hat.com>, "oss-security@...ts.openwall.com"
	<oss-security@...ts.openwall.com>
Subject: Re: Vulnerability in the Linux Audit Framework Auditd

Hello Mr. Grubb,
 
thank you for your insight.
First and foremost we would like to clarify that our intent is not to put blame on anyone but to improve the level of security for the affected systems and the organisations utilising Auditd.
According to the rules.conf manual page, file-watch rules are meant to monitor any accesses to files based on their permission level.
For the syscalls mentioned in this report this is not the case.
 
RedHat Inc. shares our perspective on this issue and has assigned a CVE for the vulnerability. Additionally they informed us that they will work together with the Upstream Linux Kernel Developers on behalf of fixing this issue.
 
Furthermore we were asked by RedHat Inc. to share our findings via this mailing list.
 
Kind regards,
 
Felix Kosterhon
Cyber Defense Analyst
SECUINFRA GmbH, Germany

Am 18.02.21, 15:32 schrieb "Steve Grubb" <sgrubb@...hat.com>:

    Hello,

    I normally do not comment on security announcements, but this needs some 
    fixing...

    On Thursday, February 18, 2021 5:15:20 AM EST Felix Kosterhon wrote:
    > my name is Felix Kosterhon and i am Cyber Defense Analyst at SECUINFRA
    > GmbH, Germany.
    > 
    > We discovered a security vulnerability in the Linux Audit Framework
    > (Auditd).

    Before people start asking for an updated audit package, auditd is not 
    responsible for this. The Linux Kernel is where any issue might lie. Blaming 
    auditd  is like saying syslog has a security problem because a login was not 
    recorded.

    > During our research we discovered that the usage of a certain
    > open-syscall (open_by_handle_at) is not covered by the current file watch
    > implementation of Auditd.

    Where to begin? name_to_handle_at/open_by_handle_at work together. 
    name_to_handle_at is the syscall that would have the path name and returns a 
    handle. open_by_handle_at() takes the handle and makes a descriptor. That 
    means open_by_handle_at() has no idea what the path might be. All it has is 
    numbers. So, if there was going to be a watch placed, it would be more 
    meaningful on name_to_handle_at(). Anyone concerned can place a syscall audit 
    rule on name_to_handle_at() like this:

    -a always,exit -F arch=b32 -S name_to_handle_at  -F auid>=1000 -F auid!=unset
    -a always,exit -F arch=b64 -S name_to_handle_at -F auid>=1000 -F auid!=unset

    But then...what might use this? All the references I can find seem to 
    associate this syscall with NFS. And if that is the case, the audit system 
    doesn't really support remote file systems. Sometimes it does. But that is 
    more likely accidental than anything planned.

    But this does not stop anyone with admin privileges from using the syscall 
    pair locally.

    -Steve

    > This allows a local attacker with elevated
    > privileges (CAP_DAC_READ_SEARCH capability) to read and modify files
    > without being noticed by the implemented Auditd file watches.
    >
    > We disclosed our finding to RedHat, Inc. in November and it will be
    > published today, Feb 18, under CVE-2020-35501. As suggested by RedHat,
    > Inc., we want to inform you about this security flaw. If you have any
    > further questions, we are happy to help you.
    > 
    > We would also like to subscribe to your mailing list to stay informed about
    > current security topics.
    > 
    > Best Regards,
    > 
    > 
    > 
    > Felix Kosterhon
    > 
    > Cyber Defense Analyst
    > 
    > 
    > 
    > 
    > 
    > SECUINFRA GmbH
    > 
    > Münchener Straße 36
    > 
    > 60329 Frankfurt/Main
    > 
    > 
    > 
    > Mobile:  +49 151 18975666
    > 
    > 
    > 
    > felix.kosterhon@...uinfra.com
    > 
    > www.secuinfra.com
    > 
    > 
    > 
    > Follow us on XING.





Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.