ID PACKETSTORM:23334 Type packetstorm Reporter dragon.hack.tc Modified 2000-10-15T00:00:00
Description
`____________________________________________________________________________________
**********************
* 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.
----------------------------------------------------------------------------------
`
{"hash": "638e781de7b45945be26fad7d0e92498da5cd87c9b8498434bb25496b6ef361e", "sourceHref": "https://packetstormsecurity.com/files/download/23334/gdmurder.txt", "title": "gdmurder.txt", "id": "PACKETSTORM:23334", "published": "2000-10-15T00:00:00", "description": "", "modified": "2000-10-15T00:00:00", "sourceData": "`____________________________________________________________________________________ \n \n \n********************** \n* GDM Murder Attack * \n********************** \n \nby Ashtar <ashtar@dragon.hack.tc> \n \nThanks to CyberKahn <cyberkahn@hack.tc> for testing and adding some stuff \nto this text. \n_____________________________________________________________________________________ \n \n \nExploit: Possible local root comprimise / or DoS against GDM \n \nAffected: gdm-2.0beta4-0_helix_6, gdm-2.0beta2-26, gdm-2.0beta2-23 \n(Other versions are untested by us). \n \nTested on: Linux (Red Hat 6.2) \n \n------------------------------------------------------------------------------------- \n \nAlright this isn't going to be a highly detailed explanation, but it'll do. \nIf this has already been pointed out before, sorry. \nSorry kiddies, no scripts to ./dotslash with. You'll have to use Keyboard Kung-f00 \nto exploit this for now. A few conditions would have to be in place to gain root \nof course. That is, that root actually started gdm from his/her shell, \nand not just let the system boot into runlevel 5. Of course that is a pretty insecure \nway to do things, but think of this as proof of concept. If gdm is starting up on auto \nbecause the system was booted into runlevel 5, you can still kill gdm with this \nmethod however. So either way, we have here a local root exploit or a DoS against GDM. \n \nHeres a process list output of what GDM (referring to the entire program) looks like \nwhen its running. In this example we have the main process running (PID 627), \nthe slave process (PID 755) and gdmlogin, and of course, X. \n \n627 ? 00:00:00 gdm \n754 ? 00:00:00 X \n755 ? 00:00:00 gdm \n762 ? 00:00:00 gdmlogin \n \n \nThe main process of gdm (PID 627) will just spawn another slave if you restart X. \nHowever if you kill X continuously and rapidly you can eventually kill off the \nmain gdm process. \n \n834 ? 00:00:00 X \n837 ? 00:00:00 gdm \n845 ? 00:00:00 gdmlogin \n \n \nNow after the main process is killed, it would probably have still spawned another \nslave, you might notice a slight halt for a second as X restarts, and then \ngdmlogin will pop back up. However since the main process is out of the picture, \nyou can now kill X without worrying about gdm respawning a slave, and depending \non the circumstances, possibly be dropped into a root shell, or just \"DoS\" \nGDM. \n \n \nHere is a sample message you'll recieve once you restart gdm after performing \nthe attack. \n \n\"According to /var/run/gdm.pid, gdm was already running (627), but seems \nto have been murdered mysteriously.\" \n \n \nIf you perform this attack on a system that has gdm start automatically on \nbootup (runlevel 5), you'll probably just get thrown back to the standard login \nprompt. \n \nBut gdm won't totally be dead, root will have to kill it, to have it \nstart back up all over again (See ps output below). \n \n656 tty1 00:00:00 mingetty \n669 ? 00:00:00 gdm \n683 ? 00:00:00 X <defunct> \n \n \nSome things to consider: \n \nAlthough this might not seem like a major local exploit it could be. \nImagine a facility running gdm as its default login. In the event \nthe box is running this process as root they would have root access. Even \nworse, lets say the facility is running NIS, and they have set up NIS \nto distribute root. Now they have even more control. \n \nOr maybe someone wants to take a crack at the root password but root \nlogins are disabled by gdm. They can probably use this exploit to \nDoS gdm and start hammering away at the standard login. \nAt the very least, they'd be able to \"DoS\" gdm, which could just be annoying. \n \n \nPossible Solutions: \n \nThe first and foremost thing to remember is, don't login as root \nand just execute 'gdm'. This is just asking for trouble. \n \nYou can at least disable the <ctrl> + <alt> + <backspace> sequence, \nso you can't break out of X so easily. You can simply trap this key set by editing \nyour /etc/X11/XF86Config file. Just search for DontZap and uncomment this line. \nThis will disable someone from using this key stroke to break out of X / gdm. \nAs it stands right now gdm is too much of a security risk. The best solution \nis to login and type \"startx\" for now. ;-) \n \n--------------------------------------------------------------------------------- \n \n(C) Ashtar <ashtar@dragon.hack.tc> \n \nAshtar and CyberKahn would like to greet: Moshing, Talk, Guato, \nDark Thorn, JC, delete-, 561.2600 and everyone else. \n \n---------------------------------------------------------------------------------- \n`\n", "reporter": "dragon.hack.tc", "hashmap": [{"key": "bulletinFamily", "hash": "708697c63f7eb369319c6523380bdf7a"}, {"key": "cvelist", "hash": "d41d8cd98f00b204e9800998ecf8427e"}, {"key": "cvss", "hash": "d4be9c4fc84262b4f39f89565918568f"}, {"key": "description", "hash": "d41d8cd98f00b204e9800998ecf8427e"}, {"key": "href", "hash": "fde5c209de5744b4ef525a915bad018f"}, {"key": "modified", "hash": "e84cfd5f94e4dab10777cc5854b10ebe"}, {"key": "objectVersion", "hash": "56765472680401499c79732468ba4340"}, {"key": "published", "hash": "e84cfd5f94e4dab10777cc5854b10ebe"}, {"key": "references", "hash": "d41d8cd98f00b204e9800998ecf8427e"}, {"key": "reporter", "hash": "7defa8e93d249b878dafbd177b4ae3ff"}, {"key": "sourceData", "hash": "f445e55ff97c12875e55de0436ecb921"}, {"key": "sourceHref", "hash": "ec9112e6678800ffa956b8f90ca86d4b"}, {"key": "title", "hash": "d9d085891101a576d7c539fdf4fb830d"}, {"key": "type", "hash": "6466ca3735f647eeaed965d9e71bd35d"}], "cvss": {"vector": "NONE", "score": 0.0}, "references": [], "type": "packetstorm", "cvelist": [], "history": [], "bulletinFamily": "exploit", "objectVersion": "1.2", "edition": 1, "href": "https://packetstormsecurity.com/files/23334/gdmurder.txt.html", "lastseen": "2016-11-03T10:28:38", "viewCount": 0, "enchantments": {"vulnersScore": 7.2}}
