[Outofthebox] The Times They Are A-Changin'

[Massimiliano Oldani]

Angelo Dell'Aera wrote:
> Non so perche' ma questi "pezzetti d'informazione" pescati a destra e a
> manca suscitano forte in me la sensazione che i tempi siano ormai
> cambiati e che ben presto scrivere exploit con un minimo di
> affidabilita' su Linux sara' cosa piuttosto ardua... 
> 
E' gia' da un bel po' che si suda freddo buffero:)
> 
> ---
> 
> Randomize the i386 vDSO
> 
> Move the i386 VDSO down into a vma and thus randomize it. Besides the
> security implications (attackers cannot use the predictable high-mapped
> VDSO page as syscall trampoline anymore) this feature also helps
> debuggers, and it's good for hypervisors (Xen, VMWare) too. There's a
> new CONFIG_COMPAT_VDSO option, which provides support for older glibcs
> that still rely on a prelinked high-mapped VDSO. Newer distributions
> (using glibc 2.3.3 or later) can turn this backwards-compatibility
> option off (recommended, for security reasons, as the features makes
> harder certain types of attacks). There is a new vdso=[0|1] boot option
> as well, and a runtime /proc/sys/vm/vdso_enabled sysctl switch, that
> allows the VDSO to be turned on/off
> 

Purtroppo su alcuni custom-kernel (vedi RH/Fedora) questa feature c'e'
gia' da un bel po', prima che la 'committassero' intorno al ~2.6.19 sul
vanilla.
Inoltre diciamo la verita', era un assurdita' la fixed-mapped VDSO;)
> 
> ---
> 
> 
> CONFIG_DEBUG_RODATA:
> 
> Mark the kernel read-only data as write-protected in the pagetables,
> in order to catch accidental (and incorrect) writes to such const
> data. This option may have a slight performance impact because a
> portion of the kernel code won't be covered by a 2MB TLB anymore. 
> 
> 
Questo pure rompe i coglioni a parecchi vector in molti scenari di
exploit a ksapce (da NULL def, etc..), purtroppo anche questo in realta'
non e' una novita'. Pipacs la implemento' quasi 3 anni fa in PaX KERN_EXEC.
Non usare PSE per abilitare questa 'sporca' pero' e' un esagerazione, la
 'slight' e' un po' piu' di 'slight', provare per credere :))

> ---
> 
> 
> From:  	 	Arjan van de Ven <arjan at linux.intel.com>
> To: 	 	        linux-kernel at vger.kernel.org
> 
> This patch series adds support for the gcc 4.1 -fstack-protector feature
> to the kernel. While gcc 4.1 supports this feature for userspace, the
> patches to support it for the kernel only got added to the gcc tree on
> 27/7/2006 (eg for 4.2); it is expected that several distributors will
> backport this patch to their 4.1 gcc versions.
> 
> -fstack-protector is a security feature in gcc that causes "selected"
> functions to store a special "canary" value at the start of the
> function, just below the return address. At the end of the function,
> just before using this return address with the "ret" instruction, this
> canary value is compared to the reference value again. If the value of
> the stack canary has changed, it is a sign that there has been some
> stack corruption (most likely due to a buffer overflow) that has
> compromised the integrity of the return address.
> 
> Standard, the "selected" functions are those that actually have stack
> buffers of at least 8 bytes, this selection is done to limit the
> overhead to only those functions with the highest risk potential. There
> is an override to enable this for all functions.
> 
> On first sight this would not be needed for the kernel, because the
> kernel is "perfect" and "has no buffer overflows on the stack". I
> thought that too for a long time, but the last year has shown a few
> cases where that would have been overly naive.
> 
> This feature has some performance overhead (but it's not that incredibly
> expensive either) so it should be a configuration option for those who
> want this extra security.
> 
> For those people who want to use the gcc 4.1 patch, it can be found at
> http://www.fenrus.org/stackprotector/gcc41.patch
> 
> 
> Saluti,
>

Le canary sul kernel non sono la soluzione, poiche' cmq sia la
maggiorparte dei bug che usciranno da qui a poco, e che sono usciti fino
ad ora sono quasi tutti errori logici (da lost-PTE, VMA overlap, CORE
overwrite etc.. ) e overflow sul kernel heap.
Inoltre anche qui l'overhead non e' banale.. si sta cercando di fare di
tutto per ottimizziare, e poi si piazzano tutti sti check in un
interrupt handler? .. insomma qui si sta un attimo esagerando.
Cmq vedremo dove andremo a finire..