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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 4 Oct 2006 01:40:08 -0400
From:	Kyle Moffett <mrmacman_g4@....com>
To:	Julio Auto <mindvortex@...il.com>
Cc:	Chase Venters <chase.venters@...entec.com>,
	goodfellas@...llcode.com.ar,
	Linux kernel <linux-kernel@...r.kernel.org>,
	endrazine <endrazine@...il.com>,
	Stephen Hemminger <shemminger@...l.org>,
	Valdis.Kletnieks@...edu, Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: Registration Weakness in Linux Kernel's Binary formats

On Oct 04, 2006, at 00:08:57, Julio Auto wrote:
> I sincerely think you're all missing the point here.

No, _you're_ missing the point.

> The observation is in fact something that can be used by rootkit  
> writers or developers of other forms of malware.

This attack relies on being able to load an arbitrary attacker- 
defined kernel module.  Full Stop.  If you can load code into  
privileged mode it's game over regardless of what other designs and  
restrictions are in place.  The "default" security model is that only  
root can load kernel code, but using SELinux or other methods it's  
possible to entirely prevent anything from being loaded after system  
boot or written to the kernel or bootloader images.

If the attacker gains kernel code access, it doesn't matter what  
"simply linked list" or whatever other garbage is being used, they  
can just overwrite the existing ELF loader with their shellcode if  
they want.  Or they could insert a filesystem patch which always  
loads a virus into any ELF binary at load.  Or they could just fork a  
kernel thread and run their shellcode there.  Or they could load a  
copy of Windows from the CD drive and boot into that from Linux.

Kernel-level access implies ultimate trust and security, and  
*nothing* is going to change that.

Cheers,
Kyle Moffett

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