marco@email.ncsc.navy.mil (Barbarisi) (05/03/91)
I am not a Wizard, but I sometimes play one at work. Far be it from
me to throw water on an entertaining flame war, but there is an obvious
fix to the problem with "write" that you all have overlooked. Namely,
Mr. or Ms. Root (whom I assume is the SysAdmin) logs on and does this:
rm /bin/write
There. No more games with write. If someone squawks about the loss of this
feature, tell them to use sendmail or, dare I say it,......the phone!
There is also an alternative to "write" called "talk", which appears to
be far less susceptable to abuse. I believe it comes with modern
flavors of BSD.
Marco C. Barbarisi
marco@email.ncsc.navy.mil
"The truth is made up of little particulars which
seem ridiculous by themselves." - Jack Crabbgwyn@smoke.brl.mil (Doug Gwyn) (05/04/91)
In article <26758@adm.brl.mil> marco@email.ncsc.navy.mil (Barbarisi) writes: > rm /bin/write But the problem is not with "write" as such (it's so simple, how could it be?), but with the properties of terminal devices on most UNIXes.
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (05/08/91)
In article <26758@adm.brl.mil> marco@email.ncsc.navy.mil (Barbarisi) writes: > rm /bin/write Another plausible idea along the same lines is to rm -rf / ... I just put together a simple backwards-compatible write system synchronizing through BSD's UNIX-domain sockets rather than through ttys. There's a privileged server and a privileged client to set up secure communication, but everything else---how write looks for ttys, writing itself, the write daemon that produces output---is under user control. Expert users can freely substitute their own write, ucommwrite, and ucommwrited front-ends and back-ends, so the Multics hands should be satisfied. In the package I have a patch to 4.3 ntalk to send messages through write rather than the tty; a ``biffmail'' that you can stick in .forward instead of depending on comsat/biff; simple clones of mesg and write. To address Jef's disgust for new features, I made sure that you could retain backwards compatibility by setting a few environment variables. The new mesg n does not turn off writes in progress, but as any write to a user involves a process run by that user, appropriate kills will turn off writes. I do not know if these changes cover all the cases in which user applications need ttys to be in the filesystem. If they do, then a vendor could solve the tty security problems (though not the denial-of-service attacks) by simply making /dev/tty* exclusive-open like /dev/pty*. (The denial-of-service problem would be a lot less important if more applications did random pseudo-tty searching like pty. It can only really be solved, though, by protecting the files and making a user pay one process or utmp entry per tty wasted.) This is really easy to implement---it's almost like a permanent TIOCEXCL, which does apply to /dev/tty btw---but would require some work in each tty-allocating program. Back to write: Any volunteer beta testers? Please don't respond just because you're trying to find a better mousetrap or tighten up security. The package will be available soon enough. What I'm looking for are people who have some experience with various message systems, may want to contribute extra front ends or back ends, know exactly what compatibility users depend on, and can test the code on different BSD machines. I'm also looking for a brave soul to do a System V port, but this isn't immediately necessary (I do have some fifo-based client-server stuff lying around somewhere). > There is also an alternative to "write" called "talk", which appears to > be far less susceptable to abuse. I believe it comes with modern > flavors of BSD. talk is, in fact, completely insecure. (Doesn't ``hunt'' forge talk messages to everyone on a mailing list?) You can make BSD 4.3 ntalk support RFC 931 with the patches in pub/hier/inet/rfc931/talk* on stealth.acf.nyu.edu, but that only gives you authenticated usernames if the other side of the connection has an RFC 931 server. This has very little to do with tty security in any case. ---Dan
protin@pica.army.mil (Arthur W. Protin Jr.) (05/13/91)
Folk,
I am getting very tired of the foolishness, personal attacks, and
(seeming) evilness going on in this thread on tty security. Dan
posted a warning about a pretty serious security hole and more importantly
about the indifference vendors have about fixing it. He threatened/promised
to release a complete break-and-enter kit far enough into the future that
any viable vendor could act to protect their products. He even included
a step-by-step recipe for closing the hole.
Then comes the demands for the details to be released now. With the
exception of Keith Muller's postings, and those supporting Dan's position,
the majority of postings in this thread have been nonsense or
maliciousness. One poster who complained bitterly that Dan would not
give him the dirt turned out to be from a vendor that, according to the
poster, makes a unix variant that includes none of the problem code.
Why should that poster need the code, except for malicious purposes?
THE CODE THAT DAN IS WITH HOLDING IS THE CODE THAT EXPLOITS THE
SECURITY BUG. It is not needed to fix the code. It is useful for
testing the fixes.
Thus, I find the following posting to be logically flawed:
> System administrators are notably busy all the time, whereas idle
> hackers usually (by definition) have a great deal of idle time.
> Who do you suppose is going to be able to react better to a few
> hints, an overworked system administrator or some eager hacker?
System administrators don't need to deal with the hints! Follow
the recipe. Leave the hints and/or other dealings with Dan to the
systems programmers who commit to fixing the problem completely
(for at least a significant set of machines). If you can not work
from his plan, you will not be able to anything more with the details
except exploit the bug!
Other than following Dan's step-by-step repair proceedure, SA's
can start to pressure their suppliers to fix or commit to fix the
bug.
As for the suggestion that undergraduate students could help
solve the problem, Dan has already given them an assignment. In
a year and a half, take the break-and-enter kit and test every
system within reach. The dozens of machines here will only get
fixed when the vendor supplies us with good code. What makes
anybody think that there is a shortage of technical fixes? The
BIGGEST problem is BUREAUCRACY and INDIFFERENCE at the vendors.
We need a few good law suits or contract penalty clauses to motivate
them.
Thank you, I just had to get that of my chest.
Arthur Protin
Arthur Protin <protin@pica.army.mil>
These are my personal views and do not reflect those of my boss
or this installation.dave@jato.jpl.nasa.gov (Dave Hayes) (05/14/91)
protin@pica.army.mil (Arthur W. Protin Jr.) writes: > I am getting very tired of the foolishness, personal attacks, and >(seeming) evilness going on in this thread on tty security. Yes, and I am getting tired of the lack of cooperation and mistrust going on in this community. It still exists, and I'll still complain about it but that ain't goin t'make it go away...dammit. 8) > THE CODE THAT DAN IS WITH HOLDING IS THE CODE THAT EXPLOITS THE >SECURITY BUG. It is not needed to fix the code. It is useful for >testing the fixes. It is useful indeed. My point (and I don't know who else agrees with me) is that not only is this code needed to assert the validity of any said fixes, but the code (or pseudo code) is needed to understand the hole. A logical case can be made for security holes to be exposed; good security is not based upon obscurity. >System administrators don't need to deal with the hints! Follow >the recipe. Do you trust someone who doesn't trust you? Please answer honestly, now. Personally, and professionally, I do not. I find it extremely difficult to trust someone else's fixes when they not only distrust me, but I have little or no understanding of exactly what needs to be fixed and why. >(for at least a significant set of machines). If you can not work >from his plan, you will not be able to anything more with the details >except exploit the bug! I disagree completely. If you have the details, you can eventually provide fixes...assuming competance. > Other than following Dan's step-by-step repair proceedure, SA's >can start to pressure their suppliers to fix or commit to fix the >bug. Give me a break, here. How many times has that failed? >Thank you, I just had to get that of my chest. You're welcome. Please acknowledge that I'd like to do the same. -- Dave Hayes - Network & Communications Engineering - JPL / NASA - Pasadena CA dave@elxr.jpl.nasa.gov dave@jato.jpl.nasa.gov ames!elroy!dxh He who has self-conceit in his head - Do not imagine that he will ever hear the truth.
protin@pica.army.mil (Arthur W. Protin Jr.) (05/15/91)
Greg,
I am sorry to have say this but you are wrong when you say:
>> THE CODE THAT DAN IS WITH HOLDING IS THE CODE THAT EXPLOITS THE
>>SECURITY BUG. It is not needed to fix the code.
>
> It is needed if you're not bright enough to figure out what the bug is.
If you are not "bright enough to figure out what the bug is",
then you can do any of these four things:
1) apply the fixes that Dan provided;
2) start the flood of users requesting that their vendors
fix the bug;
3) ignore it all and hope it goes away;
4) carry on like spoiled children and demand that Dan give you
code that you are not bright enough to understand anyhow!
If you cannot figure out what the problem is from all that has already
been said, you will not fare much better with the code to exploit
the bug (unless your goal is to exploit the goal).
If you are not bright enough to figure how what the bug is by now,
what makes you think you are bright enought to find an equally good
alternative to Dan's formula?
If you can can not follow Dan's proof that his fixes close the hole,
then you really should turn this problem over to some one qualified
to deal with it and you will have to be able to trust them because
you will not be able to second guess them technically.
Understand that when Dan does publish the code he has withheld,
no one who had to wait for that code to fix the problem will be
able to fix the problem before the crackers have run through
their systems.
Those who want the code published now want the affected systems
violated now.
thank you,
Art Protin
Arthur Protin <protin@pica.army.mil>
These are my personal views and do not reflect those of my boss
or this installation.protin@pica.army.mil (Arthur W. Protin Jr.) (05/15/91)
Folks,
I cc'ed this mail-list with my response to Greg Lindahl
<gl8f@astsun.astro.virginia.edu> because I thought that the
response was applicable to more than just his rantings. I
have two more of his messages, quoted here in full, and again
I hope to answer many of you with one reply. (But I won't bother
to address him specifically.)
>In article <26893@adm.brl.mil> you write:
>>Greg,
>> I am sorry to have say this but you are wrong when you say:
>
> Responding to email in public? Newbie. I should have guessed from your
> security-through-obscurity orientation.
No, I am not a newbie. I felt that my response was directed to more
than just you. "security-through-obscurity" is a poor position that
regretably we sometimes find ourselves in when products lack quality,
assuming that we are doing anything of any importance. Unimportant
things need little or no security, important things need the best
security available, and it is truely shameful when that is only
"security-through-obscurity".
(End of first message)
> Dan provided a patch file? Funny, it doesn't seem to have gone
> anywhere else than at your site.
The only "patch file" I know of for this problem is not a patch file
but a multi-step recipe for curing the problem. And Dan generously
posted that recipe for all of us to benefit from.
> Other than that, I still find your
> assumption that everyone is evil to be disgusting. Must be fun when
> you know enough to condemn everyone else as evil crackers despite
> knowing nothing about them.
I don't assume anyone is evil, let alone that every one is. I do assume
that there exist evil people, but the only way of determining if some one
is evil is by what they do. I do think that it is reasonable and proper
to be suspicious of people who can not understand the technical aspects
of this discussion but demand to be given a purely offensive weapon.
Dan's secret code is only for attacking systems!
I guess the shoe fits too well, or why would some of you carry on so.
This goes for anyone who is offended by what I have said. I
did not accuse anyone of wrong doing or bad intent. I said that
there is no good reason for Dan's weapon to be released early.
If anyone feels that this implicates them it is only because they
know themselves too well.
I stand by what I said. Judge me by my words for I will surely judge
you by yours.
respectfully yours,
Arthur Protin
Arthur Protin <protin@pica.army.mil>
These are my personal views and do not reflect those of my boss
or this installation.jim@segue.segue.com (Jim Balter) (05/18/91)
In article <1991May13.223942.21459@jato.jpl.nasa.gov> dave@jato.jpl.nasa.gov writes: >It is useful indeed. My point (and I don't know who else agrees with >me) is that not only is this code needed to assert the validity of >any said fixes, As Dijkstra has pointed out, testing can only demonstrate the presense of bugs, not their absense. >but the code (or pseudo code) is needed to understand >the hole. Since you haven't seen it, how do you know? In fact, since there are people who understand the holes but haven't seen the break code, your statement is counterfactual. >A logical case can be made for security holes to be exposed; >good security is not based upon obscurity. The holes have been exposed. You may disagree, but that gives you no justification for slinging personal attacks (not that you did in this note; a welcome change from your previous ad hominem postings). >Do you trust someone who doesn't trust you? Please answer honestly, >now. Personally, and professionally, I do not. In _The Hunting of the Snark_, "the bowsprit got mixed with the rudder sometimes", because the Bellman decided that, if no one was to speak to the Helmsman, then the Helmsman was to speak to no one. Your statement makes about as much sense. Very few people who don't trust me distrust me *personally* (perhaps it is different for you). When someone locks the door, it is because they know there are thieves, not because they expect me personally to steal something. I have no more reason to distrust people who lock doors than people who don't. In fact, people who don't are careless and are less to be trusted. Trust is an operational issue more than a moral issue. >I find it extremely difficult to trust someone else's fixes when they >not only distrust me, This is like people who think there shouldn't be speed limits because they don't speed and feel insulted by the presense of the laws. Their problem is egocentrism and an underdeveloped abstractual facility. If there is reason to think that there is anyone who is untrustworthy, then only those *known* to be trustworthy will be trusted. If you don't understand this concept, get a logic text and look up "free variable". >but I have little or no understanding of exactly >what needs to be fixed and why. When you get the upgrade from your vendor, are you really going to demand the source and its history so that you can understand exactly what was fixed and why? If we all demanded to know exactly how everything around us works and why, we wouldn't get anything done. It is far better to give people specific tasks and to put QC and QA mechanisms in place than to try to do everything ourselves. >>(for at least a significant set of machines). If you can not work >>from his plan, you will not be able to anything more with the details >>except exploit the bug! > >I disagree completely. If you have the details, you can eventually >provide fixes...assuming competance. Assuming competence is assuming a lot, here. Anyway, the details are in the system code and in the design concepts that have been discussed, not in the code that demonstrates a problem. This whole concept of "providing fixes" rather than doing design has a lot to do with the current cost of software technology. > He who has self-conceit in his head - > Do not imagine that he will ever hear the truth. Indeed.