lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 09 Jan 2012 06:54:19 -0500 (EST)
From:	Ramon de C Valle <rcvalle@...hat.com>
To:	linux-kernel@...r.kernel.org
Subject: [PATCH] New PT_GNU_COMPAT segment header extension

Hi,

These patches introduces the PT_GNU_COMPAT segment header to indicate the
kernel whether an ELF binary or a shared library needs to have all readable
virtual memory mappings also executable (i.e. READ_IMPLIES_EXEC personality)
and if necessary, it allows more compatibility modes to be implemented in
the future.

Currently, an binary that needs only executable stack have unnecessarily all
readable virtual memory mappings also executable. This is because the kernel
does not know if the PF_X flag set in the PT_GNU_STACK segment header of the
binary indicates it needs only stack executable or all readable virtual
memory mappings also executable. Consequently, the kernel sets the
READ_IMPLIES_EXEC personality upon loading any binary with the PT_GNU_STACK
segment header and the PF_X flag set.

Furthermore, if the PT_GNU_STACK segment header with the PT_X flag is set in
any of the shared libraries a binary is linked, the kernel does not know if
the PF_X flag set in the PT_GNU_STACK segment header of the shared library
indicates it needs only stack executable or all readable virtual memory
mappings also executable either. Consequently, GCC sets the PT_GNU_STACK
segment header with the PF_X flag set upon compiling any binary linked to a
shared library with the PT_GNU_STACK segment header and the PF_X flag set.

This can result in applications unnoticeably having not only the stack, but
also all readable virtual memory mappings also executable. These patches
returns the original meaning and purpose of the PT_GNU_STACK segment header.

>From the security standpoint, these binaries will rely upon lesser security
extensions, such as heap consistency checking and others. Thus, improving
the security of binaries that needs only the stack executable.

These patches does not affect the current binaries that have the
PT_GNU_STACK segment header, neither legacy binaries that most likely does
not have this segment header either. For the existing binaries that
necessarily need to have all readable virtual memory mappings also
executable, the PT_GNU_STACK segment header can be easily converted to a
PT_GNU_COMPAT segment header without recompilation.

The following are important details about the changes made to the linker:

 * The PT_GNU_STACK and PT_GNU_COMPAT segment headers are mutually
   exclusive.
 * The PT_GNU_STACK segment header has precedence over the PT_GNU_COMPAT
   segment header.
 * The PT_GNU_COMPAT segment header IS NOT created by default.
 * The PT_GNU_STACK segment header IS ALWAYS created by default--which is
   the original behaviour of the linker.

These patches are completely non-intrusive. Over the time, once this
compatibility mode is no longer needed, they can be removed with no
subsequent effect.


-- 
Ramon de C Valle / Red Hat Security Response Team

View attachment "binutils-2.22-elf-compat-pt-gnu-compat.patch" of type "text/x-patch" (6368 bytes)

View attachment "linux-3.2-elf-compat-pt-gnu-compat.patch" of type "text/x-patch" (3404 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