All of lore.kernel.org
 help / color / mirror / Atom feed
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 13:08:42 +0900	[thread overview]
Message-ID: <40CBD34A.8030608@ThinRope.net> (raw)
In-Reply-To: <40CBC094.6050901@ThinRope.net>

Kalin KOZHUHAROV wrote:
> 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.
> 
Ok, I changed agetty to mingetty (I was long waiting to do that).
However this didn't change things.
Now, playing with switching VT, however, the buffer was cleared!

So, I guess this is agetty problem then...

Also for point 2 you can do with:
2. cat /etc/services

When I logout a given box from the console, I repetedly do Alt+Left to check if there are some VT left logged in and thus I clear all the buffers as a side effect (now with mingetty).

Kalin.

-- 
||///_ o  *****************************
||//'_/>     WWW: http://ThinRope.net/
|||\/<" 
|||\\ ' 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  parent reply	other threads:[~2004-06-13  4:08 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
2004-06-13  3:47           ` David Lang
2004-06-13  4:08           ` Kalin KOZHUHAROV [this message]
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=40CBD34A.8030608@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.