search

lkrg-org / lkrg

Linux Kernel Runtime Guard
https://lkrg.org
Other
404 stars 72 forks source link

Use KERN_EMERG in place of KERN_CRIT #222

Closed solardiz closed 1 year ago

solardiz commented 1 year ago

As mentioned in https://github.com/lkrg-org/lkrg/issues/208#issuecomment-1198354860, some distros appear to limit console messages to EMERG severity by default, which results in insufficient information on kernel panic screens from LKRG - only the panic itself is seen, but not the more detailed security alert(s) leading to it. Since we actually expect all of our alerts to go to the console, we can and should use the EMERG severity for them.

solardiz commented 1 year ago

Turns out this isn't a harmless change like I thought it was. On Ubuntu 20.04, got alert messages relayed via syslogd to all logged in users. Perhaps not what we intended! Might revert.

solardiz commented 1 year ago

The messages are relayed even to users SSH'ed in remotely, and here's what they look like:

Message from syslogd@hostname at Jul 30 15:35:47 ...
 kernel:[4778049.659020] LKRG: ALERT: DETECT: Task: uid corruption (expected 1000 vs. actual 0) for pid 181915, name exploit

There isn't literally a syslogd running. There is an rsyslogd. I guess it's the one sending those.

Also, I was able to inject a terminal escape sequence via the exploit's filename - it affected the terminal of the other logged in user accordingly. I think that's actually an rsyslogd vulnerability that it lets this through without filtering when deliberately outputting to ttys.

I'll revert the LKRG change, so that we use at most CRIT again, and we may want to separately sanitize the strings we print.

A related concern is what happens to the panic message, which is logged by the kernel itself as EMERG, but then maybe there's no time for userspace to relay it to users... or is there? A further related concern is what an exploit can do during the time after a kernel panic is initiated and until it fully takes effect - can it, for example, dump /etc/shadow to the attacker's terminal? If so, we might want to take additional steps before invoking panic().