From owner-freebsd-security@FreeBSD.ORG  Fri Apr 22 11:52:03 2005
Return-Path: <owner-freebsd-security@FreeBSD.ORG>
Delivered-To: freebsd-security@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id CDE2516A4CE
	for <freebsd-security@freebsd.org>;
	Fri, 22 Apr 2005 11:52:03 +0000 (GMT)
Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.27])
	by mx1.FreeBSD.org (Postfix) with ESMTP id EE1C943D41
	for <freebsd-security@freebsd.org>;
	Fri, 22 Apr 2005 11:52:02 +0000 (GMT)
	(envelope-from keramida@freebsd.org)
Received: from orion.daedalusnetworks.priv (aris.bedc.ondsl.gr
	[62.103.39.226])j3MBopZm016357;	Fri, 22 Apr 2005 14:50:51 +0300
Received: from orion.daedalusnetworks.priv (orion [127.0.0.1])
	j3MBq01R062659;	Fri, 22 Apr 2005 14:52:00 +0300 (EEST)
	(envelope-from keramida@freebsd.org)
Received: (from keramida@localhost)j3MBq0t6062652;
	Fri, 22 Apr 2005 14:52:00 +0300 (EEST)
	(envelope-from keramida@freebsd.org)
Date: Fri, 22 Apr 2005 14:52:00 +0300
From: Giorgos Keramidas <keramida@freebsd.org>
To: Jesper Wallin <jesper@www.hackunite.net>
Message-ID: <20050422115200.GA58483@orion.daedalusnetworks.priv>
References: <42686A29.7090900@hackunite.net>
	<810a540e05042120493eb79da0@mail.gmail.com> <42687BDD.6000008@hackunite.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <42687BDD.6000008@hackunite.net>
X-Mailman-Approved-At: Fri, 22 Apr 2005 13:45:39 +0000
cc: freebsd-security@freebsd.org
cc: Pat Maddox <pergesu@gmail.com>
Subject: Re: Information disclosure?
X-BeenThere: freebsd-security@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Security issues [members-only posting]
	<freebsd-security.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-security>,
	<mailto:freebsd-security-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-security>
List-Post: <mailto:freebsd-security@freebsd.org>
List-Help: <mailto:freebsd-security-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-security>,
	<mailto:freebsd-security-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Apr 2005 11:52:03 -0000

On 2005-04-22 06:21, Jesper Wallin <jesper@www.hackunite.net> wrote:
>Pat Maddox wrote:
>>On 4/21/05, Jesper Wallin <jesper@hackunite.net> wrote:
>>>Hello,
>>>For some reason, I thought little about the "clear" command today..
>>>Let's say a privileged user (root) logs on, edit a sensitive file
>>>(e.g, a file containing a password, running vipw, etc) .. then runs
>>>clear and logout. Then anyone can press the scroll-lock command,
>>>scroll back up and read the sensitive information.. Isn't "clear"
>>>ment to clear the backbuffer instead of printing a full screen of
>>>returns? If it does, I'm not sure how that would effect a user
>>>running "clear" on a pty (telnet, sshd, screen, etc) ..
>>
>>No, it's not meant to clear the buffer.  If you need to clear the
>>buffer, just cat a really, really long file.
>
> Heh, that sounds more like a ugly hack than a solution if you ask me.

Who has physical access to your consoles and why?

Putting "deliberate paranoia" aside for a while, you can always _force_
the syscons buffer to be cleared by toggling between a couple of
different video modes:

	# vidcontrol 80x30 ; vidcontrol 80x25 ; clear ; logout