HUGE security hole ! How to close?

HUGE security hole ! How to close?

Post by Michael Veksl » Fri, 20 Jan 1995 23:47:34



I found a way to kill any "xlock" on any machine as a simple user.
This can be done as long as I can login to that machine of
after "xhost +".
I've written something that makes the job automatically on any
machine I choose (in few seconds).
I don't want to post the exact procedure (who knows what can be done
with this information...).

I would like to know if there is any way to block this hole.

  Thanks
     Michael

 
 
 

HUGE security hole ! How to close?

Post by Steve Heista » Sat, 21 Jan 1995 01:11:01



Quote:>I found a way to kill any "xlock" on any machine as a simple user.
>This can be done as long as I can login to that machine of
>after "xhost +".
>I've written something that makes the job automatically on any
>machine I choose (in few seconds).
>I don't want to post the exact procedure (who knows what can be done
>with this information...).
>I would like to know if there is any way to block this hole.
>  Thanks
>     Michael

There is no way to block it, but to fix the hole remove
the suid root bit on xlock.  Linux is not the only
OS that suffers from this "bug".

steve

--
=-------------------------------------------------------------------------=

=                                                                         =
=  Scalable Computing Lab     Phone: (515) 294-1918                       =
=  237 Wilhelm Hall           Fax  : (515) 294-4491                       =
=  Iowa State University      Home : 227 Hyland Ave Ames, Ia 50014        =
=  Ames Ia 50011                     (515) 292-8445                       =
=                                                                         =
=  www: http://www.physics.iastate.edu/cfd/people/heistand/heistand.html  =
=                                                                         =
=         We are far to busy around here to get anything done.            =
=       GE D? P C++ L+ U++ E++ M+ S N- H-- F* G- W+++ T+ T+ Y*            =
=-------------------------------------------------------------------------=

 
 
 

HUGE security hole ! How to close?

Post by A Chris Lo » Sat, 21 Jan 1995 13:01:40


xhost is ok security if the people you want to protect against can't
log into your server machine (I think).  If you want better security,
try xauth (still by no means perfect, but better than xhost).

- Chris

A. Chris Long, Jr.              \ "I am attempting, madam, to construct a
Graduate Serf^H^H^H^HStudent     \ pneumonic memory circuit out of stone knives

WWW: http://www-plateau.cs.berkeley.edu/people/allanl \  Edge of Forever"

 
 
 

HUGE security hole ! How to close?

Post by Wolfgang Barts » Sun, 22 Jan 1995 00:52:31



>I found a way to kill any "xlock" on any machine as a simple user.
>This can be done as long as I can login to that machine of
>after "xhost +".
>I would like to know if there is any way to block this hole.

Yes. Use "xauth" instead of "xhost".
--
Gr"u"se,   (~\/\/~)
            \_/\_/olfgang

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                    <A HREF=http://www.leo.org/~bartsch/>Wolfgang Bartsch</A>

 
 
 

HUGE security hole ! How to close?

Post by Daniel Stephe » Sun, 22 Jan 1995 03:04:12


    Michael> I found a way to kill any "xlock" on any machine as a
    Michael> simple user.  This can be done as long as I can login to
    Michael> that machine of after "xhost +".  I've written something
    Michael> that makes the job automatically on any machine I choose
    Michael> (in few seconds).  I don't want to post the exact
    Michael> procedure (who knows what can be done with this
    Michael> information...).

    Michael> I would like to know if there is any way to block this
    Michael> hole.

  I wouldnt say that this was a 'HUGE security hole'... When someone types
'xhost +' they're saying:

         "hey I don't care what anyone does to any of my windows"

It's just like someone setting a null password.. You wouldn't say that the
system had a HUGE security hole, you'd say that the user was a little 'naive'
and hope that they will learn from their mistake. The same kind of thing
applies with 'xhost', you should do 'xhost -' and maintain your system
integrity by carefully managing the magic cookies created by xauth et al..

(Another solution is do "xhost +", run whatever it was you wanted to run on
 the remote system, then do "xhost -", the open connection will remain open,
 but new ones will be refused - Of course this can work against you, since
 someone can open a fairly dormant connection while your server is available,
 and it will stay open even if you restrict access - In fact, depending on
 your X server, it will stay open until you restart X.)

Daniel.

PS: If I completely mis-understood your problem then none of the above will
    be of any use - however I don't think I did.
--
/-           Daniel Stephens            ---------------------#----------------\

| .signature still under development 8-)                    ### ##  # # 'LIFE'|
\-----------------------------------------------                 #  ##       -/

 
 
 

HUGE security hole ! How to close?

Post by b.. » Mon, 23 Jan 1995 10:10:38


: I found a way to kill any "xlock" on any machine as a simple user.
: This can be done as long as I can login to that machine of
: after "xhost +".
: I've written something that makes the job automatically on any
: machine I choose (in few seconds).
: I don't want to post the exact procedure (who knows what can be done
: with this information...).

: I would like to know if there is any way to block this hole.

:   Thanks
:      Michael

   Can't you get out of Xlock on a Linux machine just by hitting
<CTRL>-<ALT>-<BACKSPACE> and killing X altogether?  Though I suppose this
wouldn't be too effective if XDM was being used.  Just a thought...

                                                Bill
--
Bill McKinnon                        Senior Information Technology Assistant


 
 
 

1. Security Hole on webservers run on variuos OS, How to close UNIS hole

Hi,

I have written a program that enables me via the web, to access any file
(access is see it and download it) on a webservers hard drive. It
basically exlpores the drive (/ root downwards). Now the Apache Server
that run my program delivers the results to my browser. I wrote it
initailly to test the security of our account.

So what permissions should I use on our web directory:-

/usr/www/foobar

That will still allows the server to deliver the webpages and yet stop
people from other accounts from accessing it via chdir (telnet/ftp)?

We also hove home directoys that are not visible to the www called:-
/usr/home/foobar

Now my programs can access this directory too! So what sould I set the
file permissions too, again to stop other account holders with our ISP
from accessing it?

For the record my program traversed the enitire Disc that the web server
is running on. It was only denied access to a few directorys.

Also this mean that no logs are kept!! As my 2nd program called by the
first program, downloads the actual file to my browser and the only log
kept ofcousre is that someone ran the download program.

Is this what Goverments do to obtain without permission peoples files?:-

Say they are targetting http://www.foobar.co.uk, they can do this:-

1) Find out who the ISP is for http://www.foobar.co.uk
2) Buy a cgi account with the same ISP
3) Use a program like mine. (Will not give details publically)
4) Run the program and download the files including any within NON web
directorys.
--
Mark Worsdall
Home  :- shadowwebATworsdall.demon.co.uk
Any opinion given is my own personal belief...

2. (nis+ lookup): Error in accessing NIS+ cold start file

3. fix for HUGE SECURITY HOLE in syslog?

4. Installing Redhat 4.1 - Bus Error

5. Huge security hole?

6. Lockups when changing Psudo Terminals

7. Single-user mode -- huge security hole?

8. Solaris or Linus on SparcStation IPX

9. Huge security hole in elvis (Slackware)

10. Another Huge Security Hole!

11. Huge security holes in Microsoft FP98 server extensions for Apache

12. Closing suid root security holes forever

13. best-of-security mailing list (was: Solaris 2.5 Security Hole: local users can get root)