From mitsuru@zebu.riken.go.jp  Fri Feb 23 23:25:40 2001
Return-Path: <mitsuru@zebu.riken.go.jp>
Received: from zebu.riken.go.jp (zebu.riken.go.jp [134.160.20.73])
	by hub.freebsd.org (Postfix) with SMTP id 30B4B37B4EC
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 23 Feb 2001 23:25:40 -0800 (PST)
	(envelope-from mitsuru@zebu.riken.go.jp)
Received: (qmail 75002 invoked by uid 123); 24 Feb 2001 07:25:56 -0000
Message-Id: <20010224072556.75001.qmail@zebu.riken.go.jp>
Date: 24 Feb 2001 07:25:56 -0000
From: mitsuru@riken.go.jp
Reply-To: mitsuru@riken.go.jp
To: FreeBSD-gnats-submit@freebsd.org
Subject: dmesg -a
X-Send-Pr-Version: 3.2

>Number:         25337
>Category:       bin
>Synopsis:       dmesg -a should be restricted
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    rwatson
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Fri Feb 23 23:30:01 PST 2001
>Closed-Date:    Sun May 02 15:23:55 PDT 2004
>Last-Modified:  Sun May 02 15:23:55 PDT 2004
>Originator:     Mitsuru Yoshida
>Release:        FreeBSD 4.2-STABLE i386
>Organization:
RIKEN
>Environment:

        FreeBSD 4.2-STABLE i386

>Description:

        Using dmesg -a, any user can get all data in the message buffer, 
        and it may cause security problem. Especially all messages written to 
        the console are stored in the message buffer during single user mode, 
        and any user can get them later. The use of -a option should be 
        restricted to root user.

>How-To-Repeat:

	dmesg -a

>Fix:

--- dmesg.c.dist	Wed Feb 21 10:00:26 2001
+++ dmesg.c	Wed Feb 21 10:02:11 2001
@@ -56,6 +56,7 @@
 #include <unistd.h>
 #include <vis.h>
 #include <sys/syslog.h>
+#include <sys/types.h>
 
 struct nlist nl[] = {
 #define	X_MSGBUF	0
@@ -87,6 +88,10 @@
 	while ((ch = getopt(argc, argv, "aM:N:")) != -1)
 		switch(ch) {
 		case 'a':
+			if (getuid() != (uid_t)0) {
+			  fprintf(stderr,"dmesg: must be root to get all data in the message buffer\n");
+			  exit(1);
+			}
 			all++;
 			break;
 		case 'M':
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: ru 
State-Changed-When: Sat Feb 24 02:17:11 PST 2001 
State-Changed-Why:  
Fixed in 5.0-CURRENT, sbin/dmesg/dmesg.c,v 1.13. 


Responsible-Changed-From-To: freebsd-bugs->ru 
Responsible-Changed-By: ru 
Responsible-Changed-When: Sat Feb 24 02:17:11 PST 2001 
Responsible-Changed-Why:  
MFC reminder. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=25337 

From: Thomas Moestl <tmoestl@gmx.net>
To: freebsd-gnats-submit@FreeBSD.org
Cc: mitsuru@riken.go.jp
Subject: Re: bin/25337: dmesg -a should be restricted
Date: Sat, 24 Feb 2001 18:11:19 +0100

 > switch(ch) {
 > case 'a':
 >        if (getuid() != (uid_t)0) {
 >                fprintf(stderr,"dmesg: must be root to get all data in the message buffer\n");
 >                exit(1);
 >        }
 This fix is not sufficient, I'm afraid; first, the whole message buffer
 is exported as sysctl (on i386); second, dmesg classifies the lines by
 the first characters (lines starting with <number> and number != 0 are 
 only printed when -a is given). Because the kernel message buffer is
 a ring buffer, the first characters of a line may be overwritten, causing
 the rest of the line to be printed by a simple dmesg (without -a).
 
 	- thomas
 
State-Changed-From-To: feedback->open 
State-Changed-By: ru 
State-Changed-When: Mon Feb 26 00:10:16 PST 2001 
State-Changed-Why:  
The suggested fix does not work: 

On Sat, Feb 24, 2001 at 01:49:57PM -0500, Robert Watson wrote: 
> 
> Please back out this change.  The syslog hack was fairly bogus *before* 
> this change, but now it's gone from being bogus to being a vulnerability. 
> This is because the heuristic used to differentiate syslog messages and 
> console messages is not always correct, as (a) this prevents dmesg from 
> showing strings the kernel prints that are in the format of syslog 
> messages, and (b) wrap-around in the dmesg buffer in kernel can result in 
> messages being displayed when the syslog string prefix is squished.  So 
> you've turned what was an innocent hack into a security problem, since 
> you now make a security guarantee about the availability of the messages. 
> 
> We're also about to commit changes to dmesg to make it no longer require 
> privilege when used on a live system by virtue of the existing sysctl (on 
> i386) currently exporting the message buffer, so this piece of "security" 
> doesn't even prevent users from getting to the data, as they can currently 
> extract it directly using sysctl and don't have to use the dmesg command. 
> 
> We're currently considering adding two new sysctl's that could be used to 
> restrict creation and access to msgbuf data.  First, a sysctl that toggles 
> whether or not console output is sent to the message buffer.  Second, a 
> sysctl that toggles whether or not dmesg output is available in jail(). 


Responsible-Changed-From-To: ru->rwatson 
Responsible-Changed-By: ru 
Responsible-Changed-When: Mon Feb 26 00:10:16 PST 2001 
Responsible-Changed-Why:  
Robert objected this change and proposed the right fix. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=25337 
State-Changed-From-To: open->suspended 
State-Changed-By: rwatson 
State-Changed-When: Mon Mar 18 11:08:37 PST 2002 
State-Changed-Why:  
Doing this requires us to seperate the different msgbuf contents, requiring 
a larger rewriting of the console and message buffer code.  Doing so would 
fix a number of bugs, including the "overflow" bug involving the msgbuf 
ringbuffer problem. However, that's a lot of work.  In the mean time, 
it's possible to restrict access to the entire message buffer by setting 
the security.bsd.unprivileged_read_msgbuf sysctl to 1 on 5.0-CURRENT. 
This will prevent unprivileged users from using the msgbuf-retrieval 
sysctl, although they will still be able to read the boot-time cached 
data in /var/run/dmesg.boot.  I'm putting this PR into suspend mode 
to remind me every now and then I should rewrite all this stuff. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=25337 
State-Changed-From-To: suspended->closed 
State-Changed-By: rwatson 
State-Changed-When: Sun May 2 15:22:19 PDT 2004 
State-Changed-Why:  
Close this PR; a security toggle was provided to help limit the 
problem, but the fundamental issue of combining kernel message 
buffers for kernel printfs vs console output will be harder to 
address.  Since my work queue has grown too deep, I'll close this 
PR as addressed, but I will open a feature request PR to have the 
two buffers separated. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=25337 
>Unformatted:
