[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5j+nyRM+4JbPwtnWpdO9mKTL15FTn0c0+8xK-kr0hJpgag@mail.gmail.com>
Date: Mon, 27 Jan 2014 15:56:51 -0800
From: Kees Cook <keescook@...omium.org>
To: Ryan Mallon <rmallon@...il.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Jiri Kosina <jkosina@...e.cz>, Joe Perches <joe@...ches.com>,
Al Viro <viro@...iv.linux.org.uk>,
Olof Johansson <olof@...om.net>,
Stepan Moskovchenko <stepanm@...eaurora.org>,
Daniel Borkmann <dborkman@...hat.com>
Subject: Re: [PATCH] vsprintf: BUG on %n
On Mon, Jan 27, 2014 at 3:11 PM, Ryan Mallon <rmallon@...il.com> wrote:
> On 28/01/14 10:03, Kees Cook wrote:
>> Now that there has been a full release of the kernel, and all users
>> of %n have been dropped, switch to %n use triggering a BUG. Ignoring
>> arguments could be used to assist in information leaks if an arbitrary
>> format string was under the control of an attacker.
>
> Not sure I follow the reasoning. %n no longer does anything in the
> kernel, so there is no risk if it does manage to find its way into a
> printed string. BUG() is for unrecoverable errors, which this clearly isn't.
>
> Information leaks via injectable strings are still possible if an
> attacker can insert %x, %d, etc. %n is more problematic since it allows
> for code injection, which is why it got removed. %n is not however,
> required to get an infoleak via a format string, so I think the summary
> is also a bit misleading.
Yeah, I'm a bit uncomfortable with the BUG() too. The issue with %n is
that it would produce no output at all to skip arguments. With other
things, you have to take up output space, which may be limited. How
about just not skipping the argument? Leave the warn_on, etc?
-Kees
--
Kees Cook
Chrome OS Security
--
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