[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