[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2132838.iZASKD2KPV@x2>
Date: Thu, 18 Feb 2021 09:32:06 -0500
From: Steve Grubb <sgrubb@...hat.com>
To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
Cc: Felix Kosterhon <felix.kosterhon@...uinfra.com>
Subject: Re: Vulnerability in the Linux Audit Framework Auditd
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.
