Bug 149037 - "New Login" button on xscreensaver unlock dialog launches gdm flexi Xserver
"New Login" button on xscreensaver unlock dialog launches gdm flexi Xserver
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: xscreensaver (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
ftp://tux.go-nix.ca/incoming/Screensh...
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-17 22:48 EST by Gabriel Schulhof
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-14 11:45:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
New button to allow logins from the xscreensaver password dialog (22.61 KB, patch)
2005-02-17 22:50 EST, Gabriel Schulhof
no flags Details | Diff
Final (?) version of the patch, adding mouse functionality during password dialog (23.55 KB, patch)
2005-02-28 03:30 EST, Gabriel Schulhof
no flags Details | Diff
Instead of socketeering over to gdm, simply run gdmflexiserver (18.04 KB, patch)
2005-02-28 20:45 EST, Gabriel Schulhof
no flags Details | Diff
Modified the patch to follow Jamie's suggestions (20.40 KB, patch)
2005-03-01 01:31 EST, Gabriel Schulhof
no flags Details | Diff
new patch (29.40 KB, text/plain)
2005-03-05 06:42 EST, Jamie Zawinski
no flags Details

  None (edit)
Description Gabriel Schulhof 2005-02-17 22:48:44 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.7.5) Gecko/20050109 Fedora/1.7.5-3

Description of problem:
I have written a patch against xscreensaver-4.19 as available on Jamie Zawinski's Web site which adds a "New Login" button to the xscreensaver password dialog which, when pressed, initiates a dialog with gdm over /tmp/.gdm_socket and asks it to start a new flexi server. This would allow computers used by more than one person to easily provide multiple graphical logins on demand.

The patch has one shortcoming: The mouse is either invisible or entirely disabled during the lifetime of the xscreensaver password dialog, so, while the button works when running the password dialog from a test utility (part of xscreensaver), it doesn't work "live", because there's no mouse available for clicking on it.

Version-Release number of selected component (if applicable):
xscreensaver-4.19

How reproducible:
Always

Steps to Reproduce:
1. Log in on gdm.
2. Lock the screen.
3. Good luck to anyone else trying to log in via gdm.

Actual Results:  It's very difficult to start another graphical login manager, let alone another GNOME session.

Expected Results:  There should be a way to start a new login screen - much like fast user switching on Windoze or OSX.

Additional info:
Comment 1 Gabriel Schulhof 2005-02-17 22:50:46 EST
Created attachment 111191 [details]
New button to allow logins from the xscreensaver password dialog
Comment 2 Gabriel Schulhof 2005-02-28 03:30:37 EST
Created attachment 111465 [details]
Final (?) version of the patch, adding mouse functionality during password dialog

I finished off the patch. Thus, the mouse cursor becomes visible during the
password dialog. The cursor is trapped inside the password dialog (as it should
be), and the user can click on the "New Login" button to start a new flexi
server.

This patch is against version 4.20 of xscreensaver.
Comment 3 Ray Strode [halfline] 2005-02-28 11:25:52 EST
Hi Jamie,
What are your thoughts on this patch?  Would something like this every
make it upstream?
Comment 4 Gabriel Schulhof 2005-02-28 12:07:50 EST
Hi!

