4

I'm asking myself if the function printk() causes security issues on Linux. When an attacker has user level access to the system, does it make his life easier if he has access to kernel pointers? Does the usage of printk() support him in any ways when searching for some privilege escalation vulnerabilities on the system?

It can be easily disabled through setting CONFIG_PRINTK=n as configuration flag of the Linux kernel. Should it be done on a highly secured system? How is it about embedded systems? (I know that the system will be very silent afterwards.) Does anybody has any recommendations or experiences about this?

6

I'm asking myself if the function printk() is a security issue on Linux.

This depends on whether or not there are any printk() calls which may print unsanitized pointers. Generally, pointers will be sanitized when kernel.kptr_restrict is non-zero. This works because the identifier for pointers is %pK, which sanitizes pointers by default. However, there seem to be a lot of situations in which mistakes result in accidental pointer leakage, for example because some value is calculated from a pointer and printed, or because a typo results in %pk being used instead, which does not go through the same sanitization process. This is not unique to this function and can even happen in virtual filesystems like proc and sysfs as well. These infoleaks are not rare.

When an attacker has user level access to the system, does it make his life easier if he has access to kernel pointers?

Well yes and no. The worst thing an attacker can do* with kernel pointers is discover the base offset of the kernel to break KASLR. Unfortunately, KASLR is already quite useless against local attackers, as has been shown time and time again (most often by Brad Spengler). It can be defeated either through infoleaks as mentioned above, or through a variety of timing attacks against most CPU architectures.

It can be easily disabled through setting CONFIG_PRINTK as configuration flag of the Linux kernel. Should it be done on a highly secured system?

No. There is a better option. Instead of disabling printing, make it a requirement to have high privileges to read the kernel log buffer. This can be done by setting kernel.dmesg_restrict to 1. This both protects from pointers that happen to not get sanitized and leak into the syslog from being available to attackers, as well as hiding other potentially sensitive information that might get printed there.

* This is only true for stock kernels. If you compile your own kernel, especially if using RANDSTRUCT, knowledge of pointers becomes necessary for an attacker since it can allow pinpointing the actual offset of sensitive kernel functions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.