Re: Vulnerability in the Linux Audit Framework Auditd

[Steve Grubb <sgrubb () redhat 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 () secuinfra com
>
> www.secuinfra.com
>
>
>
> Follow us on XING.