____________________________________________________________________________________


                              **********************
                              * GDM Murder Attack  *
                              **********************

                        by Ashtar <ashtar@dragon.hack.tc>
         
Thanks to CyberKahn <cyberkahn@hack.tc> for testing and adding some stuff
to this text. 
_____________________________________________________________________________________


Exploit: Possible local root comprimise / or DoS against GDM

Affected:  gdm-2.0beta4-0_helix_6, gdm-2.0beta2-26, gdm-2.0beta2-23
(Other versions are untested by us).

Tested on: Linux (Red Hat 6.2)

-------------------------------------------------------------------------------------

Alright this isn't going to be a highly detailed explanation, but it'll do.
If this has already been pointed out before, sorry.
Sorry kiddies, no scripts to ./dotslash with. You'll have to use Keyboard Kung-f00 
to exploit this for now. A few conditions would have to be in place to gain root
of course. That is, that root actually started gdm from his/her shell,
and not just let the system boot into runlevel 5. Of course that is a pretty insecure 
way to do things, but think of this as proof of concept. If gdm is starting up on auto 
because the system was booted into runlevel 5, you can still kill gdm with this
method however. So either way, we have here a local root exploit or a DoS against GDM.

Heres a process list output of what GDM (referring to the entire program) looks like 
when its running. In this example we have the main process running (PID 627), 
the slave process (PID 755) and gdmlogin, and of course, X.

  627 ?        00:00:00 gdm
  754 ?        00:00:00 X
  755 ?        00:00:00 gdm
  762 ?        00:00:00 gdmlogin


The main process of gdm (PID 627) will just spawn another slave if you restart X. 
However if you kill X continuously and rapidly you can eventually kill off the 
main gdm process.

  834 ?        00:00:00 X
  837 ?        00:00:00 gdm
  845 ?        00:00:00 gdmlogin


Now after the main process is killed, it would probably have still spawned another 
slave, you might notice a slight halt for a second as X restarts, and then
gdmlogin will pop back up. However since the main process is out of the picture, 
you can now kill X without worrying about gdm respawning a slave, and depending 
on the circumstances, possibly be dropped into a root shell, or just "DoS"
GDM.


Here is a sample message you'll recieve once you restart gdm after performing
the attack.

"According to /var/run/gdm.pid, gdm was already running (627), but seems 
to have been murdered mysteriously."


If you perform this attack on a system that has gdm start automatically on 
bootup (runlevel 5), you'll probably just get thrown back to the standard login
prompt.

But gdm won't totally be dead, root will have to kill it, to have it 
start back up all over again (See ps output below).

  656 tty1     00:00:00 mingetty
  669 ?        00:00:00 gdm
  683 ?        00:00:00 X <defunct>


Some things to consider:

Although this might not seem like a major local exploit it could be.
Imagine a facility running gdm as its default login. In the event
the box is running this process as root they would have root access. Even
worse, lets say the facility is running NIS, and they have set up NIS 
to distribute root. Now they have even more control. 

Or maybe someone wants to take a crack at the root password but root
logins are disabled by gdm. They can probably use this exploit to
DoS gdm and start hammering away at the standard login.
At the very least, they'd be able to "DoS" gdm, which could just be annoying.


Possible Solutions: 

The first and foremost thing to remember is, don't login as root
and just execute 'gdm'. This is just asking for trouble.

You can at least disable the <ctrl> + <alt> + <backspace> sequence, 
so you can't break out of X so easily. You can simply trap this key set by editing
your /etc/X11/XF86Config file. Just search for DontZap and uncomment this line.
This will disable someone from using this key stroke to break out of X / gdm.
As it stands right now gdm is too much of a security risk. The best solution
is to login and type "startx" for now. ;-)

---------------------------------------------------------------------------------

(C) Ashtar <ashtar@dragon.hack.tc>

Ashtar and CyberKahn would like to greet: Moshing, Talk, Guato, 
Dark Thorn, JC, delete-, 561.2600 and everyone else.

----------------------------------------------------------------------------------