From: Kalin KOZHUHAROV <kalin@ThinRope.net>
To: Koblinger Egmont <egmont@uhulinux.hu>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: information leak in vga console scrollback buffer
Date: Sun, 13 Jun 2004 11:48:52 +0900 [thread overview]
Message-ID: <40CBC094.6050901@ThinRope.net> (raw)
In-Reply-To: <Pine.LNX.4.58L0.0406122301250.25004@sziami.cs.bme.hu>
Koblinger Egmont wrote:
> On Sat, 12 Jun 2004, Chris Wedgwood wrote:
>
>
>>>Rationale? (At least an rtfm-like pointer to that?)
>>
>>Maybe I didn't full understand you. Generally I find it desirable to
>>be able to read things that scrolled off the screen a long time ago.
>>It's very useful for unattended machines if I need to 'look' back.
>
>
> Generally console's scrollback buffer disappears as soon as you switch to
> another console.
>
> It'd be a really nice idea if all the consoles had a configurable amount
> of scrollback buffer which is always remembered. IMHO with todays machines
> having a scrollback buffer of 1000 lines for 6 or a little bit more
> consoles (at most 63 IIRC) is affordable as well as the processor time
> needed to copy the data from/to vga/normal memory on each console switch
> and at every Nth Shift+PageUp (no matter what N is). But this is a whole
> different story.
>
> What I'm talking about is: normally after people switch away from a
> console they assume that the scrollback buffer is no longer available
> since this is the behavior they experience normally. E.g. Z does a 'cat
> my-long-private-file' and then logs out. Then even if getty clears the
> screen, one can press Shift+PageUp to go back and read parts of this file.
> Z is about to leave the computer but don't want others to be able to
> scroll back with Shift+PageUp. So switches console (Alt+Fx) and the
> scrollback buffer is gone. He is happy. But shouldn't be.
>
> With the trick I described it is possible to bring back some random parts
> of previous texts, often some garbage with stupid flashing characters, but
> maybe parts of Z's my-long-private-file. The behavior seems to be random
> to me, uncontrollable by the user (I see no way to force private data to
> be cleared from the vga buffer) and clearly not intentional.
>
> Please try what I wrote, I'm sure that you misunderstood me (I'm trying to
> write as clear as I can but I'm not native English speaker and not even
> good in English, so it might be that my bugreport is a little bit hard to
> understand). I'm sure not talking about a feature, nor am I a Linux newbie
> who has just seen Shift+PageUp a few days ago for the first time (even
> though I'm very far from being a kernel hacker ;-))
>
OK, I think I got what you are trying to point out.
To reproduce:
1. login to a (vga) console.
2. less /etc/services; press space t oscroll a few screens
3. logout
4. login again on the same console (possibly as a different user)
5. less /etc/resolv.conf
6. press UpArrow, then Shift+PgUp
What is expected:
screen should not scroll past your file.
What happens:
You can view the previous text (from /etc/services)!!!
So the point is that this buffer is persistend across logout/login, which is a security bug.
And I guess LKML is not the place for it, logout should clear the buffer IMHO.
BTW, using agetty here.
Kalin.
--
||///_ o *****************************
||//'_/> WWW: http://ThinRope.net/
|||\/<"
|||\\ '
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
next prev parent reply other threads:[~2004-06-13 2:49 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-12 20:01 information leak in vga console scrollback buffer Egmont Koblinger
2004-06-12 20:43 ` Chris Wedgwood
2004-06-12 20:54 ` Koblinger Egmont
2004-06-12 20:59 ` Chris Wedgwood
2004-06-12 21:22 ` Koblinger Egmont
2004-06-13 2:48 ` Kalin KOZHUHAROV [this message]
2004-06-13 3:47 ` David Lang
2004-06-13 4:08 ` Kalin KOZHUHAROV
2004-06-13 8:33 ` Koblinger Egmont
2004-06-13 10:52 ` Kalin KOZHUHAROV
2004-06-13 11:48 ` Koblinger Egmont
2004-06-22 15:32 ` Pavel Machek
2004-06-24 18:47 ` Chris Wedgwood
2004-06-24 21:41 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40CBC094.6050901@ThinRope.net \
--to=kalin@thinrope.net \
--cc=egmont@uhulinux.hu \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.