[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110701125411.GA21551@albatros>
Date: Fri, 1 Jul 2011 16:54:11 +0400
From: Vasiliy Kulikov <segoon@...nwall.com>
To: kernel-hardening@...ts.openwall.com
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Andrew Morton <akpm@...ux-foundation.org>,
James Morris <jmorris@...ei.org>, Namhyung Kim <namhyung@...il.com>,
Greg Kroah-Hartman <gregkh@...e.de>, linux-kernel@...r.kernel.org
Subject: Re: Re: [PATCH v2] kernel: escape non-ASCII and
control characters in printk()
On Fri, Jul 01, 2011 at 14:00 +0200, Ingo Molnar wrote:
>
> * Linus Torvalds <torvalds@...ux-foundation.org> wrote:
>
> > On Mon, Jun 27, 2011 at 11:38 AM, Vasiliy Kulikov <segoon@...nwall.com> wrote:
> > >
> > > Sure, I don't propose it anymore (v2 goes without it).
> >
> > What point would you like to filter things at?
> >
> > I really think that user space should do its own filtering - nobody
> > does a plain 'cat' on dmesg. Or if they do, they really have
> > themselves to blame.
Some people do "dmesg | tail" or "grep -i err /var/log/messages". Or
even "tail -f /var/log/messages".
http://www.google.com/search?q=grep+var+log+messages
> > And afaik, we don't do any escape sequence handling at the console
> > level either, so you cannot mess up the console with control
> > characters.
> >
> > And the most dangerous character seems to be one that you don't
> > filter: the one we really do react to is '\n', and you could possibly
> > make confusing log messages by embedding a newline in your string and
> > then trying to make the rest look like something bad (say, an oops).
> >
> > So I'm not entirely convinced about this filtering at all.
>
> Yeah. It would be nice to see a demonstration of at least one 'bad
> thing' that is possible via the current code, before we protect
> against it.
>
> The claim the patch makes is rather specific:
>
> | There are numerous printk() instances with user supplied input as
> | "%s" data, and unprivileged user may craft log messages with
> | substrings containing control characters via these printk()s.
> | Control characters might fool root viewing the logs via tty, e.g.
> | using ^[1A to suppress the previous log line.
>
> So it ought to be demonstrable.
Read this mail again:
http://www.openwall.com/lists/kernel-hardening/2011/06/22/6
Using the instance of the bug in core dump code that Willy used here for
\n thing:
http://www.openwall.com/lists/kernel-hardening/2011/06/25/3
We get:
$ echo "main() { sprintf((char*)3, (char*)1); }" | gcc -xc -o ../1234 -
$ ln -s ../1234 $'\x1b[1Ainit\nfail'
Now generate an arbitrary log message:
$ ../1234
Ошибка сегментирования (core dumped)
$ dmesg | tail -n1
[16291.982492] 1234[21579]: segfault at 0 ip 00007f527186028a sp 00007fff08251dd8 error 4 in libc-2.11.1.so[7f52717d8000+17a000]
Change this log entry:
$ './^[[1Ainit
fail'
Ошибка сегментирования (core dumped)
$ dmesg | tail
...
[16291.982492] init[21579]: segfault at 0 ip 00007f527186028a sp 00007fff08251dd8 error 4 in libc-2.11.1.so[7f52717d8000+17a000]
[16379.001357] fail[21586]: segfault at 0 ip 00007f332831028a sp 00007fffc52de568 error 4 in libc-2.11.1.so[7f3328288000+17a000]
$
(see 1234 => init change)
As you see here, the previous log entry was showed not as it was
initally logged. Core dump message was chosen fully arbitrary, just to
show that some specific part of it can be "edited".
If this step-by-step instruction is not a proof, then I don't know what
the word "proof" means...
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
