My Broadcast
j...@violet.berkeley.edu.uucp
the net two days ago. I have since received 743 messages and have
replied to every one (either with a form letter, or more personally
when questions were asked). The intention behind this effort was to
show that I wasn't interested in doing what I did maliciously or in
hiding out afterwards and avoiding the repercussions. One of the
people who received my message was Dennis Perry, the Inspector General
of the ARPAnet (in the Pentagon), and he wasn't exactly pleased.
(I hear his Interleaf windows got scribbled on)
So now everyone is asking: "Who is this Jordan Hubbard, and why is he on my
screen??"
I will attempt to explain.
I head a small group here at Berkeley called the "Distributed Unix Group".
What that essentially means is that I come up with Unix distribution software
for workstations on campus. Part of this job entails seeing where some of
the novice administrators we're creating will hang themselves, and hopefully
prevent them from doing so. Yesterday, I finally got around to looking
at the "broadcast" group in /etc/netgroup which was set to "(,,)". It
was obvious that this was set up for rwall to use, so I read the documentation
on "netgroup" and "rwall". A section of the netgroup man page said:
...
Any of three fields can be empty, in which case it signifies
a wild card. Thus
universal (,,)
defines a group to which everyone belongs. Field names that ...
...
Now "everyone" here is pretty ambiguous. Reading a bit further down, one
sees discussion on yellow-pages domains and might be led to believe that
"everyone" was everyone in your domain. I know that rwall uses point-to-point
RPC connections, so I didn't feel that this was what they meant, just that
it seemed to be the implication.
Reading the rwall man page turned up nothing about "broadcasts". It doesn't
even specify the communications method used. One might infer that rwall
did indeed use actual broadcast packets.
Failing to find anything that might suggest that rwall would do anything
nasty beyond the bounds of the current domain (or at least up to the IMP),
I tried it. I knew that rwall takes awhile to do its stuff, so I left
it running and went back to my office. I assumed that anyone who got my
message would let me know.. Boy, was I right about that!
After the first few mail messages arrived from Purdue and Utexas, I begin
to understand what was really going on and killed the rwall. I mean, how
often do you expect to run something on your machine and have people
from Wisconsin start getting the results of it on their screens?
All of this has raised some interesting points and problems.
1. Rwall will walk through your entire hosts file and blare at anyone
and everyone if you use the (,,) wildcard group. Whether this is a bug
or a feature, I don't know.
2. Since rwall is an RPC service, and RPC doesn't seem to give a damn
who you are as long as you're root (which is trivial to be, on a work-
station), I have to wonder what other RPC services are open holes. We've
managed to do some interesting, unauthorized, things with the YP service
here at Berkeley, I wonder what the implications of this are.
3. Having a group called "broadcast" in your netgroup file (which is how
it comes from sun) is just begging for some novice admin (or operator
with root) to use it in the mistaken belief that he/she is getting to
all the users. I am really surprised (as are many others) that this has
taken this long to happen.
4. Killing rwall is not going to solve the problem. Any fool can write
rwall, and just about any fool can get root priviledge on a Sun workstation.
It seems that the place to fix the problem is on the receiving ends. The
only other alternative would be to tighten up all the IMP gateways to
forward packets only from "trusted" hosts. I don't like that at all,
from a standpoint of reduced convenience and productivity. Also, since
many places are adding hosts at a phenominal rate (ourselves especially),
it would be hard to keep such a database up to date. Many perfectly well-
behaved people would suffer for the potential sins of a few.
I certainly don't intend to do this again, but I'm very curious as to
what will happen as a result. A lot of people got wall'd, and I would think
that they would be annoyed that their machine would let someone from the
opposite side of the continent do such a thing!
Jordan Hubbard
j...@violet.berkeley.edu
(ucbvax!jkh)
Computer Facilities & Communications.
U.C. Berkeley
LY...@a.isi.edu.uucp
the "system". Now, if you could figure out a way to encourage
them to get plugged. I remember years ago being annoyed at the
loose security in the Tenex operating system that was prevalent
on the early Arpanet. I couldn't get the wizards at BBN to "fix"
the problems by the "usual" means. So, one day I took advantage of
the holes and, across the net, all by myself with no confederates,
obtained the password of the wizard of all wizards and sent it to him
in a one word mail message. No other communication was necessary.
He plugged the holes as fast as his fingers could type. I was a "good
guy" and he knew it, but it took an actual event to drive the point home
it wouldn't be too long before someone else would figure out the
method i used an dperhaps not be so benign.
Can you think of a similar thing to do? Or have you already done it?
(I think not because what you are pointing out is going to take
lots of thinking to solve. But, it has to start somewhere.
Dan
-------
Rudy....@h.cs.cmu.edu.uucp
Encouraging people to find holes and then use them to make the local system
programmers work on them is wrong. It is like encouraging people to find out
if their neighbors lock their door during the day so they will. Do you really
want that or do you want the theives to be caught? I want the theives to be
caught and the ability to leave my door open. I don't want to fear my
neighborhood or my users.
I could spend many man years working on Unix security alone. The same is
TRUE with TOPS-20. The worst is when you fix a security problem and some
yo-yo finds out about it and then attacks some other remote site. The remote
site gets pissed and says it can not afford to fix it....would you please
deal with the yo-yo.
-RUdy
use...@ucbvax.uucp
I'm afraid you (and I, and any of the other old-timers who
care about security) are banging your head against a brick wall.
The philsophy behind Unix largely seems quite reminiscent of the
old ITS philsophy of "security through obscurity;" we must
entrust our systems and data to a open-ended set of youthful
hackers (the current term is "gurus") who have mastered the
arcane knowledge.
The problem is further exacerbated by the multitude of slimy
vendors who sell Unix boxes without sources and without an
efficient means of dealing with security problems as they
develop.
I don't see any relief, however. There are a lot of
politics involved here. Some individuals would rather muzzle
knowledge of Unix security problems and their fixes than see them
fixed. I feel it is *criminal* to have this attitude on the DDN,
since our national security in wartime might ultimately depend
upon it. If there is such a breach, those individuals will be
better off if the Russians win the war, because if not there will
be a Court of Inquiry to answer...
It may be necessary to take matters into our own hands, as
you did once before. I am seriously considering offering a cash
reward for the first discoverer of a Unix security bug, provided
that the bug is thoroughly documented (with both cause and fix).
There would be a sliding cash scale based on how devastating the
bug is and how many vendors' systems it affects. My intention
would be to propagate the knowledge as widely as possible with
the express intension of getting these bugs FIXED everywhere.
Knowledge is power, and it properly belongs in the hands of
system administrators and system programmers. It should NOT be
the exclusive province of "gurus" who have a vested interest in
keeping such details secret.
-- Mark --
PS: Crispin's definition of a "somewhat secure operating system":
A "somewhat secure operating system" is one that, given an
intelligent system management that does not commit a blunder that
compromises security, would withstand an attack by one of its
architects for at least an hour.
Crispin's definition of a "moderately secure operating system": a
"moderately secure operating system" is one that would withstand
an attack by one of its architects for at least an hour even if
the management of the system are total idiots who make every
mistake in the book.
-------
PE...@vax.darpa.mil.uucp
that what happened was allowed to happen.
By the way, I am the program manager of the Arpanet in the Information
Science and Technology Office of DARPA, located in Roslin (Arlington), not
the Pentagon.
I would like suggestions as to what you, or anyone else, think should be
done to prevent such occurances in the furture. There are many drastic
choices one could make. Is there a reasonable one? Perhaps some one
from Sun could volunteer what there action will be in light of this
revelation. I certainly hope that the community can come up with a good
solution, because I know that when the problem gets solved from the top
the solutions will reflect their concerns.
Think about this situation and I think you will all agree that this is
a serious problem that could cripple the Arpanet and anyother net that
lets things like this happen without control.
dennis
-------
j...@violet.berkeley.edu.uucp
Sorry about the mixup on your location and position within DARPA. I got
the news of your call to Richard Olson second hand, and I guess details
got muddled along the way. I think the best solution to this problem (and
other problems of this nature) is to tighten up the receiving ends. Assuming
that the network is basically hostile seems safer than assuming that it's
benign when deciding which services to offer.
I don't know what Sun has in mind for Secure RPC, or whether they will move
the release date for 4.0 (which presumably incorporates these features)
closer, but I will be changing rwalld here at Berkeley to use a new YP
database containing a list of "trusted" hosts. If it's possible to change
RPC itself, without massive performance degradation, I may do that as well.
My primary concern is that people understand where and why unix/network
security holes exist. I've gotten a few messages from people saying that
they would consider it a bug if rwall *didn't* perform in this manner, and
that hampering their ability to communicate with the rest of the network
would be against the spirit of all it stands for. There is, of course, the
opposite camp which feels that IMP's should only forward packets from hosts
registered with the NIC. I think that either point of view has its pros and
cons, but that it should be up to the users to make a choice. If they wish
to expose themselves to potential annoyance in exchange for being able to,
uh, communicate more freely, then so be it. If the opposite is true, then
they can take appropriate action. At least an informed choice will have been
made.
Yours for a secure, but usable, network.
Jordan Hubbard
PAL...@sushi.stanford.edu.uucp
discussion into a diatribe against Unix. If there's a point to his
flame, however, it escapes me. It does bear an entertaining
resemblance to some conspiracy theories I've heard, I must admit.
Crispin's definition of a "somewhat secure operating system":
A "somewhat secure operating system" is one that, given an
intelligent system management that does not commit a blunder that
compromises security, would withstand an attack by one of its
architects for at least an hour.
"You stupid fool, who told you to turn the damn thing on?!?"
Crispin's definition of a "moderately secure operating system": a
"moderately secure operating system" is one that would withstand
an attack by one of its architects for at least an hour even if
the management of the system are total idiots who make every
mistake in the book.
The first mistake in the book is to believe that the security of the
operating system implies the security of the data, or rather that the
system is an isolated entity which can be made "secure" independent of
its environment.
joe
-------
LY...@a.isi.edu.uucp
The example I gave was definitely in the "security" area and you
should note that the method used to get it fixed involved exactly
one "outside site", the site of the author of the operating system.
The example of the broadcast that went "astray" is more accurately
described as an "integrity" issue. With integrity one is concerned
that the "system/facility" stay alive and functional under both
normal use and many forms of abnormality. What we are learning
with some of the facilities for message sending is that our
"internet" is very highly connected and even can be considered
to be too highly connected for some forms of (even innocent)
misbehavior. How do we benefit from what we have learned thus far?
Dennis has suggested that one of the manufacturers fix some code
and/or defaults and/or procedures in its releases. I'm sure other
manufacturers can do likewise should they also exhibit the
same misfeatures in their offerings. But the big thing that we
need to understand is that we do not understand how to live
in these highly connected internets yet. Much more research needs
to happen in the area of intergroup interactions. And much more
tolerance needs to be exhibited towards those who are probing
the edges of all this.
Dan
-------
rob...@spam.istc.sri.com.uucp
>> entrust our systems and data to a open-ended set of youthful
>> hackers (the current term is "gurus") who have mastered the
>> arcane knowledge.
Only because these 'youthful hackers' are the only ones
willing (or having the time) to look for the problems
they discover.
>>
>> ....
>>
>> Knowledge is power, and it properly belongs in the hands of
>> system administrators and system programmers. It should NOT be
>> the exclusive province of "gurus" who have a vested interest in
>> keeping such details secret.
Mark,
I agree that system administators should have the know-how
to protect their systems. However I have not seen the
concerted effort of gurus to keep security problems
secret from the administors. Rather I have seen administrators
keeping such holes secret from the users, and then complaining
when the users discover and use them.
>>
>> -- Mark --
>>
>> PS: Crispin's definition of a "somewhat secure operating system":
>> A "somewhat secure operating system" is one that, given an
>> intelligent system management that does not commit a blunder that
>> compromises security, would withstand an attack by one of its
>> architects for at least an hour.
...except for the case where one has physical access to
the hardware.
Robert Allen,
rob...@spam.istc.sri.com
Disclaimer: I am not a guru, and I don't advocate breakins, but if a
feature is there (such as telnet port 25), and is used,
I think that the administrators should share responsibility
with the user for any problems that result.
Rudy....@h.cs.cmu.edu.uucp
My two areas of frustration are abuse of mail resources and abuse of
network resources. Each year people, send mail to as many mailing lists
as they can asking to be put on them instead of the request list. Several
times a year, someone configures a mailer to cause a huge loop that causes
many megabytes of mail messages to be sent to many people on many different
systems. At least once year, I see a piece of code written under the
assumption that the network is a quiet high-speed high-relaibility
medium -- the code retransmits quickly and has very short timeouts.
Lastly, we have several systems that take a list of hosts and broadcast
messages to them to update databases. This is in the similiar flavor
of grapevine. It is not unlikely that some company could set up a
system and want a broadcast facility similiar to the one that started
up this discussion. At this point, it is no longer a security problem
but a feature.
If I had concrete improvements that I could implement, I would act on them.
Maybe the system will change to charge for mail and to charge for network
access and usage. People would then be more responsive to their utilization
of those resources.
-Rudy
fau...@ic.berkeley.edu.uucp
If so, maybe it's better that there are well-known loopholes so that nobody
places too much faith in their system and makes use of techniques like
public-key encryption when it really matters. No matter how secure your
network and OS is, if you assume that it's ok to rely on their security alone
for very sensitive data, you'll get burned sooner or later. It's much
safer to assume the worst and take proper precautions.
Wayne
rob...@spam.istc.sri.com.uucp
>>
>> Encouraging people to find holes and then use them to make the local system
>> programmers work on them is wrong. It is like encouraging people to find out
>> if their neighbors lock their door during the day so they will. Do you really
>> want that or do you want the theives to be caught? I want the theives to be
>> caught and the ability to leave my door open. I don't want to fear my
>> neighborhood or my users.
While this doesn't deal directly with TCP-IP, it is a *very* important
consideration in the Internet in particular, and any network in general.
Often a so-called 'breakin' does not even require that a user maliciously
"try their neighbors doors" to see if they can gain restricted permissions
or access. Often curiosity alone is enough to cause problems. Example 1:
a first-time UNIX user was learning about the file system, and in particular
how to delete files. He was told that he could only delete files owned by
him, and by way of counterexample his mentor typed "rm /etc/passwd".
Surprise, /etc was writeable and the file was gone. Example two: the recent
rlogin breakins at Stanford. Example 3: Obviously if you have hardware
access to the transmission medium you can unintentionally wreak havoc merely
by using someone elses IP address.
I too would like to live in a word where I can leave my "door unlocked".
Unfortunately it doesn't take more than a very few nasty or ignorant persons
to cause problems. Due to the fact that computers have evolved in an
atmosphere of sharing (time sharing, memory sharing, src sharing..)
we have yet to realize the responsibilities and risks of trusting them too
much. I.e., there is a big difference between leaving your door
unlocked but closed, and spreading $20.00 bills on your front lawn.
In the case of J. Hubbards 'wall' to the Net, the problem was not
caused by a malicious person, but by simple curiosity.
At the recent TCP/IP Conference in Monterey CA, some discussion was
given to "network security". From the military standpoint they want
the ability to send data through a network, such that anyone who
captures the data won't be able to read or use it. While this may
be a prerequisite for the military, I don't think that 'normal' users
should expect that their Email be any more secure than their USMail.
The best method of keeping something secure on a network is to physically
seperate it. Or, do what I do, and don't put anything on the system
which you wouldn't read by someone else under the worst case scenario.
Fixing security 'features' is obviously important, and should be pursued.
Catching malicious persons doing damage is also extremely important. But
"catching the theives" is not the answer to a lack of network security.
If your network rolls out a red-carpet to someone then don't be surprised
if you find muddy footprints on it the next morning. I leave you with
two examples quoted from the January 1987 issue of the ACM Software
Engineering Notes...
"The computer security administrator at Roche ... had been
plagued by a hacker who auto-dialed the entire Roche phone
system in sequence. .... They laid a hacker trap on one of
the PC's and traced the call. Once the suspect was found,
it was even harder to get him arrested since he was in
New York, and Roched in New Jersey (which got the FBI involved).
The perp was brought into the police station and had the riot
act read to him... He was not charged -- because there wasn't
a **no-trespassing** sign on the hacker trap identifying the
system as private proberty of Roche."
" "Welcome to the ______ System" ... A Mass. financial firm
that had attempted to prosecute a hacker who had penetrated
their system. The defense lawyer argued that the system had
a greeting that welcomed people to the system, and that was
tantamount to welcoming someone intor your home. The judge
threw out the case, accepting the arguments of the defense.."
Robert Allen,
rob...@spam.istc.sri.com
b...@bu-cs.bu.edu.uucp
Mark Crispin --
I think your attack on UNIX is utterly unwarranted and devoid of
content. How you can compare it to ITS where everyone was effectively
a wheel is utterly beyond me.
UNIX exhibits no worse characteristics than other commonly used
systems. Even your beloved TOPS-20 had this charming feature of
unencrypted passwords so anyone gaining access to a priviliged
terminal for a few seconds could print every pwd on the system in
clear text with one command. Sure, that's fixed, but the fix came
recently, after DEC had dumped the product. We had to live with this
for years (and show me the local hack patches that "fixed" this and
I'll show you the local hack patches that fix any UNIX security flaw
you see.)
For the love of god Mark, Jordan broadcast a message to a lot of terminals.
That's it.
BFD, sure it could be annoying, but the originating site (and user,
although I admit that could be faked easily) was clearly printed and
easily (see etherfind for example) identified. To say your "systems
and data" were endangered by this broadcast is hyperbole, at best.
Can you condemn the entire UNIX operating system because a user was
able to SHOUT to a bunch of hosts he didn't own? Sounds flimsy to
me.
As to "muzzling" of unix security problems, there's an entire, active
mailing list on the internet devoted to nothing but discussing UNIX
security issues. What other operating system can claim this? (Ok,
these things are also freely discussed on some of the TOPS-20 lists,
no argument, but name another? I've seen this stuff specifically
stifled and people severely flamed on at least one other O/S's list.)
-Barry Shein, Boston University
P.S. One thing I do agree with Mark about is that without the sources
you might be a sitting duck. This is one major reason I discourage
people from buying VMS.
b...@bu-cs.bu.edu.uucp
From Dennis Perry:
>I would like suggestions as to what you, or anyone else, think should be
>done to prevent such occurances in the furture.
Solution:
Edit /etc/servers and remove the rwalld line. This will disable the
remote service. The local "write to all users" program, 'wall', can
still be used on any individual system. To shout to all systems in an
area either have the operators log in and run wall locally or execute
it via 'rsh system wall ..msg..' from a locally trusted site (as per
the rsh restrictions.) A command file could be created trivially which
simulated "rwall" to a selected set of sites:
#!/bin/sh
echo "Enter message to be sent to all systems (one line)"
echo -n 'MESSAGE: '
read msg
for i in host1 host2 etc...
do
rsh $i wall $msg
done
(I didn't test this, but I think the point is clear.)
This can be further enhanced by removing the rwall binary from your
systems, but if you don't support the daemon, you're not going to see
any broadcasts, so it's under your control. Done.
-Barry Shein, Boston University
PE...@vax.darpa.mil.uucp
found in the system. But at the same time, we don't want to have to
shut the thing down until such a fix can be made. Misuse of the system
get us all in a lot of trouble. The Arpanet has succeeded because of
the self policing community. If this type of potential for disruption
gets used by very many people, I guarentee that we all will not like the
solution or fix proposed.
dennis
-------
PE...@vax.darpa.mil.uucp
to start with, i.e. where we trust the users to implement the fix.
Ultimately, we have to build a network that will protect itself somehow.
Can I ask all you out there to implement such a scheme or any better one
that may come out of this discussion.
Thanks,
dennis
-------
PE...@vax.darpa.mil.uucp
issues of intergroup interaction. But, like any society where our
collective well being depends upon the behavior of others outside
our control, we need to be sensitive on how we explore the edges of these
interactions. I posit that this should take place in a controlled
experiment that maximizes the benefits and minimizes the disruptions.
After all, the Arpanet is still an 'experimental' network. Let's plan
our experiments, rather than just letting them happen.
dennis
-------
gal...@dewey.uucp
From: Robert Allen <rob...@spam.istc.sri.com>
I don't think that 'normal' users should expect that their
Email be any more secure than their USMail.
I don't buy this. Why should we restrict or constrain current technology
based on what we are used to? There is no reason that electronic mail can't
be more secure than USMail. Isn't it self-defeating to assume otherwise?
From: Rudy....@h.cs.cmu.edu
Encouraging people to find holes and then use them to make the
local system programmers work on them is wrong. It is like
encouraging people to find out if their neighbors lock their
door during the day so they will. Do you really want that or do
you want the theives to be caught? I want the theives to be
caught and the ability to leave my door open. I don't want to
fear my neighborhood or my users.
This analogy doesn't hold in the internet (small i intended). It is not your
neighbors you are worried about. You can live in a "friendly" network just
like you can live in a "friendly" neighborhood. The problem is, your friendly
network is a great deal "closer" to the unfriendly ones than your friendly
neighborhood is close to unfriendly ones.
Isn't this what Dan Lynch meant when he said:
From: Dan Lynch <LY...@a.isi.edu>
What we are learning with some of the facilities for message
sending is that our "internet" is very highly connected and
even can be considered to be too highly connected for some
forms of (even innocent) misbehavior. How do we benefit from
what we have learned thus far?
... But the big thing that we need to understand is that we do
not understand how to live in these highly connected internets
yet. Much more research needs to happen in the area of
intergroup interactions. And much more tolerance needs to be
exhibited towards those who are probing the edges of all this.
Jim
d...@sri-lewis.arpa.uucp
Just an interested bystander here,
Perhaps the fundemental difference in UNIX versus most other operating
system is that the basic user has to get so much more intimate with the
command set. In addition a goodly number of these users are writing software
that requires them to, at some point in time, have a hook or two into
the workings of the operating system.
Also one must remember that the abilities/capabilities of one to cross
mount entire file systems is a FEATURE, not a quirk.
Believe me, when the feds come crashing through your bedroom window
and sieze your equipment you will know you shouldn't have been doing
what you were doing.
TIA, (That Is All)
Don
N...@cornella.bitnet.uucp
>mailing list on the internet devoted to nothing but discussing UNIX
>security issues. What other operating system can claim this? (Ok,
>these things are also freely discussed on some of the TOPS-20 lists,
>no argument, but name another? I've seen this stuff specifically
>stifled and people severely flamed on at least one other O/S's list.)
The VM Group of the IBM user's group SHARE has a conferencing system
(VMSHARE) which has an on going discussion of security problems.
ah...@cc7.bbn.com.uucp
I would like to hear why Mark Crispin's second definition isn't
a more pratical approach to the security issue. If Unix is still vulnerable
after a decade of availability should we ever expect it to be safe? Why also
should we pick on Unix (except its a good subject to evoke flames)? My
years of experience in dealing with security indicates that data should
be encrypted whenever practical. Relying on software or system adminstrators
is folly.
Alan
m...@emptys.cc.umich.edu.uucp
I'm suprised about messages I receive where the intent
of the author is to raise my consciousness by making me angry.
What usually happens is this -- I get angry.
So is the case with the message from Mark Crispin.
The philsophy behind Unix largely seems quite reminiscent of the
... "security through obscurity;"
The only security is through obscurity. It is precisely the lack of
information which secures some system. As an example, consider publishing
the passwords of all the accounts on a system, or the private parts of
DES pair.
entrust our systems and data to a open-ended set of youthful
hackers (the current term is "gurus") who have mastered the
arcane knowledge.
I'm confused here about the term youthful hackers. Is youthful under 18?
under 25? under 35? under 45? I know of many excellent programmers
in all age groups. I also know malicious usage has no age range.
Mark, if you are a manager, have you had occassion to use the same talents
you are complaing about to solve some particular problem without getting
involved? Are you complaing about their knowledge or about your unwillingness
to learn what you need to know?
The problem is further exacerbated by the multitude of slimy
vendors who sell Unix boxes without sources and without an
efficient means of dealing with security problems as they
develop.
The focus seems to have changed. If the discussion was about Unix problems,
if the focus was about selection criterea for the people hired,
the focus is now on vendor problems?
Even so, I wasn't aware that lack of source was the key to the security
problems on Unix systems. I'm not aware of too many unix vendors who
are unwilling to share their code when they are reimbursed for their efforts.
I don't see any relief, however.
There are a lot of politics involved here.
<here? Where is here? Stanford? Sumex? California? USA?>
Some individuals would rather muzzle knowledge of
Unix security problems and their fixes than see them fixed.
This may be true. This may always be true.
I feel it is *criminal* to have this attitude on the DDN,
since our national security in wartime might ultimately depend
upon it. If there is such a breach, those individuals will be
better off if the Russians win the war, because if not there will
be a Court of Inquiry to answer...
Ah, after alot of though, I think I am beginning to understand what you
are trying to write. Are you assuming the sensitive machines on the DDN
to be Unix machines? And from there assuming they are unsecured?
I would think people using machines and needing particular levels of
security would be well aware of the issues, much more than you or I.
I have seen some of the specs to come out of the military for secure
system, and have felt very good about the militaries' own understanding
of its needs.
It may be necessary to take matters into our own hands, as
you did once before.
<focus? ranting?>
I am seriously considering offering a cash reward for the
first discoverer of a Unix security bug, provided that the
bug is thoroughly documented (with both cause and fix).
Now I am beginning to understand a bit more... so happends these kind of bugs
have been found before. In fact, bugs have been discovered. In fact,
information has been sent out, describing the problem, and the resolution.
There would be a sliding cash scale based on how devastating the
bug is and how many vendors' systems it affects.
<focus?>
My intention would be to propagate the knowledge as widely
as possible with the express intension of getting these bugs
FIXED everywhere.
If that is your intention, then the process you are suggesting for making
it happen is faulty. You are trying to get people to help you by making
them angry at you. This will not work.
Knowledge is power, and it properly belongs in the hands of
system administrators and system programmers. It should NOT be
the exclusive province of "gurus" who have a vested interest in
keeping such details secret.
Here I am very confused. Seems the people who are refered to as "gurus"
are the very best system programmers. All the "gurus" I have ever met
have many talents beyond programming; including leadership. Getting the
leadership required excellant interpersonnel skills. As mentioned above,
if this is not the case where you work, then the people responsible for
selecting appropriate individuals for their positions have made mistakes.
As for "in the hands of"; a case of analogy may make clear that this is
not necessarily the best way... I would guess the same was said to the
people making the atomic bomb; that they had the understanding the create
the bomb, but not the understanding to use it correctly. Defering the
responsibilty to the people who wanted it for "power" created an environment
where those people used the very technology only for "power".
I would say for you to focus on the knowledge itself, because for you,
the knowledge will not be power.
m...@emptys.cc.umich.edu.uucp
I'm suprised about messages I receive where the intent
of the author is to raise my consciousness by making me angry.
What usually happens is this -- I get angry.
So is the case with the message from Mark Crispin.
The philsophy behind Unix largely seems quite reminiscent of the
... "security through obscurity;"
The only security is through obscurity. It is precisely the lack of
information which secures some system. As an example, consider publishing
the passwords of all the accounts on a system, or the private parts of
DES pair.
entrust our systems and data to a open-ended set of youthful
hackers (the current term is "gurus") who have mastered the
arcane knowledge.
I'm confused here about the term youthful hackers. Is youthful under 18?
under 25? under 35? under 45? I know of many excellent programmers
in all age groups. I also know malicious usage has no age range.
Mark, if you are a manager, have you had occassion to use the same talents
you are complaing about to solve some particular problem without getting
involved? Are you complaing about their knowledge or about your unwillingness
to learn what you need to know?
The problem is further exacerbated by the multitude of slimy
vendors who sell Unix boxes without sources and without an
efficient means of dealing with security problems as they
develop.
The focus seems to have changed. If the discussion was about Unix problems,
if the focus was about selection criterea for the people hired,
the focus is now on vendor problems?
Even so, I wasn't aware that lack of source was the key to the security
problems on Unix systems. I'm not aware of too many unix vendors who
are unwilling to share their code when they are reimbursed for their efforts.
I don't see any relief, however.
There are a lot of politics involved here.
<here? Where is here? Stanford? Sumex? California? USA?>
Some individuals would rather muzzle knowledge of
Unix security problems and their fixes than see them fixed.
This may be true. This may always be true.
I feel it is *criminal* to have this attitude on the DDN,
since our national security in wartime might ultimately depend
upon it. If there is such a breach, those individuals will be
better off if the Russians win the war, because if not there will
be a Court of Inquiry to answer...
Ah, after alot of though, I think I am beginning to understand what you
are trying to write. Are you assuming the sensitive machines on the DDN
to be Unix machines? And from there assuming they are unsecured?
I would think people using machines and needing particular levels of
security would be well aware of the issues, much more than you or I.
I have seen some of the specs to come out of the military for secure
system, and have felt very good about the militaries' own understanding
of its needs.
It may be necessary to take matters into our own hands, as
you did once before.
<focus? ranting?>
I am seriously considering offering a cash reward for the
first discoverer of a Unix security bug, provided that the
bug is thoroughly documented (with both cause and fix).
Now I am beginning to understand a bit more... so happends these kind of bugs
have been found before. In fact, bugs have been discovered. In fact,
information has been sent out, describing the problem, and the resolution.
There would be a sliding cash scale based on how devastating the
bug is and how many vendors' systems it affects.
<focus?>
My intention would be to propagate the knowledge as widely
as possible with the express intension of getting these bugs
FIXED everywhere.
If that is your intention, then the process you are suggesting for making
it happen is faulty. You are trying to get people to help you by making
them angry at you. This will not work.
Knowledge is power, and it properly belongs in the hands of
system administrators and system programmers. It should NOT be
the exclusive province of "gurus" who have a vested interest in
keeping such details secret.
Here I am very confused. Seems the people who are refered to as "gurus"
MRC%...@sumex-aim.stanford.edu.uucp
In a sense your message is very reminiscent of the attitude of the
architects of MIT ITS. It is a useful attitude in certain environments;
it has been argued that the security/integrity consciousness of TOPS-20
and Multics hampered tools development (or limited it to system wizards)
compared to systems such as ITS, WAITS, and Unix. But this does not
mean that it is right for all environments. Even in an environment in
which rwalld is useful, it's important to have safeguards in place to
limit its range. In the present state of affairs, such safeguards are
either absent, not enabled, or inadequately documented.
Just as an example, why did Dennis Perry's system at DARPA accept a
rwall from a machine somewhere at Berkeley? Maybe Berkeley is doing such
time-critical research that breakthroughs must be announced by such
"network shouts", but I think it's much more likely that nobody at DARPA
even knew that such a facility existed or was running on their machine.
Think of what would happen if our IP gateways supported an IP address
of FF.FF.FF.FF (the famous and as-yet mythical "Godzilla-gram").
Fortunately, no gateway does. The same sort of sanity check needs to
be extended to higher-level protocols.
-- Mark --
PS: I could envision a security bug caused by the ability to broadcast
arbitrary characters to terminals on other systems. Are all the rwalld
implementations clever enough to filter out control characters? Also,
those of us who are old enough to know what "cookie bear" know that
broadcasting messages CAN effectively stop all work...
-------
MRC%...@sumex-aim.stanford.edu.uucp
I consider it a given that Unix will never be "safe" (although it can
be made a lot "safer"). The whole point of my message (or flames, if you
will) was to knock a hole into some of the complacency surrounding "standard"
software. The incident that started this entire discussion demonstrated an
instance in which a particular operating system lacked a sanity check.
It is my contention that certain (but not all) versions of this operating
system (Unix) have an endemic lack of such sanity checks. Since this operating
system is the primary operating system on the DDN it is crucial that these
oversights be corrected. Otherwise, as long as there are other operating systems
or crackers on the network there will be similar incidents.
If I didn't care, I'd keep my mouth shut.
-- Mark --
-------
preece%...@gswd-vms.arpa.uucp
From: "Alan R. Hill" <ah...@cc7.bbn.com>
> My years of experience in dealing with security indicates that data
> should be encrypted whenever practical. Relying on software or system
> adminstrators is folly.
Unless you're doing all your work on a trusted workstation, to which
only you have access, encryption isn't enough. The processor on which
the work is done has to encrypt and decrypt, meaning that the data
has to be floating around in plaintext form at some times. If your
software is ignoraably secure, then so is your transitory plaintext.
--
scott preece
gould/csd - urbana
uucp: ihnp4!uiucdcs!ccvaxa!preece
arpa: preece@gswd-vms
ah...@cc7.bbn.com.uucp
History indicates that "whistle blowing" is not generally appreciated
regardless of its well meaning intent. Unless DoD specifies requirements
for Unix use on the internet, I doubt that anything will change.
Although there are lots of security problems with Unix and its
network code, I thought I would relate my experience with this type of
problem. Many years ago I had responsibility for a Unix system that
was used by competing contractors and a government agency. My job was
to prevent importation of non-approved code that could compromise the
integrity of the system. I also had to keep the various groups from
digging into each others files. I modified the access code for the
network and the file system. It took me roughly 2 hours work and
I was able to restrict access by user and source location. I also logged
all access attempts good or bad. My point is that the effort to
dramatically improve control is not costly.
I suggest that this discussion is no longer useful to the
TCP-IP mailing list and can be continued off-line. I generally
approve of comments that will evoke an emotional response since they
will generate much more data than those that are more benign.
Alan
Rudy....@h.cs.cmu.edu.uucp
I read your message in response to Mark Cripin's flame. I only want
to comment on guru versus system programmer misunderstanding you have.
We have many people at CMU that can crack a system but are impossible to
communicate with. These people are brilliant but their personaility is very
very poor on interpersonal skills. In many cases, they are in control of
important software. There is no intent to discourage such situations by
management since all benefit....on the other hand they are not policy or
decision makers except in their own "world".
In some cases, I have dealt with people that control software and blantantly
ignore management. Management is in a position of needing them and not
feeling the issue is critical enough to fire (since they have a hard time
evaluating the situation). The result is the hacker is viewed as a guru
who controls the systems and runs it as he sees fit and management tolerates
him until he leaves.
In the final analysis, hacker is not the same as guru which is not the
same as system programmer which is not the same as system manager. Luckily,
many people have some or all of these "jobs" at the same time....makes
life interesting.
Cheers,
-Rudy
b...@bu-cs.bu.edu.uucp
>...If Unix is still vulnerable
>after a decade of availability should we ever expect it to be safe?
Look folks, we're really flying off the handle here on innuendo and
virtually no facts.
Let me try to rehash what I believe happened that started all this:
Sun provided a utility, rwalld, which is a daemon which listens for
certain informatory message broadcasts on a network (such as a
scheduled system shutdown) and displays them on terminals.
This was an extension of the single system 'wall' (Write ALL) program
that most UNIX systems come with. Wall, as it is standardly provided,
is not the issue. Most O/S's come with some utility to broadcast a
message within a local system (ie. no network involved.) Sun simply
extended this service to a network facility (leaving the older method
intact, thus it was an optional extension.)
The security breach was that someone discovered that many systems were
configured to accept these broadcasts fairly indiscriminately.
This, in turn, was due not to a lack of security inherent in the
system, but the fact that the way the system comes off the tape it
allows this. All O/S's come off of distribution tapes inherently
insecure (eg. super-user password is typically generic or null.)
There is a facility (netgroups) which is supposed to be set up by the
concerned system administrator with those machine groups who are to be
allowed to issue such broadcasts (well, that's a little backwards, you
list the systems who you will accept such messages from.)
So, in complete contradiction to Mark Crispin's analysis, it was not
the "random gurus" who were the problem in finding an unclosed
security hole but, rather, the sysadmins who never even opened the
manuals to find out what daemons they were running and how to
administer security (there aren't that many, look at your start-up
files and services/servers files.)
Or, perhaps as was the case with my system (which received the
broadcast) they didn't particularly care if someone sent such a
message and viewed it in the same light as someone sending mail to
someone who didn't want it, a nuisance that could be dealt with easily
if a problem arises (I am still not convinced there is much of a
problem with this particular event.) We never really took a vote on
how many people even agree that a security breach worthy of concern
has occurred on their system, even that fundamental observation
remains an opinion.
Thus, as is almost always the case with system security, it was not
the fault of the system providers but entirely the fault of those
charged with the responsibility of maintaining the system, if they
were concerned about this (later) then they have only themselves to
blame. They simply left the barn door wide open, ignoring the door,
the lock and the key.
To add insult to the system administrator's injury, not only was it
within their normal administrative power to limit such an event with a
simple file edit, they never even had to run the utility at all. It
is purely icing on the cake to find out about other system's status
changes on your network and can be removed by adding one comment
character to one line in the system's start-up file with no real ill
effect on the operation of the system (remember, only SUN's UNIX even
has this particular utility.)
I really wish that people who send notes discussing these issues would
ask themselves if their notes actually contain any factual information.
If nothing else, this whole interchange has pointed out how
ill-informed many folks are about security management on various
systems and how they have turned to folk tales and philosophizing
to supplant that void.
This, in my opinion, is a far worse problem. I do not deny that there
are security and integrity problems on an internet. I only claim that
little of the discussion I have seen has moved us any closer to
measuring and rectifying the problems instead of just finding someone
to blame (we has met the enemy and they is us.)
-Barry Shein, Boston University