linux-kernel - Re: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

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]

Message-ID: <20130821155632.GO17845@n2100.arm.linux.org.uk>
Date:	Wed, 21 Aug 2013 16:56:32 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Dave Jones <davej@...hat.com>
Cc:	Aaro Koskinen <aaro.koskinen@....fi>,
	ksummit-2013-discuss@...ts.linuxfoundation.org,
	Kees Cook <keescook@...omium.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit
	mitigations

On Wed, Aug 21, 2013 at 11:43:55AM -0400, Dave Jones wrote:
> On Wed, Aug 21, 2013 at 04:26:14PM +0100, Russell King - ARM Linux wrote:
>  > I've been running several iterations of it for a while (== up to 10 minutes
>  > run time - which is normally about how long it takes to find the rather-too-
>  > exposed kmalloc in sys_oabi_epoll_wait) and so far have seen no sign of any
>  > page table corruption.
> 
> awesome. Guess it was a google specific issue then.
> (Or something that got fixed post 3.4)

It's been running on this run for 38 minutes so far (having put a
__GFP_NOWARN stopper in that kmalloc - which I think there needs to be
a better solution.)

What I have noticed is during the initialisation of the fd[] array, it
sometimes hangs on a futex.  Killing trinity, removing all the files
and restarting it seems to sort the problem out.  I'm not sure what's
doing that - any ideas?  I couldn't find any evidence of another trinity
thread doing anything with futexes.

>  > Were there any nonstandard platform
>  > specific devices in /dev which that user could access - such as graphics
>  > or video decoder devices which could be exposing big holes?
> 
> I'm not sure what google patched into that kernel altogether, so who knows..

Unfortunately, it seems to be rather common if there's hardware GPU or
video codecs to expose physical addresses to userspace which get passed
around in closed source libraries and ultimately to GPU/video hardware.
I would not be surprised if trinity was finding that and finding some
way to get something to poke randomly in kernel memory.

It seems also that the normal approach is to expose the device nodes in
/dev to the world, effectively handing any userspace program the ability
to:

(a) a way to allocate from a pool of memory, and get its physical address
(b) to be able to pass a physical address to hardware for DMA type operations
(c) to initiate DMA on that hardware

This is why closed source GPU/video stuff is Bad News(tm) for security.
I'd strongly suggest keeping such platforms well away from any data
anyone cares about keeping private and keeping them well isolated. :)
--
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/