Hi.

Not sure whether noone has noticed this so far, but it seems to be worth
a CVE, IMHO.

As one can easily test, gpm uses one clip-board space for all users (including
root).
So if any of them marks anything sensitive, a following user can gather
this information.


Cheers,
Chris.

Likewise, if you log out, your Linux console screen is still readable
for the next user.  And even if you clear the screen before you log
out, the next user can still hit Shift-Prior (aka Shift-PageUp) and see
some of your work.

Who, in your opinion, should clear the scrollback buffer and the gpm
clipboard?  .bash_logout?  getty?

Well but
a) that's something one would clearly see; it's not "hidden" from the
user
b) therefore we have now per default a .bash_logout which resets the
screen.
As you say, scrollback buffer is usually cleared by .bash_logout and gpm
should "simply" have a clipboard per authenticated user that is cleared
when a user logs out of his last session, since even if it was kept _per
user_ (which is not the case currently) it would be somehow unclean if
it was still there on new logins after the user had logged out all
sessions.
Your X server also doesn't bring back your clipboard, when you re-login
as the same user.


Cheers,
Chris.

Hi.


First.... gpm has no bug tracker right? So could you please CC the
Debian bug, that we can record all this at some central palce? :)
I've updated some information there:
Mainly that I think that ideally, a clipboard should be kept per logged
in user (and obviously each user should only get access to "his"
clipboard).
This includes, that a user's clipboard is removed one he has logged out
from all his sessions.
It does not mean, that there should be a clipboard for each terminal of
a user.
Note that this is of course not only a security hole between root/user-A
but also between user-A/user-B situations.
I can't understand why you think this... especially on multi-user
systems it IS absolutely critical.
The system could be some terminal computer where people from many
different places can access a console.
I don't exactly understand what you did there... gpm shouldn't work
within X at all, should it?
See my comments above, that go even a bit further...
Obviously session tracking would complicate things a bit,... one could
e.g. use consolekit for this, but that may be an unwanted dependency.

From a "theoretical" security point of view, there should be no strict
need, to clear a user's clipboard when all his sessions are logged out.
Because an attacker that gains access to this (and could therefore read
the clipboard on subsequent re-logins) could probably also install
key-loggers or so.
But it may be helpful on systems where multiple persons share one
account (in theory each person should have it's own account, which is
why I wrote "theoretical" above)... an it's also the behaviour of X'
clipboard.


Cheers,
Chris.

Hi Chris,

   thank you for your reply.

As noted, didn't file Red Hat Bugzilla bug yet, since I am not completely
sure this is a security issue (and first wanted to obtain feedback from
gpm developers / upstream).

I don't see that far into gpm code. Maybe the callback handling paste-clipboard
event should check for UID (if it's the same as was used in the copy-clipboard
callback handler).

Sure, just focused on root/unprivileged user scenario in my testing.

Right, valid concern.

Didn't know about this restriction. But noticed now in gpm's manual page.

Didn't completely mean separated clipboard for each of the users (like
there would be another instance for each of them). Was rather thinking
of checking UID when pasting, if it matches UID used for copying (but
not sure this would be implementable). Will let gpm developers to reply
here.
--
Jan iankko Lieskovsky / Red Hat Security Response Team

P.S.: Nico, Nikola could you let us know your opinion on the above?
       (upstream view at the issue as a whole and possibilities how to
       fix it [if willingness]).

Yeah that's okay,... but I think it's good to record other things in the
meantime at the debian bug, to have it at least somewhere =)
Okay... just wanted to point out again, that it's critical for both
scenarios.


Upstream folks,... have you had already time to think about all this?
I don't think that this issue is highly critical, but one should
probably fix it, request a CVE and so on.


Cheers,
Chris.

Hello,

I'm not sure what's the news with this bug.
It should be clear to anyone using gpm that every local user
has access to its buffer.

I don't even believe this is a bug - but a feature: You can cat on one
console as $foouser and paste on another console as $other use.

You can open up a CVE or whatever for it, but it may not be appropriate.

GPM is not bound to however is logged in - you can even use it, if you
are *not* logged in at all - to for instance copy the bootmessages from tty1
to a logged in console on tty2.

That said - if you really want the behaviour of gpm working only if a
user is logged in, feel free to submit a patch against latest stable
source code using a new parameter like --per-user-clipboard
or --per-tty-clipboard (which would save you of another mapping table).

Cheers,

Nico

p.s.: changed e-mail address to the correct one

Hey Nico, et al.
Well the thing is, that this IS a security problem.... be it new, or
not :)
No,... in all doing respect,... this simply can't be a feature...
It's a security issue,... one can argue how critical it is, but given
that you cannot know how the consoles of a system are used (maybe
thousands of remote users can log into them via some way) it should be
quite clear that this can become a big problem.

