Red Hat Bugzilla – Bug 679262
[RFE] kernel: kptr_restrict for hiding kernel pointers from unprivileged users [rhel-6.2]
Last modified: 2016-01-20 03:09:47 EST
+++ This bug was initially created as a clone of Bug #679261 +++ Description of problem: Add the %pK printk format specifier and the /proc/sys/kernel/kptr_restrict sysctl. The %pK format specifier is designed to hide exposed kernel pointers, specifically via /proc interfaces. Exposing these pointers provides an easy target for kernel write vulnerabilities, since they reveal the locations of writable structures containing easily triggerable function pointers. The behavior of %pK depends on the kptr_restrict sysctl. If kptr_restrict is set to 0, no deviation from the standard %p behavior occurs. If kptr_restrict is set to 1, the default, if the current user (intended to be a reader via seq_printf(), etc.) does not have CAP_SYSLOG (currently in the LSM tree), kernel pointers using %pK are printed as 0's. If kptr_restrict is set to 2, kernel pointers using %pK are printed as 0's regardless of privileges. Replacing with 0's was chosen over the default "(null)", which cannot be parsed by userland %p, which expects "(nil)". Upstream commit: http://git.kernel.org/linus/455cd5ab305c90ffc422dd2e0fb634730942b257 Also backport: drm: do not leak kernel addresses via /proc/dri/*/vma http://git.kernel.org/linus/01e2f533a234dc62d16c0d3d4fb9d71cf1ce50c3 timer debug: Hide kernel addresses via %pK in /proc/timer_list http://git.kernel.org/linus/f590308536db432e4747f562b29e5858123938e9 [PATCH v2] use %pK for /proc/kallsyms and /proc/modules http://marc.info/?l=linux-kernel&m=129608894604282&w=2 (not upstream yet)
(In reply to comment #0) > [PATCH v2] use %pK for /proc/kallsyms and /proc/modules > http://marc.info/?l=linux-kernel&m=129608894604282&w=2 (not upstream yet) Now in mainline http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9f36e2c448007b54851e7e4fa48da97d1477a175
(In reply to comment #0) > If kptr_restrict is set to 0, no deviation from the standard %p behavior > occurs. If kptr_restrict is set to 1, the default, if the current user > (intended to be a reader via seq_printf(), etc.) does not have CAP_SYSLOG > (currently in the LSM tree), kernel pointers using %pK are printed as 0's. > > Upstream commit: > http://git.kernel.org/linus/455cd5ab305c90ffc422dd2e0fb634730942b257 > This patch requires the CAP_SYSLOG capability, added by mainline commit http://git.kernel.org/linus/ce6ada35bdf710d16582cc4869c26722547e6f11 options? 1. Replace CAP_SYSLOG with CAP_SYS_ADMIN 2. Add CAP_SYSLOG patch 3. reject BZ
(In reply to comment #2) > (In reply to comment #0) > > > If kptr_restrict is set to 0, no deviation from the standard %p behavior > > occurs. If kptr_restrict is set to 1, the default, if the current user > > (intended to be a reader via seq_printf(), etc.) does not have CAP_SYSLOG > > (currently in the LSM tree), kernel pointers using %pK are printed as 0's. > > > > Upstream commit: > > http://git.kernel.org/linus/455cd5ab305c90ffc422dd2e0fb634730942b257 > > > > This patch requires the CAP_SYSLOG capability, added by mainline commit > > http://git.kernel.org/linus/ce6ada35bdf710d16582cc4869c26722547e6f11 > > options? > > 1. Replace CAP_SYSLOG with CAP_SYS_ADMIN > 2. Add CAP_SYSLOG patch > 3. reject BZ Perhaps take option 1, and then mention about the CAP_SYSLOG patch in your patch submission for discussion.
Patch(es) available on kernel-2.6.32-150.el6
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: In Red Hat Enterprise Linux 6.2, due to security concerns, addresses in /proc/kallsyms and /proc/modules show all zeros when accessed by a non-root user.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2011-1530.html