Type packetstorm
Modified 2000-10-15T00:00:00


* GDM Murder Attack *  
by Ashtar <>  
Thanks to CyberKahn <> 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"  
Here is a sample message you'll recieve once you restart gdm after performing  
the attack.  
"According to /var/run/, 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  
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 and CyberKahn would like to greet: Moshing, Talk, Guato,   
Dark Thorn, JC, delete-, 561.2600 and everyone else.