[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <34243612.Gid3QHG1hd@wuerfel>
Date: Wed, 20 Jul 2016 13:12:20 +0200
From: Arnd Bergmann <arnd@...db.de>
To: Michael Ellerman <mpe@...erman.id.au>
Cc: Russell King - ARM Linux <linux@...linux.org.uk>,
Balbir Singh <bsingharora@...il.com>,
Stewart Smith <stewart@...ux.vnet.ibm.com>, bhe@...hat.com,
kexec@...ts.infradead.org, dyoung@...hat.com,
Petr Tesarik <ptesarik@...e.cz>, linux-kernel@...r.kernel.org,
AKASHI Takahiro <takahiro.akashi@...aro.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Thiago Jung Bauermann <bauerman@...ux.vnet.ibm.com>,
linuxppc-dev@...ts.ozlabs.org, Vivek Goyal <vgoyal@...hat.com>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC 0/3] extend kexec_file_load system call
On Wednesday, July 20, 2016 8:47:45 PM CEST Michael Ellerman wrote:
> At least for stdout-path, I can't really see how that would significantly help
> an attacker, but I'm all ears if anyone has ideas.
That's actually an easy one that came up before: If an attacker controls
a tty device (e.g. network console) that can be used to enter a debugger
(kdb, kgdb, xmon, ...), enabling that to be the console device
gives you a direct attack vector. The same thing will happen if you
have a piece of software that intentially gives extra rights to the
owner of the console device by treating it as "physical presence".
Arnd
Powered by blists - more mailing lists