linux-kernel - Re: printk()s of user-supplied strings

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 22 Aug 2006 22:34:36 +0200
From:	Willy Tarreau <w@....eu>
To:	Ernie Petrides <petrides@...hat.com>
Cc:	Solar Designer <solar@...nwall.com>, linux-kernel@...r.kernel.org,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: printk()s of user-supplied strings

Hi Ernie,

On Tue, Aug 22, 2006 at 04:23:17PM -0400, Ernie Petrides wrote:
> On Tuesday, 22-Aug-2006 at 7:7 +0400, Solar Designer wrote:
> 
> > On Mon, Aug 21, 2006 at 07:36:01PM -0400, Ernie Petrides wrote:
> > > -			printk(KERN_ERR "Unable to load interpreter %.128s\n",
> > > -				elf_interpreter);
> >
> > I'd rather have this message rate-limited, not dropped completely.
> 
> I consider any printk() that can be arbitrarily triggered by an
> unprivileged user to be inappropriate, rate-limited or not.  I
> recommend that it be removed entirely.

Well, we had the same problem with the setuid() call where I proposed a
printk(), and Alan proposed to ratelimit it to prevent local user from
using it to flush the logs for instance, which I found clearly appropriate,
reason why I've backported 2.6's printk_ratelimit() function, citing the
two other printk() in binfmt_elf as good candidates.

> > Another long-time concern that I had is that we've got some printk()s
> > of user-supplied string data.  What about embedded linefeeds - can this
> > be used to produce fake kernel messages with arbitrary log level (syslog
> > priority)?  It certainly seems so.
> >
> > Also, there are terminal controls...
> 
> These are valid concerns.  Allowing the kernel to print user-fabricated
> strings is a terrible idea.

I agree. While this printk might have been there for years now, I really
think that it should be fixed for sensible chars, but then restored and
ratelimited to inform the admin that something abnormal is going on.

2.4.33.2 is out with the SCTP fix and this patch now, but with the printk
commented out.

Cheers,
Willy

-
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/