[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20141027120115.GB18586@amd>
Date: Mon, 27 Oct 2014 13:01:15 +0100
From: Pavel Machek <pavel@....cz>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Kees Cook <keescook@...omium.org>,
Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>, Rik van Riel <riel@...hat.com>,
David Rientjes <rientjes@...gle.com>,
Aaron Tomlin <atomlin@...hat.com>,
Dario Faggioli <raistlin@...ux.it>,
Andi Kleen <ak@...ux.intel.com>,
Peter Zijlstra <peterz@...radead.org>,
Jens Axboe <axboe@...com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Paul Wise <pabs3@...edaddy.net>
Subject: Re: [PATCH] sysctl: terminate strings also on \r
On Mon 2014-10-27 11:11:53, Geert Uytterhoeven wrote:
> On Mon, Oct 27, 2014 at 10:56 AM, Pavel Machek <pavel@....cz> wrote:
> > On Wed 2014-10-22 16:43:10, Kees Cook wrote:
> >> On Wed, Oct 22, 2014 at 4:26 PM, Andrew Morton
> >> <akpm@...ux-foundation.org> wrote:
> >> > On Tue, 21 Oct 2014 13:21:37 -0700 Kees Cook <keescook@...omium.org> wrote:
> >> >
> >> >> From: Paul Wise <pabs3@...edaddy.net>
> >> >>
> >> >> This partially mitigates a common strategy used by attackers for hiding
> >> >> the full contents of strings in procfs from naive sysadmins who use cat,
> >> >> more or sysctl to inspect the contents of strings in procfs.
> >> >>
> >> >> ...
> >> >>
> >> >> --- a/kernel/sysctl.c
> >> >> +++ b/kernel/sysctl.c
> >> >> @@ -1739,7 +1739,7 @@ static int _proc_do_string(char *data, int maxlen, int write,
> >> >> while ((p - buffer) < *lenp && len < maxlen - 1) {
> >> >> if (get_user(c, p++))
> >> >> return -EFAULT;
> >> >> - if (c == 0 || c == '\n')
> >> >> + if (c == 0 || c == '\n' || c == '\r')
> >> >> break;
> >> >> data[len++] = c;
> >> >> }
> >> >
> >> > There are no valid uses of \r in a procfs write?
> >>
> >> I struggle to imagine one; everything I found that uses proc_dostring
> >> seems to be names, paths, and commands.
> >
> > Well, filename can contain \r, right?
>
> Even \n. AFAIK, the only thing a filename cannot contain is the nul character
> and a forward slash, as that's used to separate path components (so slash
> is valid for a path name).
>
> Still, we can hide stuff using ANSI ESC sequences, and e.g. backspaces,
> right?
Right :-(. So this patch makes no sense, it would have to forbid any
character < 32 to be effective.
And more sfun is... with ESCape sequences, you can actually cause
stuff to be forced as an input on poor admin's terminal. cat could be
"fixed", but pretty much all the command line tools could be abused to
do this... I see no reasonable way forward.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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