[spender@grsecurity.net: [grsec] grsecurity 2.1.9 released for 2.4.32/2.4.33-rc2/2.6.17.7]

Jaime Buffery nestu at espresso.foo-projects.org
Thu Jul 27 12:51:11 UTC 2006


:]

----- Forwarded message from Brad Spengler <spender at grsecurity.net> -----

grsecurity 2.1.9 has been released for the 2.4.32, 2.4.33-rc2, and 
2.6.17.7 series of Linux kernels. Changes in this release include:

    * A new PaX feature that eliminates a class of kernel 
      vulnerabilities from being exploitable. On a normal x86 Linux 
      system, users are allowed to map at virtual address 0x00000000. 
      This is legitimate behavior and necessary for certain applications 
      like dosemu to run. The problem is that if a null pointer 
      dereference bug exists in the kernel, an attacker can in many 
      cases cause the kernel to silently use its trojaned data in 
      userland instead of crashing the kernel; this can possibly result 
      in privilege escalation, contrary to the popular myth that all 
      null-ptr dereference bugs are DoS-only. The PaX feature prevents 
      exploitation in the case of null pointer dereferences as well as 
      in the case of any invalid userland pointer dereferences. This 
      feature is also useful for debugging purposes, since it will catch 
      any driver that uses userland memory directly and not through the 
      proper copy_(to/from)_user channels. This feature is highly 
      recommended, though it should not be enabled in kernels meant to 
      run inside virtual machines (unless your processor supports 
      virtualization extensions).
    * A new PaX feature that zeroes out physical memory pages as soon as 
      they are freed. Though an encrypted swap helps reduce the chance 
      of certain sensitive information being recovered, it does 
      nothing against short-term recovery of sensitive information 
      which may be properly locked into physical memory. The sensitive 
      information can be found by reading /dev/mem and /dev/kmem (if you 
      haven't protected those with grsecurity), or through arbitrary 
      read bugs in the kernel. Enabling this feature incurs a small 
      performance hit (3% measured on kernel compilation). In the 
      future, it will be integrated into the RBAC, so that it can be 
      toggled on a per-process basis, reducing the overall performance hit.
    * The long-time unmounting failure on reboot bug (caused by certain 
      /proc assumptions by killall5) has been resolved.
    * An RBAC bug reported on the forums related to automatic policy 
      regeneration has been resolved.
    * A rare deadlock condition in the IP tagging code has been 
      resolved.
    * Resource logging has become a sysctl-tunable feature.
    * Disabling support for module loading at runtime through the 
      grsecurity feature no longer prevents writes to other 
      grsecurity-related sysctl entries.
    * Additional minor grsecurity/gradm bugfixes


Please note that the 2.4.33-rc2 kernel is currently being recommended 
instead of the 2.4.32 kernel, since it includes a number of fixes for 
reported security bugs. The 2.6 patch has changed the way it adds -grsec 
to the kernel's extraversion, so it should apply cleanly to most 
2.6.17.x kernel releases. We however continue to discourage the 2.6 
series of kernels for production use for reasons that should by now be 
obvious to everyone.

On another note, my employer is sending me to Blackhat/Defcon this year, 
so I hope to get a chance to meet some of you there.

Enjoy,
-Brad



_______________________________________________
grsecurity mailing list
grsecurity at grsecurity.net
http://grsecurity.net/cgi-bin/mailman/listinfo/grsecurity


----- End forwarded message -----


More information about the Lunar-dev mailing list