jsol@BU-IT.BU.EDU (03/18/89)
X11R3 has a nasty security bug that is being exploited here. We use our
workstations as user hosts as well as X machines, and when a user logs
in, he can do anything to your X system that he wants (dump the screen,
snarf windows, or anything that I can do from my console).
Also, the security system ("xhost bu-cs" for example), will let you
turn on a specific host for the purpose of running XTERM, but you can
not prevent some other user on that host from accessing your server
and doing any of the above sorts of things.
Is anyone going to fix this in the near future?
--jsolrws@EXPO.LCS.MIT.EDU (Bob Scheifler) (03/18/89)
Is anyone going to fix this in the near future? Depends on how you define "fix". We (X Consortium staff at MIT) have been running a "secure" environment for quite a while now, using a very simple authorization protocol. We have a more secure protocol on paper, as part of our work on an (X) terminal control protocol, that we expect to get implemented at some point. People at Project Athena (I'm told) have been working on integrating Kerberos. I have diffs in my mailbox from a company that has just done their own secure authorization protocol. The hitch, of course, is that none of these are available to the general public right now (although our simple scheme has been available to members of the X Consortium for a while now). It is currently unlikely that MIT will make anything available until R4. (And then, there's this problem with distributing cryptographic stuff outside the US ...)
jsol@BU-IT.BU.EDU (03/18/89)
Is there anything we can do to alleviate the problem? I can't believe that we are going to have to live with the fact that our bight young students have devised a way to read our windows, dump them to disk, rearrange them, etc. etc. etc. That simply won't do. If there is no way to handle this, I am going to recommend to my superiors that we support Suntools and get out of the X situation entirely. --jsol
jsol@BU-IT.BU.EDU (03/18/89)
No, running X servers on the same machine will not solve the problem. Anyone can log into your machine (who has an account on the server) and rape and pillage as much as they like. --jsol
bking@UF.MSC.UMN.EDU ("Bill King") (03/18/89)
> From: jsol@bu-it.bu.edu > > Is there anything we can do to alleviate the problem? ... > If there is no way to handle this, I am going to recommend to my superiors > that we support Suntools and get out of the X situation entirely. > --jsol It should be pointed out that Suntools does not solve the security problem, it avoids it. If you are willing to limit yourself to running all X clients on the same machine as the X server there is no security hole. No one said it would be easy. Bill King bking@uf.msc.umn.edu
rlk@THINK.COM (Robert L. Krawitz) (03/19/89)
Well, you could turn off remote access to your workstation. You could even write a program to allow users to control outside access to your machine (access_on and access_off are what Athena calls their programs, I believe). ames >>>>>>>>> | Robert Krawitz <rlk@think.com> 245 First St. bloom-beacon > |think!rlk (postmaster) Cambridge, MA 02142 harvard >>>>>> . Thinking Machines Corp. (617)876-1111
ken@UF.MSC.UMN.EDU (03/19/89)
> Anyone can log into your machine (who has an account on the server) > and rape and pillage as much as they like. X certainly needs better security, and I look forward to it being part of the standard. But on another level, behaviour that you describe above should not be tolerated. If these are users on your own system, you probably know them personaly. Do we really need a security system to protect against friends like these? What will we do with a security system where we don't have to trust anyone? Trust no-one? I don't think we're going to solve this problem with software.... - Ken
janssen@titan.sw.mcc.com (Bill Janssen) (03/20/89)
It seems that "jsol" has trouble with users who have accounts on his machine. There is really no Unix-y answer to this. What I think he's looking for is a system like xhost that will allow one to specify a list of uids that can connect to the server. But I suppose you can't get the uid of the client process from a network stream... Bill
schwartz@shire.cs.psu.edu (Scott Schwartz) (03/20/89)
In article <2144@titan.sw.mcc.com>, janssen@titan (Bill Janssen) writes: >It seems that "jsol" has trouble with users who have accounts on his machine. >There is really no Unix-y answer to this. What I think he's looking for >is a system like xhost that will allow one to specify a list of uids that >can connect to the server. But I suppose you can't get the uid of the client >process from a network stream... And over the network, a uid wouldn't have the same semantics as a local one, in general. However, in the (berkeley) unix domain, you can do the following: have the user creat a file, mode 000. Then use sendmsg to pass the file descriptor to the server. The server can then do an fstat to see that the file is owned by the right person. -- Scott Schwartz <schwartz@shire.cs.psu.edu>
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (03/20/89)
Is there anything we can do to alleviate the problem?
You could convince BU to join the X Consortium; you could convince BU to
invoke corrective feedback on deviant behavior; you could convince BU to pay
someone to implement a solution. Since I have no real idea what your
environment is (e.g. whether you are also running product servers, have X
terminals, are running product applications, etc.) and what level of security
you want, it's rather difficult to say what will alleviate the problem.
If there is no way to handle this, I am going to recommend to my superiors
that we support Suntools and get out of the X situation entirely.
This situtation has existed since the beginning of (X) time; your students are
suddenly catching on (I thought they'd be better than that :-), and you're
suddenly in a do-or-die situation?rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (03/20/89)
Is there anything we can do to alleviate the problem? At a Consortium security meeting just after the X Conference, the issue of releasing our code to the public was discussed, and the feeling at that time was that it was premature to do so. There will be an Advisory meeting of the Consortium in mid-April, and I will raise the subject again, but I make no promises as to the outcome.
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (03/20/89)
Any chance we (xpert) could get a short description from you of the
simple security scheme you are running at MIT?
In broad terms, it's this: xdm and the server find a way to share a secret
(e.g. through data in a file readable only by root). When the user logs in,
xdm makes some form of that secret available to the user (e.g. through data in
a file readable only by that user). XOpenDisplay is modified to know where to
find this information, and uses it to prove to the server that it knows the
secret. The server only accepts connections from clients that know the secret.geoff@desint.UUCP (Geoff Kuenning) (03/21/89)
In article <8903172201.AA16819@EXPIRE.LCS.MIT.EDU> rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes: > (And then, there's this problem with distributing > cryptographic stuff outside the US ...) Not really. The "problem" is that the folks in the Reagan-now-Bush administration, having never read any Heinlein, foolishly think that the U.S. Government can stop the spread of cryptographic technology simply by applying their heavy hands to U.S. researchers. The solution, which is as simple as the minds of the bureaucrats, is to publish the requisite algorithms without the "sensitive" software, but with a vague and general description of what that supposedly unique-to-the-special-capabilities-of-the-USA software does. Pretty soon, somebody outside the U.S. (frequently an Australian) will post public-domain software which achieves the same effect; we then pick it up in the U.S. and everybody is happy. -- Geoff Kuenning geoff@ITcorp.com uunet!desint!geoff
dwm@ihlpf.ATT.COM (Meeks) (03/22/89)
> and rape and pillage as much as they like.
-------------
While this is true, you can always NOT allow them to login on your
system by removing their passwd entry. Thus, you have a security
measure. Why you can even lock your machine up in a vault and work out
of it and get a pretty good level of security.
Basically, my opinion, is that security belongs with the workstation
level and not with the windowing system level. Even if the window
system had some kind of security, if your frame buffer was open to the
world, you would be too!
cheers, --dwmstpeters@dawn.UUCP (03/22/89)
>> (And then, there's this problem with distributing >> cryptographic stuff outside the US ...) >Not really. The "problem" is that the folks in the Reagan-now-Bush >administration ... foolishly think that >the U.S. Government can stop the spread of cryptographic technology Reagan didn't invent this problem. There were other fools aplenty before him. Also, don't think the only technology impacted is cryptography. >soon, somebody outside the U.S. (frequently an Australian) will post >public-domain software which achieves the same effect; we then pick it >up in the U.S. and everybody is happy. Or a Canadian. But don't think that just because it's PD and you got it from abroad that you can distribute it abroad. The export cops are simply not rational and are bigger than you are. Please be careful. -- Dick St.Peters GE Corporate R&D, Schenectady, NY stpeters@ge-crd.arpa uunet!steinmetz!stpeters GE would charge for opinions if they could find them. These are mine.
jmd@ursa.UUCP (Josh Diamond) (03/22/89)
In article <8903172239.AA00594@buit5.bu.edu> jsol@BU-IT.BU.EDU writes: >Is there anything we can do to alleviate the problem? At this point in time, not much, other than using xhost to turn off all access to the display (including from the local host). The security hole becomes smaller if you only xhost + a host long enough to bring up the window, and then xhost - it again once the widow is up. This seems to work well for me. > I can't believe that >we are going to have to live with the fact that our bight young students >have devised a way to read our windows, dump them to disk, rearrange them, >etc. etc. etc. That simply won't do. > >If there is no way to handle this, I am going to recommend to my superiors >that we support Suntools and get out of the X situation entirely. >--jsol Are you aware that under SunTools the same can be done? All you need to figure out the the proper /dev/win devices to sepcify. One you've done that, it is trivial. For instance, I have a 10 line shell script which will raise every terminal window on the screen, making it visible even if lockscreen is running... -- Josh Diamond {philabs.phillips.com, sun.com}!gotham!ursa!jmd ...!{sun, philabs, pyrnj}!gotham!ursa!jmd We're on an express elevator to hell -- jmd%ursa%gotham@philabs.phillips.com GOING DOWN!! jmd%ursa%gotham@sun.com
treese@crltrx.crl.dec.com (Win Treese) (03/24/89)
In article <8903211848.AA07020@dawn.steinmetz.Ge.Com> stpeters@dawn.UUCP writes: >>> (And then, there's this problem with distributing >>> cryptographic stuff outside the US ...) > >>Not really. The "problem" is that the folks in the Reagan-now-Bush >>administration ... foolishly think that >>the U.S. Government can stop the spread of cryptographic technology > >Reagan didn't invent this problem. There were other fools aplenty >before him. Also, don't think the only technology impacted is >cryptography. Well, the situation turns out to be rather more complicated than it should be. The algorithm specification for the Data Encryption Standard (DES) was published some years ago by the NBS (now NIST). Anyone can get a copy and implement the software -- takes a few hours for a working, though slow, implementation. The resulting software is not exportable. In fact, several DES packages have been implemented outside the US, including one from Finland that was recently announced on USENET. But that isn't sufficient, since even that can't be exported from the US to another country. (In other words, if someone in Europe gives me a DES library, I can't give it back.) There are many lawyers who get paid to argue about this. And Bob's original statement is still true. Win Treese Cambridge Research Lab treese@crl.dec.com Digital Equipment Corp.
jbw@bucsb.UUCP (jbw) (03/25/89)
In article <848@share.ursa.UUCP> jmd@share.UUCP (Josh Diamond) writes: >In article <8903172239.AA00594@buit5.bu.edu> jsol@BU-IT.BU.EDU writes: >>Is there anything we can do to alleviate the problem? > > At this point in time, not much, other than using xhost to turn off >all access to the display (including from the local host). The security >hole becomes smaller if you only xhost + a host long enough to bring up the >window, and then xhost - it again once the widow is up. This seems to work >well for me. Unfortunately, turning off local access to the server with xhost will prevent any new connections from being accepted, including from xhost. Thus, once taken away, the ability to run local X clients can not be restored. However, turning off local access (to other users) is what is needed. These workstations are being used as multiuser machines. In addition to the user on the console, people who need to work on a Sun architecture log in remotely. The actual setup is this: any login attempt to the server from the campus network is rerouted to one of the workstations. The belief is that better performance will be achieved by keeping interactive users off the file server. It can be interesting when 3 or 4 people are running GNU Emacs on a Sun 3/50 workstation. Interactive response on the console tends to be a little slow ... -- Joe Wells INTERNET: jbw%bucsf.bu.edu@bu-it.bu.edu IP: [128.197.10.201] UUCP: ...!harvard!bu-cs!bucsf!jbw