Hi, I recently ran nessus and it gave me some information like this ... On this machine, there is an X11-Server that grants access without authentification. That means a hacker is able to sniff every keystroke that is typed on the X11-Server (or get a copy of the victims screen). Solution: use MIT-Cookies, xauth. How do I get rid of this and stil use X11. Is using MIT-Cookies, xauth a real big change?? Also, can I comment out in inetd.conf telnet shell and login and still start a new xterm? Thanks for you thoughts, Eric
On Thu, 29 Jul 1999, Eric Mosley wrote:
On this machine, there is an X11-Server that grants access without authentification. That means a hacker is able to sniff every keystroke that is typed on the X11-Server (or get a copy of the victims screen). Solution: use MIT-Cookies, xauth.
Hello Eric, yes, indeed, starting X via "startx" on a SuSE system (NOT the X-server on tty7 under runlevel 3), is not secure at all. Some weeks ago I constructed a solution: This line in /etc/profile (already done in suse with x = startx): function x { /usr/X11R6/bin/startx $* &> ~/.X.err & } In ~/.alias: alias xl='cd;x -- -auth .Xauthority;logout' In the beginning of ~/.xinitrc: xauth add $DISPLAY . `ps auxw|md5sum|cut "-d " -f1` Then: starting X by "xl". Perhaps I forgot something, so write me if you have problems!
Also, can I comment out in inetd.conf telnet shell and login and still start a new xterm?
This has nothing to do with it... Yes, you can still start a new xterm! Ciao, Peter
On Thu, Jul 29, 1999 at 07:24:03PM +0200, Peter Münster wrote:
yes, indeed, starting X via "startx" on a SuSE system (NOT the X-server on tty7 under runlevel 3), is not secure at all. Some weeks ago I constructed a solution:
Ok, it turns out, that my machine has the same problem.. so I decided to try to get your solution up and running on my computer. I ran into some problems along the way... Since I am quite literate in bash syntax among other things, I have come up with a fix or two.
This line in /etc/profile (already done in suse with x = startx): function x { /usr/X11R6/bin/startx $* &> ~/.X.err & }
Ok, here's the first problem I ran into. In my /etc/profile there was already a startx function! (I'm running SuSE 5.3, with various patches and a shiny 2.2.x kernel) I don't know if SuSE has removed this from future releases, but it is already there. Find this line in /etc/profile: function xstart { /usr/X11R6/bin/xstart $* 2>&1 | tee ~/.X.err ; } it should be there, and it is functionally equivalent to what you wrote, Peter. I would suggest renaming some stuff so you don't accidentally open up X with this function or just startx itself, but that's only if you want to implement failsafes... ;)
In ~/.alias: alias xl='cd;x -- -auth .Xauthority;logout'
Ok, this is all good, except you don't really need that ";logout", for anyone not literate in bash syntax, that is the equivalent of typing logout immediately after you kill your xsession.. if anyone reading this is like me, they also use the command line for various programs, so remove the logout part if you intend to use the command line after exiting X.. Otherwise, this part worked great.
In the beginning of ~/.xinitrc: xauth add $DISPLAY . `ps auxw|md5sum|cut "-d " -f1`
Ah, the real workhorse. This is the important part... ps auxw to get some long more or less random output, md5sum and cut to format it nicely. Worked perfectly. Leave this intact.
Then: starting X by "xl".
Yup. And it works like a charm.
Perhaps I forgot something, so write me if you have problems!
*grin* So I fixed it on my own and posted it... oh well.. -- Jeff -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS/M/>P d-(pu) s+:- a17>? C++(++++) L+++ UL++(+++)@>++++$ P+ E W++@ N+ o? K- w--- O? M V- PS+ PE(--)@ Y++@ PGP t+ 5 X++@ R++@ !tv@ b++ DI++++ D- G e- h! r++ y? ------END GEEK CODE BLOCK------
[...]
In the beginning of ~/.xinitrc: xauth add $DISPLAY . `ps auxw|md5sum|cut "-d " -f1`
Ah, the real workhorse. This is the important part... ps auxw to get some long more or less random output, md5sum and cut to format it nicely. Worked perfectly. Leave this intact.
[...] Or, if you're really paranoid: xauth add $DISPLAY . \ `dd if=/dev/random bs=256k count=1 2>/dev/null|md5sum|cut "-d " -f1` :) Chris
On Thu, 29 Jul 1999, Jeff wrote:
In ~/.alias: alias xl='cd;x -- -auth .Xauthority;logout'
Ok, this is all good, except you don't really need that ";logout", for anyone not literate in bash syntax, that is the equivalent of typing logout immediately after you kill your xsession.. if anyone reading this is like me, they also use the command line for various programs, so remove the logout part if you intend to use the command line after exiting X.. Otherwise, this part worked great.
Hello Jeff, I hope, you have seen the letter from Michael: On Thu, 29 Jul 1999, Michael Bausch wrote:
btw: there is a startx-related local security issue. when you fire up X11 using startx, xlock the screen and walk away, someone with access to the keyboard could just switch back to the text console, background the startx process, kill the xlock process and thus gain full access to your Xsession. this can be prevented by using something like (startx &); exit instead of startx.
So that's the sens of "logout" ! ( my function x was with a "&" too ) Why "xl"? -> "X"-windows and "L"ogout ! :-)
*grin* So I fixed it on my own and posted it... oh well..
Yeah, thanks for the comments! Bye, Peter
Peter Münster wrote:
On Thu, 29 Jul 1999, Eric Mosley wrote:
On this machine, there is an X11-Server that grants access without authentification. That means a hacker is able to sniff every keystroke that is typed on the X11-Server (or get a copy of the victims screen). Solution: use MIT-Cookies, xauth.
Hello Eric, yes, indeed, starting X via "startx" on a SuSE system (NOT the X-server on tty7 under runlevel 3), is not secure at all. Some weeks ago I constructed a solution:
This line in /etc/profile (already done in suse with x = startx): function x { /usr/X11R6/bin/startx $* &> ~/.X.err & } In ~/.alias: alias xl='cd;x -- -auth .Xauthority;logout' In the beginning of ~/.xinitrc: xauth add $DISPLAY . `ps auxw|md5sum|cut "-d " -f1`
Then: starting X by "xl".
Perhaps I forgot something, so write me if you have problems!
Also, can I comment out in inetd.conf telnet shell and login and still start a new xterm?
This has nothing to do with it... Yes, you can still start a new xterm!
Ciao, Peter
-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
Hello, i read all that mails about nessus, but i'm little newby : do you thinck running X-server under tty7 in run-level 3 is secure ? Then what is nessus exactly and what are MIT_COOKIES - i saw some allusions in xauth man but i don't know how to use it. Joan Luc -- Be m'agrada la convinens sazos E m'agrada lo cortes temps d'estiu E m'agrada l'auzel, quan canta piu. E m'agrada floretas per boissos.
On Fri, 30 Jul 1999, Jean Luc Laborde wrote:
Hello, i read all that mails about nessus, but i'm little newby : do you thinck running X-server under tty7 in run-level 3 is secure ? Then what is nessus exactly and what are MIT_COOKIES - i saw some allusions in xauth man but i don't know how to use it.
Hello Jean-Luc,
In runlevel 3 X is run by xdm (or kdm), I think this is secure, but I'm
not sure (I don't use it). Take a look at the message of Mark Lutz
* Eric Mosley
How do I get rid of this and stil use X11. Is using MIT-Cookies, xauth a real big change??
Do you start your X-Server using "startx"? You could try starting it using "xdm" instead. That way the file ~/.Xauthority will be created. Or you change "/etc/rc.config" DISPLAYMANAGER="xdm". They same should work for "kdm". You can make these changes using "yast", Administration des Systems, Login-Konfiguration, ... The above worked for me, if I run Nesssus as a normal user. If I run Nessus as root I still get the message. You should try "man xauth" to get further information. Also check "/usr/X11R6/lib/X11/xdm/xdm-config". There you should find the entry: DisplayManager._0.authorize: true DisplayManager._1.authorize: true DisplayManager.*.authName: MIT-MAGIC-COOKIE-1 You see: the correct settings for MIT-Cookies are already set by SuSE (SuSE 6.0). Here some information SATAN tells you about MIT-Magic-Cookies: * Use the X magic cookie mechanism or equivalent. With logins under control of xdm, you turn on authentication by editing the xdm-config file and setting the DisplayManager*authorize attribute to true. * When granting access to the screen from another machine, use the xauth command in preference to the xhost command. The protection scheme used by SATAN is in essence the same as the scheme used by many implementations of the X Window system: MIT magic cookies. These secrets are normally kept in the user's home directory, in a file called .Xauthority. Before it is granted access to the screen, keyboard and mouse, an X client program needs to prove that it is authorized, by handing over the correct magic cookie. This requirement prevents unauthorized access, provided that the magic cookie information is kept secret.
Also, can I comment out in inetd.conf telnet shell and login and still start a new xterm?
I think xterm has nothing to do with telnet. Just comment out everything, do a "/sbin/init.d/inetd stop" and "/sbin/init.d/inetd start" and try to start "xterm". It will work! BTW: SuSE 6.0: There is a typo in "/sbin/init.d/inetd". That's why "/sbin/init.d/inetd restart" won't work. Use "resart" instead or fix it. PS: SuSE: Could someone please configure this mailing list, so that I will not get a dozen errors, if someone is on vacation or if his or her e-mail address doesnt exist. It's pissing me of. :-( -- Mark Lutz Accept German and English
participants (6)
-
Chris L. Mason -
Eric Mosley -
Jean Luc Laborde -
Jeff -
Mark Lutz -
Peter Münster