open_by_handle_at and CVE-2020-35501

From: Steve Grubb <sgrubb@redhat.com>
To: linux-audit@redhat.com
Subject: open_by_handle_at and CVE-2020-35501
Date: Thu, 25 Feb 2021 17:14:38 -0500	[thread overview]
Message-ID: <7230785.EvYhyI6sBW@x2> (raw)

Hello,

There was an announcement on the oss-security mail list a week ago:

https://seclists.org/oss-sec/2021/q1/155

regarding auditing of the open_by_handle_at system call. They are using a 
rule like this:

-a always,exit -F path=/path/to/file  -F perm=wr

and expecting that we have an audit record when opened using the 
name_to_handle_at/open_by_handle_at syscall pair. 

I run a study of my system by adding audit rules for each of the syscalls. 
What I found was that the name_to_handle_at seems to be used by systemd and 
it only passes a relative file name. This makes the audit event next to 
useless.

And interestingly I have no events for open_by_handle_at in spite of systemd 
preparing to use it. So, I don't have any idea what the audit event would 
look like.

In any event, they are asking what upstream audit is going to do about this? 
In looking into open_by_handle_at, I found that it was used in an exploit 
against docker some time ago where it was possible to bruteforce the handle. 
Of cource you need CAP_DAC_READ_SEARCH to call it.

https://www.programmersought.com/article/54607139735/

I think we should do something, not sure what. Simply adding the syscall to 
the open perms machinery will get an event, but probably nothing usable. You 
could at least see who is doing it and with what program.

In the meantime, people can use the syscall rules to audit for any occurance. 
I think the default rules do include it.

Cheers,
-Steve

--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit