linux-kernel - Re: [BUG] perf: bogus correlation of kernel symbols

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 20 May 2011 08:54:53 -0400
From:	Dan Rosenberg <drosenberg@...curity.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	linux-kernel@...r.kernel.org, davej@...hat.com,
	kees.cook@...onical.com, davem@...emloft.net, eranian@...gle.com,
	torvalds@...ux-foundation.org, adobriyan@...il.com,
	penberg@...nel.org
Subject: Re: [BUG] perf: bogus correlation of kernel symbols

On Fri, 2011-05-20 at 14:07 +0200, Ingo Molnar wrote:
> * Dan Rosenberg <drosenberg@...curity.com> wrote:
> 
> > I was able to boot a relocatable kernel with the decompression location at a 
> > hard-coded offset without too much trouble.  Everything seems to work fine.
> 
> Nice!
> 
> > However, it occurred to me that even if the kernel image's base address were 
> > randomized at boot, assuming a binary distro kernel it would still be 
> > possible to sidt the address of the IDT and calculate symbol offsets relative 
> > to that.  Any thoughts on how to avoid that?  Seems difficult. Another hurdle 
> > will be to find a reasonable source of entropy that early in the boot 
> > process.
> 
> I do not think it's an issue.
> 
> If an attacker can execute arbitrary privileged instructions like SIDT then 
> it's game over. There's plenty of CPU state, the IDT, GDT, various MSRs that 
> would tell roughly where the kernel is, etc.
> 

Except that SIDT isn't a privilege instruction, it's accessible as ring
3.

> The attack randomization protects against is when the attacker has a limited 
> amount of control over a stack return address (due to a buffer overflow for 
> example) and can redirect kernel execution to some 'interesting' place that 
> allows more control. With SMEP and kernel image randomization this would be 
> rather difficult to pull off: the kernel wont jump to a pre-prepared user-space 
> shellcode buffer (due to SMEP) while the location of already existing, 
> executable, supervisor-privileged pages is randomized.
> 

Yes, all true, except are you specifically considering remote-only
attack vectors?

> So when you have implemented this i'd suggest enabling CONFIG_X86_PTDUMP=y to 
> get access to a dump of all pagetables, in the /debug/kernel_page_tables file. 
> There you can check every single executable, kernel-privileged mapping on a 
> live system and make sure it's not easily discovered.
> 

I'll do this too, but first I'd like to address the above.

Thanks,
Dan

> Thanks,
> 
> 	Ingo


--
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/