I talked to jwz about this, and he was not very enthusiastic about my
first patch (the one where the mouse wasn't working) because when he
tried starting a flexi server, it messed up his X. I can forward you
the messages we've exchanged, if you'd like.

I sent him the new, fully working patch, but I haven't heard back from
him yet (as of 2005-02-28 10:06:27 MST).
Comment 5 Jamie Zawinski 2005-02-28 15:47:54 EST
Yeah, the one time I tried to play around with gdmflexiserver it
fucked up my machine real bad.  I haven't had the stomach to try again.

I don't object to a gdmflexiserver button in principle, but if my
experience is any indication of what other users are going to
experience, we might as well label that button "Self Destruct".

Also, after thinking about it some more, I think it's probably a lot
less fragile (and hopefully no less secure?) to fork/execvp the
"gdmflexiserver" program than to explicitly speak to gdm through a
socket.  The gdm protocol looks marginally hairy, and I wouldn't trust
it not to change on us at some point.
Comment 6 Gabriel Schulhof 2005-02-28 17:21:14 EST
I would be the first to change my patch over to fork/execvp instead of
re-implementing part of the protocol from the gdmflexiserver sources,
however, I share Jamie's jitters over executing stuff from the login
screen. We will need to think of a way to determine the path to the
gdmflexiserver binary securely so that, when we finally execute it, we
can be relatively sure that we're executing the gdmflexiserver binary
and not another binary named gdmflexiserver. To this end, I can think
of 2 different ways:

1. Path search:
pfile = popen ("which gdmflexiserver", "r") ;
Read off the path (if any) from pfile
pclose (pfile) ;

The currently logged in user may prefix the PATH with her own
directories and we may end up executing some other binary. A malicious
user could /fake/ a login screen and harvest a password like so:
xinit ${HOME}/my_fake_gdm_login_screen_I_wrote_in_GTK -- :1

2. app-defaults
X resources can be overwritten by the logged in user, correct ? If so,
my view of the consequences is reduced to the scenario speculated
about above.

Is there someplace we can specify the path to gdmflexiserver in a way
that cannot be overridden by the currently logged-in user ?

Another concern:
The currently logged in user could choose to run her own version of
xscreensaver, where the button is totally hacked up, so it will do
what she wants, irrespective of what we tried to make it do. Once
again, the fake login scenario comes to mind.

Bottom line: How can a user who walks up to the screenlocked computer
wanting to log in be absolutely assured that when she presses the "New
Login" button, she will get a brand-spanking new, completely genuine
gdm login screen ?

I suppose, looking at the way OSX does it, I'm lead to conclude that
the above question can be asked in any "Switch User" scenario.

Perhaps the most secure way to allow multiple logins is for gdm to
"fork off" the session to a new X server after authenticating the
user, and to switch vts to the new X server which houses the user's
session. In such a case, the genuine gdm login screen would always be
present, and a person walking up to the computer need only browse
through the vts to find it.

Even so, a gdm login screen could be faked on a vt other than the
genuine one, however, there would always be at least one genuine gdm
login screen on /some/ vt. The fake one could be killed with a
Ctrl+Alt+Backspace and, unlike the genuine one, it wouldn't come back.
This is something an extremely paranoid user could do to be absolutely
assured that she is logging into a genuine gdm.

Of course, this would not be very convenient for non-computer-literate
users, who are unaware of the hidden powers of
Ctrl+Alt+F([1-9]|1[0-2]). For instance, I would have to teach my mom
to "walk through all the F-keys until you find the blue login screen".
Comment 7 Jamie Zawinski 2005-02-28 17:42:55 EST
xscreensaver's primary function is to execute programs, so I think we
can assume that if an attacker can manipulate the $PATH that
xscreensaver sees, the game is already lost.  E.g., they could just as
easily replace "qix" as "gdmflexiserver".  (Though this is made
somewhat less likely by the compile-time
-DDEFAULT_PATH_PREFIX=/usr/X11R6/lib/xscreensaver)

> The currently logged in user could choose to run her own version of
> xscreensaver, where the button is totally hacked up,

Or, today, they could run a hacked-up gdm that makes it look like
nobody is logged in when really someone is and it's logging passwords.
 This is not a new attack, and not made worse, I think, by a
gdmflexiserver button.

> Bottom line: How can a user who walks up to the screenlocked 
> computer wanting to log in be absolutely assured that when she 
> presses the "New Login" button, she will get a brand-spanking new, 
> completely genuine gdm login screen ?

Only by rebooting, and probably not even then.

You can't even assume that C-Alt-BS will actually reset the server:
the attacker might be running X with DontZap and trapping that too.

For that matter, the machine might be running a trojan kernel booted
off a USB disk.  It depends on how paranoid you want to be, and how
persistent you think an attacker might be.
Comment 8 Gabriel Schulhof 2005-02-28 20:45:58 EST
Created attachment 111511 [details]
Instead of socketeering over to gdm, simply run gdmflexiserver

Well, I was assuming the user didn't have root access to the machine. I was
also assuming that the machine couldn't be mutilated hardware-wise.

Anyhow, this patch executes the value of the resource "passwd.login.command"
using system(), instead of connecting to the gdm socket.
Comment 9 Jamie Zawinski 2005-02-28 20:58:09 EST
Instead of system(), use fork_and_exec() -- see do_prefs() and
do_help() in splash.c.  (You'll have to make it not be static, or put
do_loginmanager() in splash.c)

Also, I'd arrange for loginmanager_p() to be called once at startup
instead of every time the passwd window is created.  Store the command
in struct saver_preferences along with demo_command and help_url.
Comment 10 Gabriel Schulhof 2005-03-01 01:31:03 EST
Created attachment 111516 [details]
Modified the patch to follow Jamie's suggestions
Comment 11 Gabriel Schulhof 2005-03-04 01:20:22 EST
So, ummm ... not to impose or anything, but, ummm ... what, if
anything, is to become of this patch ?
Comment 12 Jamie Zawinski 2005-03-05 06:42:16 EST
Created attachment 111691 [details]
new patch

This patch should work against xscreensaver 4.20 (line numbers are slightly
off.)  Please try it and let me know what you think.  If it seems to work, I'll
include this in 4.21.

I made it be less paranoid about the command it's executing, since I think that
if $PATH is attackable, we've already lost.  Also, the button is there if the
"newLoginCommand" resource is set at all (it doesn't sanity-check it first.)

It does, however, only let you click the button once (to avoid launching
multiple copies of gdmflexiserver.)  If you dismiss the dialog (e.g. with RET)
then the button will be active again next time.

Use configure --with-login-manager to turn it on by default.

On my FC3 system (2-head xinerama, nvidia drivers) running "gdmflexiserver" is
still a "self-destruct" command: if I run it, it totally fucks my machine and I
have to ssh in and kill X and gdm to get it to come back.  I can't even switch
VTs.

So, you know, color me unimpressed with this new facility.
Comment 13 Gabriel Schulhof 2005-03-05 14:57:36 EST
Well, it works perfectly. Love the "Self Destruct!" label :o)
Comment 14 Matthew Miller 2006-07-10 18:02:28 EDT
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!
Comment 15 Ray Strode [halfline] 2007-08-14 11:45:37 EDT
The information we've requested above is required in order
to review this problem report further and diagnose/fix the
issue if it is still present.  Since there haven't been any
updates to the report in quite a long time now after we've
requested additional information, we're assuming the problem
is either no longer present in our current OS release, or
that there is no longer any interest in tracking the problem.

Setting status to CANTFIX, however if you still
experience this problem after updating to our latest Fedora
Core release and are still interested in Red Hat tracking
the issue, and assisting in troubleshooting the problem,
please feel free to provide the information requested above,
and reopen the report.

Thank you in advance.

(this message is mass message)

Note You need to log in before you can comment on or make changes to this bug.