Don't think of laptop-only systems which are usually run by just one
user (or at least just one user at a given time).
So this is basically an implicit wish/request to someone with insight to
the code to change it ;-)
could get into troubles.
(Just consider someone selects rm -rf / <newline> that way,.. and
another user, thinking he has still the old content in the clipboard
pastes this in the shell.


Cheers,
Chris.

Hello,

gpm does not implement the paste functionality, it's all handled in the
kernel. gpm only calls ioctl(TIOCLINUX) to set the selection (by only
giving the coordinates!), and make the kernel paste.

Not allowing cross-user copy/paste would be a big regression. I use it
quite often for instance.

Systematically clearing the selection on log-out could be unconvenient
too.

Clearing the selection when nobody is logged any more, however, should
be fine.  As long as a user is logged in, if somebody else comes over
the keyboard he'll be able to do other nasty things anyway.  I believe
that can be implemented in consolekit, it merely needs to do the ioctl
on last logout.  There is no need for gpm patch anyway, it's all in the
kernel.

Samuel

Well... but in principle there must be some way for it to control
pasting, as pasting doesn't work when gpm is not running...
Ok,... I also use it,... but nevertheless it's a security hole.
You could argue the same way that all user share a common X.org
clipboard - just because it's handy.

A "solution" might be to add a configuration option, that allows
cross-user copy/pasting... but that should then be disabled per default,
IMHO.
As mentioned before several times:
don't think that limited, that console access always means begin
directly at the hardware with a keyboard... just think about serial
console via some network adapters...



Cheers,
Chris.

Christoph Anton Mitterer, le Mon 09 Jul 2012 20:28:55 +0000, a écrit :
to make the kernel paste. But it doesn't even know what is being pasted.

I wonder who will ever notice and enable it.

I haven't seen that mentioned in this thread.
logged into the keyboard console, they don't have any access to the
keyboard console, and thus not to the copy/paste buffer either.

Samuel

Ah,... I now I see... so one would need to implement in the kernel, that
every user has it's own clipboard space... and only then gpm could do
something like:
onclick()
{
	if(userFits())
		ioctl(...)
	else
		;//do nothing
}
Well I guess people who desperately miss that "feature" would probably
have a look at the documentation.
And especially we in Debian have debconf that could simply ask. :)
I doubt... we at the super computing centre have many nodes where we use
some sort of serial console access (differently implemented depending on
different hosts),... where I can log in from remote places (via ssh or
browser) and get a console on which I can use gpm.
And it's the same if you remotely log in on the consoles of VMs.


Cheers,
Chris.

Christoph Anton Mitterer, le Tue 10 Jul 2012 00:08:22 +0200, a écrit :

That won't prevent any user from calling the ioctl. The ioctl is not
privileged. That should really be done in the kernel.

Such kinds of questions are quite frowned upon.

What does "use gpm" mean exactly?  What does the "tty" command return?
Is the content of the consoles exactly the same as what's physically
displayed on the machine?

I can "use gpm" in my xterms for instance, but copy/paste is entirely
done by X11.

Log how? Which tool?  There are a plethora of ways to access a machine
with very varying effects.

Samuel

Uhm.. yeah well... but there are already quite a lot of them... and I
personally consider them to be quite ok, when the priority is reasonably
set...
Tried 3 different kinds of hosts here now,.. those had either
/dev/tty{N}
or
/dev/console
Cannot check here now, sorry, access to the building is highly
restricted.
Ah? Ok... I never saw the gpm typical pointer in X terminals... and
always thought they'd work completely independent..
On the nodes that I've tried now runs VMware (yes... sigh)... and there
it's some awkward proprietary browser plugin...
Well and that's the point I tried to emphasise before... one cannot now
by which way users use the systems,... but one can be sure that there
may be some that run into troubles.


Anyway...
Expecting you're right with the syscalls... (too busy now to look into
the code :-/ ) I'd agree that the issue cannot be solved in gpm itself.

But as long as a real solution is found (if ever accepted in the
kernel)... I'd say that gpm should warn it's users of this potential
security issue.
I can imagine amongst the following:
- a SECURITY file in /u/s/d/gpm that describes the issue (which should
probably distributed part of upstream)


specific to Debian:
- a shorter warning in the package description

- and maybe the same as in SECURITY via debconf
I know you probably don't like the later ;-) ... but I guess it's the
best chance to reach most (Debian) users.


Apart from what can be done (now) at a gpm level (i.e. warnings)... how
shall be proceeded?
Popping the issue up at lkml? Anyone with good connections?
If the ioctl is part of the tty subsystem chances are probably rather
bad to get things done... last time I read,... the subsystem was still
one of the don't-touch-miracles...


Cheers,
Chris.

Christoph Anton Mitterer, le Tue 10 Jul 2012 00:51:23 +0200, a écrit :

Can somebody connect to the console too and see what you are doing, and
interfere with it?

The pointer doesn't show up in X terminals, but from the point of view
of applications, they get mouse events etc. from libgpm just as if they
were run on the linux console.

So I believe it's simply access to the hardware console.

And I'm on the contrary sure that all these ways fall into two
categories:

- access to the physical console (/dev/tty[1-9]), in which case you
already have access to it, type things, etc.
- access via network (ssh, telnet), or serial (/dev/ttyS0, etc.) in
which case you do not have access to the physical console.

It's only part of the VT subsystem.

Samuel

severity 677418 normal
thanks

This is long-standing behaviour of GPM and changing it would break
valid use cases. There's certainly room for a new option with a
more tight handling, but this is not a RC security bug.

Cheers,
        Moritz