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.