The latest CERT Advisory (Nov 4.)
Michael Neuman
the thread--kudos to them for the new improved advisories that looks
like it actually took them more than 30 seconds to write and provides
useful, complete information!
-Mike Neuman
#include <std.disclaimer>
David Sternlight
m...@synergy.c3.lanl.gov (Michael Neuman) wrote:
> Seen the latest CERT advisory? Looks like they've been following
> the thread--kudos to them for the new improved advisories that looks
> like it actually took them more than 30 seconds to write and provides
> useful, complete information!
>
Unfortunately, it also appears to contain enough information for a
malicious user who didn't know about the vulnerability to exploit it.
I don't think that's an improvement.
David
David Sternlight
>In article <david-051...@sternlight.com>,
>David Sternlight <da...@sternlight.com> wrote:
>>Unfortunately, it also appears to contain enough information for a
>>malicious user who didn't know about the vulnerability to exploit it.
>
>>I don't think that's an improvement.
>
>improvement. So hush.
>(well, I don't actually have to fix my sendmail, because I've been
>running sendmail 8.x for months)
I take it then that you are objecting on principle, not because you were
affected by the particular message.
Perhaps more detailed CERT advisories should be encrypted, with the keys
tightly held by sysops registered with InterNIC or some such. Albeit
imperfect, it's a lot better than no control at all. It would dramatically
reduce the set of those who get the info to sysops and a few leaked key
holders.
Alternatively, distribution by a closely controlled mailing list. Either
system would reduce the number of people who don't need the info and get it.
It's true that either approach would be a bit troublesome compared to no
controls, but the real tradeoff isn't that, but one between little
information and no controls, or more full information and some controls.
(By the way, my message is in response to the new circumstances of the more
detailed CERT advisory posted about sendmail, which makes this a more
pressing and practical issue.)
David
--
David Sternlight When the mouse laughs at the cat,
there is a hole nearby.--Nigerian Proverb
Timothy Newsham
>
>Perhaps more detailed CERT advisories should be encrypted, with the keys
>tightly held by sysops registered with InterNIC or some such. Albeit
>imperfect, it's a lot better than no control at all. It would dramatically
>reduce the set of those who get the info to sysops and a few leaked key
>holders.
you seem to think that a person is "good" simply because his name appears
in internic. Is it too far fetched to believe that some people who
admin machines also break into machines? In the future more and more
people will own machines on the network, the club is becomming less
elite folks, looks like unwanteds are moving into your neighborhood
and your precious country club is gonna close.
>Alternatively, distribution by a closely controlled mailing list. Either
>system would reduce the number of people who don't need the info and get it.
These make prime targets for hackers. Nothing more exciting than hunting
down a known source of man new and exciting holes, it becomes a game
at this point. Closed lists such as this also make great breeding
places for egos, which usual rip appart any cooperation.
In my opinion the majority of people are better served by the quick
and open dissemination of the knowledge of these holes. In the shortrun
there is a downside, a few people who would not otherwise have the
information on how to break your security get their hands on the
pieces of information needed to put it all together. Most hacker/cracker/
spider/wutever types would usually have this information before an
advisory was made public by CERT. The long run picture is alot different
though. Education benefits *everyone* in the long run. Open is the
way to go. Security through obscurity must be done away with.
>
[...]
>(By the way, my message is in response to the new circumstances of the more
>detailed CERT advisory posted about sendmail, which makes this a more
>pressing and practical issue.)
>
Lyle_...@transarc.com
> Perhaps more detailed CERT advisories should be encrypted, with the keys
> tightly held by sysops registered with InterNIC or some such. Albeit
> imperfect, it's a lot better than no control at all. It would dramatically
> reduce the set of those who get the info to sysops and a few leaked key
> holders.
>
> Alternatively, distribution by a closely controlled mailing list. Either
> system would reduce the number of people who don't need the info and get it.
Umm. There has historically been a considerable overlap between
sysadmins and crackers. Both roles require the same sorts of
abilities. This overlap may be fading, as more and more sysadmins
lack the abilities/inclination.
Anyway, I don't see what people are so worked up about. This hole in
sendmail has been known for many years. I could probably find
sysadmin books which have this information in it, if I tried. (ORA's
book?) Should CERT republish their advisories periodically, just for
people who didn't get the message the first time around?
Lyle Transarc 707 Grant Street
412 338 4474 The Gulf Tower Pittsburgh 15219
John Hascall
}strn...@netcom.com (David Sternlight) writes:
}> Perhaps more detailed CERT advisories should be encrypted, with the keys
}Umm. There has historically been a considerable overlap between
}sysadmins and crackers. Both roles require the same sorts of
}abilities. This overlap may be fading, as more and more sysadmins
}lack the abilities/inclination.
Indeed, we recently found out during a security incident that
one of the departments on campus had hired someone that we
had previously had trouble with as their sysadmin... sigh.
John
--
John Hascall ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center + Ames, IA 50011 + 515/294-9551
Doug McLaren
John Hascall <jo...@iastate.edu> wrote:
>Lyle_...@transarc.com writes:
>}Umm. There has historically been a considerable overlap between
>}sysadmins and crackers. Both roles require the same sorts of
>}abilities. This overlap may be fading, as more and more sysadmins
>}lack the abilities/inclination.
>
> Indeed, we recently found out during a security incident that
> one of the departments on campus had hired someone that we
> had previously had trouble with as their sysadmin... sigh.
Yes, but is that a problem?
Many people working as sysadmins got started cracking. It's kind of
of like the army - it builds skills that 4 out of 5 employers look
for. Not all cracking is malicious - lots of crackers just like to
see if they can bypass security - not do any damage, just to see if
they can do it. If they're really morally upright, they tell the
person in charge of the machine where the hole is and how to fix it.
Personally, I think this mentality makes for a good sysadmin :)
Usually once you give a cracker (ex cracker?) the root password, you
just took the challenge away. So he'll probably get down to work.
And he'll know what to look for if other crackers are trying to get
into 'his' machine. :)
I guess you've just got to judge the cracker/ex-cracker's
trustworthyness. Or anybody you hire on as a SysAdmin (or any job for
that matter!) Just because you did a security/background check on
them and they came up clean, that doesn't mean they've never played
around. It just means they never got caught.
--
dou...@utpapa.ph.utexas.edu
"Anarchy means having to put up with things that really piss you off."
Steve Simmons
>Umm. There has historically been a considerable overlap between
>sysadmins and crackers. Both roles require the same sorts of
>abilities. This overlap may be fading, as more and more sysadmins
>lack the abilities/inclination.
I find this statement rather amazing. Do you have supporting data?
--
"Although it's not what you and I would call dancing. Not good dancing
anyway. A demon moves like a white band on `Soul Train.'"
-- "Good Omens", by Neil Gaiman and Terry Pratchett
Felipe Rodriquez
>> Seen the latest CERT advisory? Looks like they've been following
>> the thread--kudos to them for the new improved advisories that looks
>> like it actually took them more than 30 seconds to write and provides
>> useful, complete information!
>>
>Unfortunately, it also appears to contain enough information for a
>malicious user who didn't know about the vulnerability to exploit it.
>I don't think that's an improvement.
Security through obscurity never worked David, and it never will.. It's better
to say clearly where the holes are, so that programmers and others can look
for ways to fix them. If CERT keeps being obscure with it's information
we put our trust entirily in their hands, instead of putting this trust
in the hands of the expert community.
Felipe Rodriquez
>Perhaps more detailed CERT advisories should be encrypted, with the keys
>tightly held by sysops registered with InterNIC or some such. Albeit
>imperfect, it's a lot better than no control at all. It would dramatically
>reduce the set of those who get the info to sysops and a few leaked key
>holders.
>Alternatively, distribution by a closely controlled mailing list. Either
>system would reduce the number of people who don't need the info and get it.
Sure.. restrict info and give yourselfe the idea that the information is
safe that way.. Really, these techniques may have worked in the intelligence
community, but they DON'T work on the internet.
I've heard about crackers getting their favourite bugs directly from
cracked cert computer-systems. A restricted mailing-list or encrypted
distribution would really help to obscure things, but it would certainly
not help to keep bugs and features out of malicious hands.
David Lesher
Others said:
# strn...@netcom.com (David Sternlight) writes:
Folks:
Sternlight just "left, never to return", several other groups where he
helped fan up big flamewars out of sensible discussions. Note that this
was actually the third or forth time he "left" in the last few weeks.
(Everyone there is hoping....)
I suppose it's enivitable that he show up somewhere else, posting
remarks to try to kindle a fire here. Sigh.
This was a interesting discussion. Let's try & keep it same. DS shares
something in common with Fred Saberhagen's vampires; If you don't
invite them into your house, all they can do is stand outside & taunt
you for a while before they go away. If you DO let one in, though,
you're stuck.
Why don't we go back to the real discussion here, and see if we can
forstall the need of garlic and/or killfiles? If you want to see the
charred remains of his previous visits, look at comp.org.eff.talk.
Note I've directed followups to the group devoted to him:
alt.fan.david-sternlight.
--
A host is a host from coast to coast..wb8foz@skybridge.scl.cwru.edu
& no one will talk to a host that's close............(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433
R Agent
>Perhaps more detailed CERT advisories should be encrypted, with the keys
>tightly held by sysops registered with InterNIC or some such. Albeit
>imperfect, it's a lot better than no control at all. It would dramatically
>reduce the set of those who get the info to sysops and a few leaked key
>holders.
It only takes one.
>Alternatively, distribution by a closely controlled mailing list. Either
>system would reduce the number of people who don't need the info and get it.
You mean like Zardoz? Or perhaps CORE? Maybe you mean FIRST.
>It's true that either approach would be a bit troublesome compared to no
>controls, but the real tradeoff isn't that, but one between little
>information and no controls, or more full information and some controls.
Either way the 'wrong' people are going to have it anyway.
RA
ro...@ccs.neu.edu (Rogue Agent/SoD!/TOS/KoX) - pgp key on request
-----------------------------------------------------------------
The NSA is now funding research not only in cryptography, but in all areas
of advanced mathematics. If you'd like a circular describing these new
research opportunities, just pick up your phone, call your mother, and
ask for one.
Theodore M.P. Lee
Rodriquez) wrote:
> da...@sternlight.com (David Sternlight) writes:
>
> Security through obscurity never worked David, and it never will.. It's better
> to say clearly where the holes are, so that programmers and others can look
> for ways to fix them.
Penetrate and patch doesn't work either. It's gotta be designed and built
right from the start to exacting standards.
David Sternlight
R Agent <ro...@ccs.neu.edu> wrote:
>In article <strnlghtC...@netcom.com> da...@sternlight.com (David
>Sternlight) writes:
>[...]
>>Perhaps more detailed CERT advisories should be encrypted, with the keys
>>tightly held by sysops registered with InterNIC or some such. Albeit
>>imperfect, it's a lot better than no control at all. It would dramatically
>>reduce the set of those who get the info to sysops and a few leaked key
>>holders.
>
>It only takes one.
>
The remainder of the message follows that line.
As I made clear in my message, I was not suggesting a perfect system but one
which had the improvement that the critical information would be available
to a reduced number of potential abusers, particularly (though I did not say
this earlier) lazy ones. I think this to be an advantage in that it would
reduce the number of abusers to contend with.
No system is perfect and this one will not exclude the determined and
skillful abuser. That is not it's purpose.
David Sternlight
Felipe Rodriquez <fel...@hacktic.nl> wrote:
>
>Security through obscurity never worked David, and it never will.. It's better
>to say clearly where the holes are, so that programmers and others can look
>for ways to fix them. If CERT keeps being obscure with it's information
>we put our trust entirily in their hands, instead of putting this trust
>in the hands of the expert community.
This is not a matter of security through obscurity but of reducing the
number of problem children. The principle is related to that of "locks keep
an honest man out"
Alexis Rosen
> Seen the latest CERT advisory? Looks like they've been following
> the thread--kudos to them for the new improved advisories that looks
> like it actually took them more than 30 seconds to write and provides
> useful, complete information!
Unfortunately, it's not complete, and if you follow the first of the
three courses of action you may be lulled into a false sense of security.
I'll post more details in a few minutes.
---
Alexis Rosen Owner/Sysadmin,
PANIX Public Access Unix & Internet, NYC.
ale...@panix.com
Jack Twilley
Kyle> You talk of security as if it were a discrete binary quantity.
Kyle> It's not. The more crackers the information is kept away from
Kyle> the more likely it is that I'll have the time to get my system
Kyle> patched before one of them gets to my system. No, obscurity
Kyle> won't stop them, but it might cut down on the number of them and
Kyle> that buys us all a bit more time.
If you keep the information from me, Kyle, it buys me no time at all.
Jack.
--
John M. Twilley | naut...@acm.rpi.edu | twi...@dewey.nl.nuwc.navy.mil
"Our passion is like a nuclear explosion: violent anticipation, a
brilliant blast of heat and light, and a beautiful sunset..." --me
Kyle Jones
> > for a malicious user who didn't know about the vulnerability
> > to exploit it. I don't think that's an improvement.
>
You talk of security as if it were a discrete binary quantity.
It's not. The more crackers the information is kept away from
the more likely it is that I'll have the time to get my system
patched before one of them gets to my system. No, obscurity
won't stop them, but it might cut down on the number of them and
Dave Hayes
>Unfortunately, it also appears to contain enough information for a
>malicious user who didn't know about the vulnerability to exploit it.
If a malicious user has the proper expertise, even the first advisory
would have helped. If they don't, this announcement does them no good.
>I don't think that's an improvement.
I do. More information is better...or does your job also depend upon
obscure security?
--
Dave Hayes - Institutional Network & Communications - JPL/NASA - Pasadena CA
da...@elxr.jpl.nasa.gov da...@jato.jpl.nasa.gov ...usc!elroy!dxh
Most novices picture themselves as masters - and are content with the
picture. This is why there are so few masters.
Hari Seldon
>In article <1993Nov7....@lokkur.dexter.mi.us>,
>Steve Simmons <s...@lokkur.dexter.mi.us> wrote:
>>Lyle_...@transarc.com writes:
>>
>>>... This overlap may be fading, as more and more sysadmins
>>>lack the abilities/inclination.
>>I find this statement rather amazing. Do you have supporting data?
>As a result, the people _assigned_ to run the computers require less
>and less knowlege, and so we see more sysadmins who do "something else"
>as their full-time job. ...
>
>Just the other day I got a flyer to subscribe to "Sysadmin" magazine.
>The flyer was clearly directed towards sysadmins-who-were-not-syadmins-
>full-time. Apparently some marketing people have seen the trend as well.
yes i've seen it. my sysadmin job is a secondary set of responsibilities.
here was the progression through my more 'recent employment'
hw design
embedded code
databases a'la oracle
dba
sysadmin
i don't think the corporate world is much different, i spend 1-3 hrs/day of
my time trying to keep up, but comparred to a full time sysadmin only, well
you can figure. i've been doing this for ~3 years now but even to reach peon
status required a bit of calender time.
so as re: the sysadmin mag, yes most of it i've already discovered,
occationally it shows me something new ( or provides the script i was going
to write anyway) strangley i don't think i'm in a position much different
from many in the new corporate age.(tho from this side i sure wish i'd been
nicer to the sysadmins who kept my network up back when i did design :-(
bill 'dweeb 3rd class' pociengel
lilb pleceoing 'I'm a little confused right now'
Peter Busser
> > > Unfortunately, it also appears to contain enough information
> > > for a malicious user who didn't know about the vulnerability
> > > to exploit it. I don't think that's an improvement.
> >
> > Security through obscurity never worked David, and it never
> > will. [...]
>You talk of security as if it were a discrete binary quantity.
It is.
>It's not. The more crackers the information is kept away from
>the more likely it is that I'll have the time to get my system
>patched before one of them gets to my system.
That's what you think it works. In reallity quite some hackers working as
sysadmins right now. They often know better what's going on with a system than
other people, so they get hired for such a job. And being sysadmin, they should
get the "sensitive" information, right?
>No, obscurity
>won't stop them, but it might cut down on the number of them and
>that buys us all a bit more time.
It will stop them for a few hours. Information spreads faster than light.
Groetjes,
Peter Busser
--
Linux, the choice of a GNU generation.
Peter Busser
>No system is perfect and this one will not exclude the determined and
>skillful abuser. That is not it's purpose.
So, what is the use of a system that isn't even going to work in theory?
Kyle Jones
> >skillful abuser. That is not it's purpose.
>
Chrissakes, is this such a hard concept to grasp? We are trying
to slow down the not-so-determined and not-so-skillful, who more
than make up for their lack of skill and determination by sheer
numbers.
James O Ausman
>
>>Umm. There has historically been a considerable overlap between
>>sysadmins and crackers. Both roles require the same sorts of
>>abilities. This overlap may be fading, as more and more sysadmins
>>lack the abilities/inclination.
>
>I find this statement rather amazing. Do you have supporting data?
I am curious, which do you find amazing: the first statement or the second?
Jim Ausman
--
Don't believe everything you read.
Jim Duncan
(Peter Busser) writes:
ky...@uunet.uu.net (Kyle Jones) writes:
>It's not. The more crackers the information is kept away from
>the more likely it is that I'll have the time to get my system
>patched before one of them gets to my system.
>No, obscurity
>won't stop them, but it might cut down on the number of them and
>that buys us all a bit more time.
It will stop them for a few hours. Information spreads faster than light.
I regret to say this, but Kyle's right and you're wrong. We need all the
time we can get.
When CERT first reported the sendmail problem a few weeks ago, I agree, it
was too weak, and the first thing I did was call our FIRST representative
and ask her to get more information.
The second notice, however, was much more useful, and I knew I needed to
upgrade to sendmail-8.6.4 (I had installed 8.5 in September). The second
advisory told me everything I needed to know. I maintain a network of over
a hundred machines, most of them a cohesive network of SPARCstations running
SunOS 4.1.3.
Posting the details of how to exploit the hole, however, was an
unconsionable act, and it really made me angry. The problem suddenly went
from something that I needed to fix this week to something I needed to do in
fifteen minutes. I resent like hell the poster's assertion that "sysadmin
is not a nine to five job, you must always be ready, etc., etc."
Contrary to what many of you believe, most of the problems come from hacker
wannabees, who *don't* have the wherewithall to figure out these holes for
themselves. They need cookbook instructions. Suddenly, attacks sprung up
all over the place (I'm inclined to believe Ed DeHart) because the wannabees
suddenly had a new toy to play with.
I think CERT is a useful thing, and I hope they continue. There have been
some mistakes, but I think they do the best job they can in a society where
there are thousands of people just waiting to sue the first "deep-pockets"
victim that stumbles. The plans others have made to provide in-depth
reports about holes are fraught with disaster. As soon as someone suffers a
loss as a result of rapid availability of dangerous information, you can bet
the lawyers will come knocking.
Jim
--
Jim Duncan <j...@math.psu.edu> Penn State Math Dept Systems Administrator
"[A computer is] like an Old Testament god, with a lot of rules and no mercy."
Joseph Campbell
Steve Simmons
Both. Historically speaking I go back over ten years as a UNIX
admin, and much further as a computer admin. Neither jibes with
my experience. Lyle and I are discussing this civilly in email :-),
so I won't incent things here.
On the other hand, there is one point worth noting. Any sysadmin worth
his salt has, at one time or another, had to break into his own system.
The big trick is how to do so in such a way that the wrong folks don't
use it. I like bootable media, myself.
John Hawkinson
>Posting the details of how to exploit the hole, however, was an
>unconsionable act, and it really made me angry.
Really? That's interesting. I'll humbly point out that I have
received NO negative feedback about my post, whatsoever. Yours is
the first post I recall seeing that suggested people were angered by
or bothered by my posting (I might have missed postings though). All
of my e-mail has been unanimously supportive, however.
>The problem suddenly went from something that I needed to fix this
>week to something I needed to do in fifteen minutes.
That's not true. It was _always_ something you had to do in the
next fifteen minutes; you should never rely on the slow spread of
information to do your work for you.
Furthermore, I was primarily expanding on an article by
an11568, and was not posting purely new information (though I don't
think this is a defense I'd like to pursue, because I would have done
the same thing in the case w/o an an11568-type posting, had I known
what I knew).
>I resent like hell the poster's assertion that "sysadmin is not a
>nine to five job, you must always be ready, etc., etc."
I said:
"Nevertheless, take this opportunity to remember that system
administration is NOT a nine to five job, and one should be
ready at all times."
Please don't misquote me (emphasis and context are important). Back
to you:
>I resent like hell the poster's assertion that "sysadmin is not a
>nine to five job, you must always be ready, etc., etc."
Do you disagree with that assertion, then? If you resent it so much
I'd like to know why you haven't told me so.
>Contrary to what many of you believe, most of the problems come from hacker
>wannabees, who *don't* have the wherewithall to figure out these holes for
>themselves.
Do you have concrete proof of this?
>They need cookbook instructions. Suddenly, attacks sprung up all
>over the place (I'm inclined to believe Ed DeHart) because the
>wannabees suddenly had a new toy to play with.
Don't forget that it afflicts sysadmins to. In fact, this problem
afflicts almost every possible knowledge-disclosure situation in the
world. There are always people who should know something who are
smart enough to figure it out, and those who should know but aren't
clever enough. Then there are those who (perhaps) ought not know,
many of whom cannot figure it out.
There is no perfect solution, _unless_ you decide that everyone
deserves to know. The problem is then comparatively simpler.
>reports about holes are fraught with disaster. As soon as someone suffers a
>loss as a result of rapid availability of dangerous information, you can bet
>the lawyers will come knocking.
You just watch. I'll be waiting.
--
John Hawkinson
jh...@panix.com
Jack Mayo
[snip, snip]
>
>Thanks to the bad Internet citizens like John I suspect we'll soon be
>seeing legislation to criminalize this sort of thing. I will lament the
>restrictions on our currently free forum. I will not lament seeing
>criminals paying restitution.
>
>Roger Marquis
Which sort of thing? Posting details of bugs that can be exploited, or
sharing information that can help sysadmins make their systems more secure?
Does this mean if I distribute information that can be used in a harmful
way you want to prosecute me? Hmmm... "If you stab someone with an ice
pick, you can cause serious damage to their person." You want a law against
something like that?
Something else I find amazing...everytime this argument (about restricting
what people can can post) comes up, people seem to forget that the US
is not the only country using the Internet anymore. Many other
countries are attached, and I think laws passed here won't necessarily
apply to citizens of other countries.
I'm not sure how I feel about full disclosure, but I definitely think
posting details at some point 2 weeks or so after an advisory
would be beneficial. (Not that this happened this time.)
---
may...@ac.com | Disclaimer: What I say isn't what they say.
"The first 24-hour Transfund automated teller machine (ATM) in Sequoyah
County was recently installed at the 1st National Bank in Sallisaw [Oklahoma]"
- The Sequoyah County Times, Feb. 14th, 1993
Kyle Jones
> The postings of details of the security bug were inconsiderate
> only of those site administrators who don't follow the
> security-related newsgroup or who don't want to fix problems
> even after they are armed with the necessary knowledge.
Ah, and such admins are therefore useless scum, unworthy of
consideration, let alone salvation?
How about the site administrators who were at home fast asleep?
The Internet is worldwide, it's always 3am somewhere. Example:
the recent disclosure of the sendmail holes hit the net at about
2100 EST (0200 UT). Dead of night in Europe, and after business
hours across most of North America.
How about admins who have hundreds of systems to fix, even after
they notice the posting? Perhaps you can't imagine the
logistical horrors involved in doing such an update on short
notice, but I can.
Robert C. Lehman
>John Hawkinson (jh...@panix.com) wrote:
>>>Posting the details of how to exploit the hole, however, was an
>>>unconsionable act, and it really made me angry.
>>Really? That's interesting. I'll humbly point out that I have
>>received NO negative feedback about my post, whatsoever.
>
>Are you blind? Personally I think it was incredibly shortsighted,
>inconsiderate of the entire population of Internet connected system
>administrators, and just plain stupid.
>
>The number of sendmail related incidents, as reported to CERT, went up
>_dramatically_ within a couple of hours of your post to the net. Do
>you really think all crackers are so expert that they already knew
>about this hole? That's a particularly self-serving viewpoint.
Anyone with half a brain could figure out how to exploit the problem.
Frankly, I think it's better for the problem (and fix) to be clearly
identifiable, even if the potential population of bad guys is increased.
It's not like we're talking about some big secret here...
>Thanks to the bad Internet citizens like John I suspect we'll soon be
>seeing legislation to criminalize this sort of thing. I will lament the
>restrictions on our currently free forum. I will not lament seeing
>criminals paying restitution.
I suspect there would be a great deal of support for criminalizing the
use of sendmail :-).
Rob
Rahul Dhesi
>Are you blind? Personally I think it was incredibly shortsighted,
>inconsiderate of the entire population of Internet connected system
>administrators, and just plain stupid.
Here at the a2i network, I don't like to fix problems on the basis of
rumor unsupported by evidence, which is pretty much what the CERT
announcement was. Although most site administrators will not like to
admit it, I believe many of them feel the same way. Nobody wants to
spend time fixing a problem without knowing if one exists and without
knowing if the claimed fix is really a fix. The postings about which
Roger is complaining allowed administrators to check to see if they
were vulnerable.
The postings of details of the security bug were inconsiderate only of
those site administrators who don't follow the security-related
newsgroup or who don't want to fix problems even after they are armed
with the necessary knowledge.
But the postings were very useful to site administrators who do follow
the security-related newsgroups and who do fix problems when they
understand them.
So, decide in which group you belong, and don't speak for 'the entire
population of Internet connected system administrators', just for the
group to which you belong.
--
Rahul Dhesi <dh...@rahul.net>
also: dh...@cirrus.com
Dave Hayes
>Come on John, I've read and heard LOTS OF NEGATIVE CRITICISM of your post.
>inconsiderate of the entire population of Internet connected system
>administrators, and just plain stupid.
And *I* think it was necessary to the long-term safety of the Internet
community as well as being incredibly helpful to those not in the security
elite.
>The number of sendmail related incidents, as reported to CERT, went up
>_dramatically_ within a couple of hours of your post to the net.
How do you know?
>Do you really think all crackers are so expert that they already knew
>about this hole? That's a particularly self-serving viewpoint.
I'd be willing to bet that most anyone who argues for security through
obscurity is either a cracker themselves or someone who's job depends upon
them being the security wizard. The reasons are obvious, dissemination of
security information leads to the elimination of security holes.
Now who's self-serving? :-)
I don't care what crackers know. I care what sys admins know.
--
Dave Hayes - Institutional Network & Communications - JPL/NASA - Pasadena CA
da...@elxr.jpl.nasa.gov da...@jato.jpl.nasa.gov ...usc!elroy!dxh
"Better to be safe than to be sorry"
is a remark of value only when these are the actual alternatives.
Butch Deal
>In article <931111222...@wendy-fate.uu.net>,
>Kyle Jones <ky...@uunet.uu.net> wrote:
>>Rahul Dhesi writes:
>> > The postings of details of the security bug were inconsiderate
>> > only of those site administrators who don't follow the
>> > security-related newsgroup or who don't want to fix problems
>> > even after they are armed with the necessary knowledge.
>>
>>consideration, let alone salvation?
>>
>>How about the site administrators who were at home fast asleep?
>>The Internet is worldwide, it's always 3am somewhere. Example:
>>the recent disclosure of the sendmail holes hit the net at about
>>2100 EST (0200 UT). Dead of night in Europe, and after business
>>hours across most of North America.
>
>coming, with details on what to do to fix things, might have counerweighted
>this somewhat. On the other hand it's not convenient to your line of argument
>to remember this, is it?
very true. Besides reading the warning posts in newsgroups, I had recieved
5 or 6 copies of it in the mail, some on mailing lists otheres just from
other sys. admins. I know. I sent out a few copies myself just to make sure
that the work got around. Although I do not have a very large network
to admin., 35 sun and 5 iris comprise my promary network, I downloaded
compiled 4 times (solaris 2.3, solaris 1.1, irix 4.x, irix 5.1.1.1), set
up the m4 cf domain structure, and installed on all machines in just
a few hours. I also took the opertunity to configure the sgi machines to
mount the mail directory from the mail hub with automount like the suns.
I know I am not the GREAT GURU of sys. admins., so I know I can not be
alone in haveing almost no trouble at all installing a solution to the
problem in a timely manner. In the time it takes you to read all this
thread you could download and install a solution. Actually it only takes
about a min. to edit the sendmail.cf file and coment out the problem, and
restart sendmail, a few more mins. and you could have a script to do
the same to all your machines. Then you have all the time you need
to come up with a better solution.
And you are really just kidding yourself if you think that crackers do
not have any information before you do. Crackers have their own mailing
lists to get this kind of info out.
>
>>How about admins who have hundreds of systems to fix, even after
>>they notice the posting? Perhaps you can't imagine the
>>logistical horrors involved in doing such an update on short
>>notice, but I can.
once I had all the different binaries I needed and the sendmail.cf files
the install was relativly short. All the suns were already set up with
a central mail hub, and most all of the non-server machines mount /usr
from the server, so all I had to do was copy the sendmail.cf file to
them and restart sendmail. The SGI's took a little more doing in
that I had to set up the automount files to mount the mail directory
from the sun mail hub machine as well. The sendmail.cf files were
pretty easy to set up with the m4 configuration set up. End result,
the users can get mail on all the machines in the network including the
sgi machines.
>
>Ask Perry Metzger. I don't see him complaining, and he had _thousands_ of
>systems to fix.
>--
>Thor Lancelot Simon t...@panix.COM
>
>"When I wanna talk sense to you, it's like spitting at the rain." -- Op Ivy
--
#include <std/*>
The Butcher
Butch Deal de...@ait.nrl.navy.mil
--------------------------------------------------------------------------------
John Hawkinson
>t...@panix.com (Thor Lancelot Simon) writes:
>>That's really interesting. You're saying CERT abandoned their
>>"information black hole" position just so they could tell you this?
>>The only thing I've ever heard from them along these lines is "we
>>cannot give information on other incidents."
>No, he is probably saying that Ed DeHart of CERT made this comment to probably
>a couple of hundred Sys Admins who were at the CERT BOF at the LISA conference
>last week
I'm afraid that's just not possible. If you'd read the paragraph prior to
the one you'd quoted:
In article <marquisC...@netcom.com>, Roger Marquis
<mar...@netcom.com> wrote:
>The number of sendmail related incidents, as reported to CERT, went up
>_dramatically_ within a couple of hours of your post to the net. Do
^^^^--meaning mine.
Since I posted my post Monday afternoon, AFTER LISA, there's no way
that Ed DeHart could have known about it.
Perhaps he was referring to something sent to fire...@greatcircle.com?
--
John Hawkinson
jh...@panix.com
Thor Lancelot Simon
Peter Van Epp <van...@fraser.sfu.ca> wrote:
>t...@panix.com (Thor Lancelot Simon) writes:
>
>>That's really interesting. You're saying CERT abandoned their "information
>>black hole" position just so they could tell you this? The only thing I've
>>ever heard from them along these lines is "we cannot give information on other
>>incidents."
>
>No, he is probably saying that Ed DeHart of CERT made this comment to probably
>a couple of hundred Sys Admins who were at the CERT BOF at the LISA conference
>also pointed out that under US law it is possible (note the possible!) that the
>person that made the post could be sued by one of the sites that got broken
>into, and that the same possibilty exists if CERT had made such a post.
That's interesting. The CERT BOF would seem to have taken place (were it
"last week") _before_ Mr. DeHart could have had any knowledge of the
consequences of something which took place _this Monday_.
Of course, it did happen _after_ CERT posted several advisories on the subject
which were misleading and dangerous. And probably helped instill the usual
false sense of trust-us, trust-the-vendor security that CERT is so good at
instilling.
Roger Marquis
>>Posting the details of how to exploit the hole, however, was an
>>unconsionable act, and it really made me angry.
>Really? That's interesting. I'll humbly point out that I have
>received NO negative feedback about my post, whatsoever.
Come on John, I've read and heard LOTS OF NEGATIVE CRITICISM of your post.
Are you blind? Personally I think it was incredibly shortsighted,
inconsiderate of the entire population of Internet connected system
administrators, and just plain stupid.
The number of sendmail related incidents, as reported to CERT, went up
_dramatically_ within a couple of hours of your post to the net. Do
you really think all crackers are so expert that they already knew
about this hole? That's a particularly self-serving viewpoint.
>You just watch. I'll be waiting.
>John Hawkinson
Thanks to the bad Internet citizens like John I suspect we'll soon be
seeing legislation to criminalize this sort of thing. I will lament the
restrictions on our currently free forum. I will not lament seeing
criminals paying restitution.
Roger Marquis
Andrew Molitor
exchange of information who decide to do so through incredibly arcane
shell scripts for exploiting problems.
These are invariably badly written, often require substantial
effort to reverse engineer, and often do something potentially nasty.
Why not distribute a textual discussion of the problem, which
actually gives the information directly? If you *must* show off your
complete failure to grasp Bourne shell, why not do so with some
code that demonstrates the problem, but requires some modification
to actually do anything unpleasant?
My personal theory is that it's some pathetic ego thing, and
that rather often, these benign white knights, fighting only for truth
and justice, are in fact idiots(*).
Andrew
opinions my own, and whatnot.
(*) Note use of new term. 'Hacker' is ambiguous, 'cracker' is silly. Bellovin
likes 'vandal', but I really feel that 'idiot' captures the essence.
Joshua Geller
writes:
> In article <marquisC...@netcom.com> mar...@netcom.com (Roger
> Marquis) writes:
> >John Hawkinson (jh...@panix.com) wrote:
> >>>Posting the details of how to exploit the hole, however, was an
> >>>unconsionable act, and it really made me angry.
> >>Really? That's interesting. I'll humbly point out that I have
> >>received NO negative feedback about my post, whatsoever.
> >Come on John, I've read and heard LOTS OF NEGATIVE CRITICISM of your post.
> >Are you blind? Personally I think it was incredibly shortsighted,
> >inconsiderate of the entire population of Internet connected system
> >administrators, and just plain stupid.
> >The number of sendmail related incidents, as reported to CERT, went up
> >_dramatically_ within a couple of hours of your post to the net. Do
> >you really think all crackers are so expert that they already knew
> >about this hole? That's a particularly self-serving viewpoint.
> Anyone with half a brain could figure out how to exploit the problem.
> Frankly, I think it's better for the problem (and fix) to be clearly
> identifiable, even if the potential population of bad guys is increased.
> It's not like we're talking about some big secret here...
two things occur to me here: first off, many (not all) crackers don't have
half a brain. they have a list of security holes and a high level of
social imparity. on the other hand, if you run a system that is connected
to the internet and don't read the appropriate newsgroups and/or don't
take immediate action to correct holes like this, what does this say
about how you do your job? I realize that a lot of system administrators
only do administration part time and have other work that takes up most
of their time. this just shows that their employers are short sighted.
> >Thanks to the bad Internet citizens like John I suspect we'll soon be
> >seeing legislation to criminalize this sort of thing.
oh come on.
josh
Rahul Dhesi
Jones) writes:
>How about the site administrators who were at home fast asleep?
>The Internet is worldwide, it's always 3am somewhere....
>How about admins who have hundreds of systems to fix, even after
>they notice the posting? Perhaps you can't imagine the
>logistical horrors involved in doing such an update on short
>notice, but I can.
Kyle, the CERT advisory came out on November 4, late in the evening
EST. CIAC followed up with its own advisory at around 2:00 am EST.
an1...@anon.penet.fi posted his/her revelations on the evening (by
EST) of November 7, and this was shortly followed by a posting from
ale...@panix.com supplying his fix-for-a-fix and promising more
details.
It was not until around 24 hour later, on the evening (by EST) of
November 8, that the posting by jh...@panix.com appeared. By then, any
site admin who was concerned about the CERT advisory and willing to act
purely on rumor should have installed the proposed fixes: disabling the
prog mailer, or installing smrsh. There had been four days of
warning. You didn't have to get up at 3:00 am to check Usenet.
Any revelation of a serious security problem should be followed some
time later by enough details to let site administrators understand,
diagnose, and fix the problem, and verify the fix. The only question
is: How much later? Had CERT, CIAC, or Whoever Else had a sensible
policy of doing so, I'm sure an1...@anon.penet.fi, ale...@panix.com,
and jh...@panix.com could have been happy to wait. But they knew it
wan't going to happen, and they took it upon themselves (thanks, guys)
to let the rest of us in on the information, so we could make some
intelligent decisions of our own.
I'm sure there are logistical horrors involved in updating a large
number of systems at short notice. That's part of the game. You can
count on having to do it once every couple of years. It's this sort of
thing that makes system administration one of the better paying jobs.
Is the network world a little more secure today than it was on
November 4? You tell me.
Thor Lancelot Simon
>>>Posting the details of how to exploit the hole, however, was an
>>>unconsionable act, and it really made me angry.
>>Really? That's interesting. I'll humbly point out that I have
>>received NO negative feedback about my post, whatsoever.
>
>Come on John, I've read and heard LOTS OF NEGATIVE CRITICISM of your post.
>Are you blind? Personally I think it was incredibly shortsighted,
No, you're either reading the other, alternate Usenet, or you're lying.
>inconsiderate of the entire population of Internet connected system
>administrators, and just plain stupid.
Inconsiderate of the entire population of Internet connected _lazy_,
_incompetent_ system administrators, who in my opinion have to learn to swim
or be let sink. Yes, I include you in this estimation.
>
>The number of sendmail related incidents, as reported to CERT, went up
>_dramatically_ within a couple of hours of your post to the net. Do
That's really interesting. You're saying CERT abandoned their "information
black hole" position just so they could tell you this? The only thing I've
ever heard from them along these lines is "we cannot give information on other
incidents."
>you really think all crackers are so expert that they already knew
>about this hole? That's a particularly self-serving viewpoint.
You think that several weeks of being told "Use Sendmail 8.6!", plus a day's
warning after the anonymous post, plus a day's warning before John posted the
exact details wasn't enough? I think you're lazy, and incompetent, and you're
only blowing so hard because you don't want to realize that you aren't doing
your job right.
Any cracker who couldn't figure out the hole John posted about, given the
original anonymous post, was such a fool that I doubt he could have used
John's help. But you already _knew_ what to do to fix things, and even if you
had had only ten minutes notice before this (to my mind wholly fictitious)
"spate of attacks" occurred, you could have used to to turn off the prog
mailers on your hosts and get to work. If you knew how to or had motive to
get to work.
>
>>You just watch. I'll be waiting.
>>John Hawkinson
>
>Thanks to the bad Internet citizens like John I suspect we'll soon be
>seeing legislation to criminalize this sort of thing. I will lament the
ROTFL. And just how long have _you_ been an "Internet citizen", sir?
I don't think you quite "get it" yet...
>restrictions on our currently free forum. I will not lament seeing
>criminals paying restitution.
Go ahead. Make my day.
Thor Lancelot Simon
Kyle Jones <ky...@uunet.uu.net> wrote:
>Rahul Dhesi writes:
> > The postings of details of the security bug were inconsiderate
> > only of those site administrators who don't follow the
> > security-related newsgroup or who don't want to fix problems
> > even after they are armed with the necessary knowledge.
>
>Ah, and such admins are therefore useless scum, unworthy of
>consideration, let alone salvation?
>
>the recent disclosure of the sendmail holes hit the net at about
>2100 EST (0200 UT). Dead of night in Europe, and after business
>hours across most of North America.
Well, it would seem to me that a full day's warning that the disclosure was
coming, with details on what to do to fix things, might have counerweighted
this somewhat. On the other hand it's not convenient to your line of argument
to remember this, is it?
>How about admins who have hundreds of systems to fix, even after
>they notice the posting? Perhaps you can't imagine the
>logistical horrors involved in doing such an update on short
>notice, but I can.
Ask Perry Metzger. I don't see him complaining, and he had _thousands_ of
systems to fix.
Peter Van Epp
>That's really interesting. You're saying CERT abandoned their "information
>black hole" position just so they could tell you this? The only thing I've
>ever heard from them along these lines is "we cannot give information on other
>incidents."
No, he is probably saying that Ed DeHart of CERT made this comment to probably
a couple of hundred Sys Admins who were at the CERT BOF at the LISA conference
last week (and yes I was there to hear him say it), not just to him. Mr DeHart
also pointed out that under US law it is possible (note the possible!) that the
person that made the post could be sued by one of the sites that got broken
into, and that the same possibilty exists if CERT had made such a post.
Peter Van Epp / Operations and Technical Support
Simon Fraser University, Burnaby, B.C. Canada
Casper H.S. Dik
>Of course, it did happen _after_ CERT posted several advisories on the subject
>which were misleading and dangerous. And probably helped instill the usual
>false sense of trust-us, trust-the-vendor security that CERT is so good at
>instilling.
Oh right. And posting a descritption on how to exploit the hole, which
worked only on a few sites, and that doesn't work for many sites taht
have a buggy sendmail isn't ``misleading and dangerous''.
The post on how to exploit the hole was not only inconsiderate,
it was much more ``misleading and dangerous'' than the CERT
advisory. The second CERT advisory said ``there is only one known
secure sendmail''. The ``howto'' post made people think,
``if this doesn't work on us, we're safe''. And that is simply
not true.
Casper
Thor Lancelot Simon
Pardon the obscenity:
If you weren't deliberately suffering from memory loss in a pitiful attempt to
hold your tenuous ground, you might observe that we
FUCKING WELL TOLD EVERYONE THAT IT WASN'T A LITMUS TEST
and that the articles in question, at least the ones from Panix, spent the
great majority of their length _discussing_ the problem, not merely
demonstrating it. In fact, I believe we _discussed_ it at substantially more
length than CERT or CIAC did.
Grr. Criticize anyone you want to -- but please get your facts straight.
Casper H.S. Dik
>Pardon the obscenity:
>If you weren't deliberately suffering from memory loss in a pitiful attempt to
>hold your tenuous ground, you might observe that we
>FUCKING WELL TOLD EVERYONE THAT IT WASN'T A LITMUS TEST
>and that the articles in question, at least the ones from Panix, spent the
>great majority of their length _discussing_ the problem, not merely
>demonstrating it. In fact, I believe we _discussed_ it at substantially more
>length than CERT or CIAC did.
>Grr. Criticize anyone you want to -- but please get your facts straight.
Right, that doesn't explain away all the posts of
``MUSLIX 4.5.x is safe'', while MUSLIX 4.5.x wasn't safe.
I've reread ``<2bmtqp$n...@panix.com>'',
"More details on the sendmail hole, including smrsh hole.".
Quotes:
The condition we have used to generate an error is an invalid
Return-Receipt-To: header. There are a plethora of other ways to do
so, and some of them may depend on the specifics of your sendmail; be
forewarned.
That's as much warning as I can find. What did I miss?
And note that it isn't only what you write what is important, also
what other people read into it. The fact remains, all versions of
sendmail are vulnerable (except 8.6.4).
It is obvious from a number of postings that people considered it a
litmus test. You should note that with certain configurations of
sendmail it is incredibly difficult to provoke the bug.
That people with the same binaries on one site can easily demonstrate
the bug, while the same people cannot do so on other sites with
the same binaries but slightly different conifurations (and
I'm not talking about the prog mailer here).
If you're posting about a security hole and how to exploit it, post
properly. Don't do a half-hearted job. My opinion remains unchanged:
CERT is better than panix.
In the CERT advisory it said: sendmail is a risk, only 8.6.4 is know
to be safe. A sysadmin worth his salt should change hist sendmail
daemon.
Or you read ``<2bmtqp$n...@panix.com>'', in that article it says:
this is one way to exploit the bug, many otehrs are variations of
headers x, y ,z. Suppose you try all of these. Works on some
machines, but not on certain other machines. Sysadmin thinks,
ah, those machines are safe. NOT!
So, in the end, whatever the outcome of his experiments HE MUST REPLACE
SENDMAIL. So what use are the experiments? Why not trust CERT then?
And believe me, various people have tried to break our sendmail daemon,
non succeeded. But I know for sure that a the bug is in that daemon.
With slightly more esoteric ways it is possible to break the daemon, but
those methods add one important step, as yet unmentioned.
Casper
Alec Muffett
>If you're posting about a security hole and how to exploit it, post
>properly. Don't do a half-hearted job.
Lay off, Casper - nobody's *perfect* - not you, me, or them.
Hell - following the same argument, you could wind up flaming me for
being so inconsiderate as to leave *BUGS* (horrors!) in the Crack code,
such that it falls over on DEC Alphas (argh!) - crippling it's
usefulness unless the sysadmin is sufficiently competent to go hacking
my code.
[incidentally - if you HAVE got a DEC Alpha, here's a hint; it's a
pointer cast problem in a printf statement, the return value from
ctime() should be cast to (char *), not the 'unsigned long int' that
the compiler implicitly assumes...sodding 64 bit machines 8-)... ]
- and if you *did* berate me for being so inconsiderate as to be an
imperfect programmer, I believe I'd be justified in thinking you a
"twisted little shit", as mjr would say...
>My opinion remains unchanged:
>CERT is better than panix.
CERT is damn good at what they are good at. If you want to discuss what
they're good at, go join the thread in comp.security.unix.
Panix - specifically jhawk & tls - are just citizens of the net, just
like you and me; as such, they have the same one and only right that
any citizen of the net has - to espouse their opinions and distribute
information.
You don't *have* to listen to it, but it *can* be to your advantage.
>In the CERT advisory it said: sendmail is a risk, only 8.6.4 is know
>to be safe. A sysadmin worth his salt should change hist sendmail
>daemon.
An experienced one who was like to face the problem, yes.
>Or you read ``<2bmtqp$n...@panix.com>'', in that article it says:
>this is one way to exploit the bug, many otehrs are variations of
>headers x, y ,z. Suppose you try all of these. Works on some
>machines, but not on certain other machines. Sysadmin thinks,
>ah, those machines are safe. NOT!
Given.
So, let us not keep sniping at each other, shall we ?
Instead, let's go and teach the bastards how to administrate their
systems properly.
- alec
Jon Allen Boone
Let me preface my remarks with the following caveats.
1) I know Jim Duncan and consider him a friend, good guy, white hat,
etc.
2) I have a few friends at the CERT, whom I also consider good guys,
white hats, etc.
3) I was grateful for the posting, since it allowed me to exploit the
hole, determine for myself how extensive the damage might be, and
convince the "uppers" that this is important and deserves
immediate attention.
j...@math.psu.edu (Jim Duncan) writes:
> I regret to say this, but Kyle's right and you're wrong. We need all the
> time we can get.
Agreed.
Scott D. Yelich
Roger> The number of sendmail related incidents, as reported to CERT, went up
Roger> _dramatically_ within a couple of hours of your post to the net. Do
Roger> you really think all crackers are so expert that they already knew
Roger> about this hole? That's a particularly self-serving viewpoint.
>> You just watch. I'll be waiting.
>> John Hawkinson
Roger> Thanks to the bad Internet citizens like John I suspect we'll soon be
Roger> seeing legislation to criminalize this sort of thing. I will lament the
Roger> restrictions on our currently free forum. I will not lament seeing
Roger> criminals paying restitution.
Roger> Roger Marquis
oh come on... I guess we're starting tha argument all over again.
GUNS DON'T KILL PEOPLE, PEOPLE DO.
or something like that.
The day that knowledge becomes illegal will be a truly sad day. I
think what you and perhaps Jim were talking about is "liability" ...
ie: panix admin posts a ``cookbook' and joe-freshman uses it to crack
his local domain.... and his lawyer or the local domain tries to prove
that the poster of the '`cookbook'' is liable.
if a gun is purchased at a shop and is then later used in a crime-- is
the shop owner liable? I thought I heard some distressing news about
bar tenders/owners being successfully sued for selling drinks to
people who later drove or caused some accident. We've seen cigarette
manufacturers successfully sued. It'll be a real shame if Information
because illegal.
I think I'll go burn some source-code printouts.
Scott
Jon Allen Boone
Let me preface my remarks with the following caveats.
1) I know Jim Duncan and consider him a friend, good guy, white hat,
etc.
2) I have a few friends at the CERT, whom I also consider good guys,
white hats, etc.
3) I was grateful for the posting, since it allowed me to exploit the
hole, determine for myself how extensive the damage might be, and
convince the "uppers" that this is important and deserves
immediate attention.
j...@math.psu.edu (Jim Duncan) writes:
> I regret to say this, but Kyle's right and you're wrong. We need all the
> time we can get.
Agreed.
> When CERT first reported the sendmail problem a few weeks ago, I agree, it
> was too weak, and the first thing I did was call our FIRST representative
> and ask her to get more information.
I don't have a FIRST affiliation and was not able to get more
information, despite my "contacts" at the CERT.
> The second notice, however, was much more useful, and I knew I needed to
> upgrade to sendmail-8.6.4 (I had installed 8.5 in September). The second
> advisory told me everything I needed to know. I maintain a network of over
> a hundred machines, most of them a cohesive network of SPARCstations running
> SunOS 4.1.3.
The second advisory (presumably the one I recieved on Thursday Nov
04, 1993) was more useful, but still seemed to be a bit misleading.
If the smrsh tact had been taken, then people here would likely have
left themselves open to attacks by _other_users'_accounts_ since
they would have, no doubt, included mail processing programs like
filter, slocal, etc. in the smrsh path. That bit of the followups
was definitely useful.
> Posting the details of how to exploit the hole, however, was an
> unconsionable act, and it really made me angry.
I have to disagree with Jim here. I found it very helpful (I had
been close to finding it myself before I saw the post) as I
mentioned before. Philosophically, I would be happier if I knew the
details of _more_ of these bugs. I seem to lack the necessary
knowledge/immagination to exploit the CERT advisories w/out aid --
perhaps that's why I never made it as a CRACKER. :-)
> The problem suddenly went from something that I needed to fix this
> week to something I needed to do in fifteen minutes.
Yes, but this urgency helped me get the point across. We _need_ a
full-time (or at least 1/2 time) security person -- not just people
who do it as a second or third priority. We need *proactive*
security instead of *reactive*. Needing to be reactive in a short
amount of time helps get this point across.
> Contrary to what many of you believe, most of the problems come from hacker
> wannabees, who *don't* have the wherewithall to figure out these holes for
> themselves. They need cookbook instructions. Suddenly, attacks sprung up
> all over the place (I'm inclined to believe Ed DeHart) because the wannabees
> suddenly had a new toy to play with.
I believe this. Under _any_ model of the world where there are
people who would like to be able to exploit security bugs (for
whatever harmless or innocuous reasons they may or may not have) and
_some_ of those people are _not_ unix wizards and are _not_ in
contact with people "in the know", you have just increased the set
of potential attackers.
We can argue about the size of this set all day if we want to.
> I think CERT is a useful thing, and I hope they continue. There have been
> some mistakes, but I think they do the best job they can in a society where
> there are thousands of people just waiting to sue the first "deep-pockets"
> victim that stumbles. The plans others have made to provide in-depth
> reports about holes are fraught with disaster. As soon as someone suffers a
> loss as a result of rapid availability of dangerous information, you can bet
> the lawyers will come knocking.
This will be interesting. I wonder if we need to press for a
"revamping" of the legislation. Is a person who provides
information on building pipe bombs liable for the use someone makes
of that information? How has the publishing industry survived this
long?
/*****************************************************************************/
/* Jon `Iain` Boone Network Systems Administrator bo...@psc.edu */
/* ia...@cmu.edu Pittsburgh Supercomputing Center (412) 268-6959 */
/* I don't speak for anyone other than myself, unless otherwise stated!!!!!! */
/*****************************************************************************/
Scott D. Yelich
Kyle> How about admins who have hundreds of systems to fix, even after
Kyle> they notice the posting? Perhaps you can't imagine the
Kyle> logistical horrors involved in doing such an update on short
Kyle> notice, but I can.
I hate to get picky and talk about specifics, but mail does get queued
you know. You can easily either disable the sendmail daemon or block
the port at a router or whatever. When your systems come back
online-- so will your mail. (More in the last paragraph)
Did you notice how many systems went COMPLETELY "off the net" during
the '88 worm? What about this time? What about when the syslogd
problem was first reported. How many systems are still on the net and
still have syslogd vulnerabilities? The effect is much the same as
the current sendmail bug-of-the-month.
To me, it is unthinkable to attach a new network to the Internet and
not even think of the idea of "security." This does not mean that you
have to make Security a 24hrs a job day as was mentioned before, but
it does mean knowing if a new potential problem has come up. If you
have networks attached to the Inetnet that use simple passwords (ie:
the "standard" -- then you should (or at least I would) assume that
any DETERMINED cracker could get access to your system with relative
ease.)-- this can be shown with extensions to the recent "panix"
incident. The problem we all face is that to make systems more
secure, it usually means a trade-off for what functionality is
provided-- do you really need a T1 connection to the Internet if
everything is blocked except sendmail to 1 host?
``Internet Security'' is an oximoron... at least for now.
Scott
William Unruh
>Pardon the obscenity:
No I don't. You took a position you KNEW was controvertial. The poster
pointed out one of the arguements against your actions. You have no
right then to start swearing at them. You have to live with your own
moral positions and try to defind them rationally, not start calling
people names. It is a fact that no matter how many disclaimers you put
on your actions, other people will assume that that if their system
passes the tests, it is safe. That you don't happen to like that featue
of the world, that you wish people would behave differently,
is your tough luck. It is precisely because the world, which includes
other peopla, does not conform to simple models is precisely what makes
moral decisions so difficult. Your posting makes you sound like an
theorist who rails against the anyone who points out that the moon
actually isn;t made of green cheese.
The people who advise not releasing details do not do so because of
malice of desire to hide things or for any other nefarious purposes.
They have their rational and moral reasons, grounded in certain aspects of the
real world, as do you. To imply that anyone who disagrees with you is an
idiot or evil, simply makes the bunch of you at Panix look like you have
not thought the matter through at all, even though I am sure you have.
Jim Duncan
Kyle, the CERT advisory came out on November 4, late in the evening
EST. CIAC followed up with its own advisory at around 2:00 am EST.
an1...@anon.penet.fi posted his/her revelations on the evening (by
EST) of November 7, and this was shortly followed by a posting from
ale...@panix.com supplying his fix-for-a-fix and promising more
details.
Two of these three days were on a weekend.
It was not until around 24 hour later, on the evening (by EST) of
November 8, that the posting by jh...@panix.com appeared. By then, any
site admin who was concerned about the CERT advisory and willing to act
purely on rumor should have installed the proposed fixes: disabling the
prog mailer, or installing smrsh. There had been four days of
warning. You didn't have to get up at 3:00 am to check Usenet.
And this tack of reasoning is remarkably devoid of any consideration to the
wide variety of concerns *other* than strictly technical, sysadmin concerns.
Any revelation of a serious security problem should be followed some
time later by enough details to let site administrators understand,
diagnose, and fix the problem, and verify the fix. The only question
is: How much later? Had CERT, CIAC, or Whoever Else had a sensible
policy of doing so, I'm sure an1...@anon.penet.fi, ale...@panix.com,
and jh...@panix.com could have been happy to wait. But they knew it
wan't going to happen, and they took it upon themselves (thanks, guys)
to let the rest of us in on the information, so we could make some
intelligent decisions of our own.
They released it too quickly, if they had to release it all.
I'm sure there are logistical horrors involved in updating a large
number of systems at short notice. That's part of the game. You can
count on having to do it once every couple of years. It's this sort of
thing that makes system administration one of the better paying jobs.
And it's this line of reasoning which sets sysadmin back a hundred years in
terms of responsible action, maturity, and planning. And this is *not* a
good-paying job; it's a s**t job. Haven't you noticed that the same thing
which happened to secretarial work after the invention of typewriters is
happening to sysadmin? It's becoming a clerical job, and the pay and
respect is dropping with this change.
Is the network world a little more secure today than it was on
November 4? You tell me.
We are slowly and steadily improving the security of our network, and it's
an ongoing task. The CERT post told me everything I needed to know; turn
off the prog mailer, or install smrsh, or upgrade to sendmail-8.6.4. What
more do folks need to know?
The post came at a very bad time for me, and talking to some other folks it
was bad for them too. My wife is expecting a baby any day now, a four month
old two gigabyte /usr/local went south, the /usr partition on another
fileserver/gateway went belly-up, and in the middle of all this someone
posts details on how to exploit the latest sendmail hole. I was planning to
do the upgrade to sendmail-8.6.4 the next morning anyhow, but instead I laid
awake all night, staring at the ceiling, wondering what might happen.
I realize (and agree) that sysadmin is a twenty-four hour job, but I
*resent* someone else dictating my schedule for me. The CERT posting had
all the information I needed, yet didn't advertise how to exploit the hole.
The later posting containing details made it possible for every single
weenie on this campus to go play with sendmail. That's reprehensible.
Matthew T. Russotto
>Thanks to the bad Internet citizens like John I suspect we'll soon be
>seeing legislation to criminalize this sort of thing. I will lament the
>restrictions on our currently free forum. I will not lament seeing
>criminals paying restitution.
If we have to hold our tongues for fear of legislation, it is not a
free forum NOW.
Personally, I think that in the medium and long term, dissemination of
cracking information will lead to security holes being fixed and
distributed in a timely manner.
Rahul Dhesi
>In the CERT advisory it said: sendmail is a risk, only 8.6.4 is know
>to be safe. A sysadmin worth his salt should change hist sendmail
>daemon.
...
>So, in the end, whatever the outcome of his experiments HE MUST REPLACE
>SENDMAIL. So what use are the experiments? Why not trust CERT then?
Actually CERT said to either use 8.6.4 or install smrsh. I believe
CERT's advice may be erroneous, and that smrsh may not be enough.
(Smrsh certainly is not enough to prevent the intruder supplying
arbitrary arguments to the piped command, and CERT didn't warn us about
that.) I believe that the problem is not just with pipes, but with any
alias, in the header sender (e.g., pathname, :include:, anything
else). Sendmail does alias resolution with insufficient checks for
which user owns the alias, and it appears to assume in some cases that
daemon (or worse, root, for :include:) owns the alias.
CERT does not generally provide complete or accurate information. (I
am, of course, willing to be proven wrong.) The Panix guys tell me as
much as they can. CERT tells me as little as it can. Who should I
trust more? A few days after the warning Neil Rickert posted a patch
for IDA sendmail. It could have been a few days *before* had CERT
contacted him and Eric Allman in advance.
Tom Fitzgerald
> I regret to say this, but Kyle's right and you're wrong. We need all the
> time we can get.
> Posting the details of how to exploit the hole, however, was an
> unconsionable act, and it really made me angry. The problem suddenly went
> from something that I needed to fix this week to something I needed to do in
> fifteen minutes.
It was already something you needed to do in 15 minutes. Posting the hole
did you a favor, because it saved you the possibility of coming in on
Monday to find your disks wiped. I honestly don't see how you could
believe that no crackers knew about the code until it was posted - and if
any of them knew it, then you were too exposed to spend a week before
fixing it.
CERT did you a disservice by hiding the problem from legitimate admins
until last Friday, when you could have dealt with it before.
And, for the rest of us, posting the hole was invaluable, because it let us
determine which of hundreds of dissimilar systems were clearly vulnerable
and had to be dealt with immediately. Of course, since nobody could say
for sure what systems (if any) were safe, they all had to be plugged, this
was just a matter of setting priorities.
--
Tom Fitzgerald Wang Labs, Lowell MA, USA fi...@wang.com 1-508-967-5278
Mitch Wright
>And note that it isn't only what you write what is important, also
>what other people read into it. The fact remains, all versions of
>sendmail are vulnerable (except 8.6.4).
>
This might be true for the "out of the box" versions of sendmail, BUT
what about the version I got off the net (lets say IDA), and that I
made a substantial number of changes to? Did I inadvertantly fix the
bug? If so, I would like to know before going out and having to fix
things that aren't broken. I barely have enough time to fix things that
are broken.
>And believe me, various people have tried to break our sendmail daemon,
>non succeeded. But I know for sure that a the bug is in that daemon.
>With slightly more esoteric ways it is possible to break the daemon, but
>those methods add one important step, as yet unmentioned.
>
One thing doesn't jive quite well with me about some of the whining going
on out there. We have a couple of facts that I think everyone can agree
on (yeah, right):
1) Wanna-be crackers, not knowing how to exploit the bug, now
know because of this posting.
2) The posting doesn't show how to exploit it on ALL systems
due to configuration differences and such.
3) SOME sysadmins will use that script as a "litmus test" and
most likely think they are safe when they might not be.
4) SOME sysadmins can use the information to FIX the bug.
Conclusion #1
If the admins under #3 are being attacked by the crackers described
under #1 there should be little or no concern. If it didn't work
for the admin, it won't work for the wanna-be.
NOTE: This doesn't make him safe from a more proficient cracker,
but that person most certainly didn't need the posting to do it.
Conclusion #2
The admins in #4 now have more information (enough?) to fix
the problem to ward off #1's *AND* the proficient cracker.
Conclusion #3
Posting the information put everyone on a more even ground when
it comes to the ability to exploit and FIX the problem. Before
the posting, the "exploiters" had an edge.
Conclusion #4
If people would spend more time fixing their systems rather than
crying about them being broken on USENET...
I like most of the people reading this was very concerned about the
reported sendmail bug. I wasn't necessarily thrilled about the idea
that some N (N is large) more people being able to beat on my sendmail,
BUT now I was one of the people that could beat on it AND FIX it.
Something tells me that most (if not all) of the folks that think the
details of the hole shouldn't have been posted ALREADY knew how to
exploit it.
My closing remark is a question to all those complaining about the
posting:
What would you say if I told you (Casper, Jim, ...) if I
know right now how to get root on your respective systems,
via the network? I know, some friends know, CERT knows,
and OH, by the way it's being widely used by crackers!!
Heck, I'll even give you a patch for it, but I won't say
what the bug is -- you know those wanna-be...
Am I kidding? Maybe.
Regards,
~mitch
Mark E. Mallett
>seeing legislation to criminalize this sort of thing. I will lament the
>restrictions on our currently free forum. I will not lament seeing
>criminals paying restitution.
I appreciate John's posting. I had already installed smrsh, as well
as sendmail 8.6.4 (heck, I was in the middle of it anyway), but
finally I knew why and could evaluate what I had previously done out
of blind faith.
Frankly I find the CERT advisories -- which often read something like:
"there's a bug somewhere, and if you whisper the right words to your
vendor, providing that you have one, you might get a fix for it" --
frustrating. I, probably like everyone reading this group, have a
responsibility to a lot of people, and I'm grateful for specific
information about specific problems.
-mm-
--
Mark E. Mallett MV Communications, Inc./ PO Box 4963/ Manchester NH/ 03108
Bus. Phone: 603 429 2223 Home: 603 424 8129
Looking for Internet access in southern NH / northern MA? Try MV!
Mail to in...@mv.mv.com for autoreply, or login as "info"/ 603-424-7428 (7E1)
Dave Hayes
>litmus test.
And why not? The people needed *something* with which to find out
if they had *any* hole or not...
>If you're posting about a security hole and how to exploit it, post
>properly. Don't do a half-hearted job.
So, then...no one should post anything unless they know *all* the holes?
I don't think this is workable.
>In the CERT advisory it said: sendmail is a risk, only 8.6.4 is know
>to be safe. A sysadmin worth his salt should change hist sendmail
>daemon.
Not all sysadmins have time to keep up with the latest elitisim of
security people. Some barely have time enough from serving their
users to read their mail. Are these people not worth their salt?
>So, in the end, whatever the outcome of his experiments HE MUST REPLACE
>SENDMAIL. So what use are the experiments? Why not trust CERT then?
It's hard to trust someone who doesn't trust you. Ever tried to?
--
Dave Hayes - Institutional Network & Communications - JPL/NASA - Pasadena CA
da...@elxr.jpl.nasa.gov da...@jato.jpl.nasa.gov ...usc!elroy!dxh
Most anything that annoys you is a mirror.
matthew green
>Kyle, the CERT advisory came out on November 4, late in the evening
>EST. CIAC followed up with its own advisory at around 2:00 am EST.
>an1...@anon.penet.fi posted his/her revelations on the evening (by
>EST) of November 7, and this was shortly followed by a posting from
>ale...@panix.com supplying his fix-for-a-fix and promising more
>details.
>It was not until around 24 hour later, on the evening (by EST) of
>November 8, that the posting by jh...@panix.com appeared. By then, any
>site admin who was concerned about the CERT advisory and willing to act
>purely on rumor should have installed the proposed fixes: disabling the
>prog mailer, or installing smrsh. There had been four days of
>warning. You didn't have to get up at 3:00 am to check Usenet.
but you did need to get a usenet feed that isn't lagged.
in the past few months (it has been better just recently),
i have often read news that was posted 1 or even 2 weeks
ago.
maybe i need to be up 10 days ago to be sure that i know
everything i need to to keep my system secure (we never
had a Mprog line to begin with).
i don't know how i feel about making security flaws public.
i've read this thread since it started, and i am still
unsure what is good and what is bad. as far as i can tell,
`both' stances have their good and bad points, but neither
is able to adequately refute the good points of the other.
maybe someone else has a better idea that works. i
certainly hope so.
.mrg.
ps. someone meantioned to me that sendmail 8.6.4 was indeed
susceptible in some way, but was not forthcoming on any
details. does anyone know if this is true and if the ida
patch still doesn't fix this problem? [i have no more
details on this, and do not want to create a panic, but i
feel this is important enough to risk it]
Matt Blaze
>If you weren't deliberately suffering from memory loss in a pitiful attempt to
>hold your tenuous ground, you might observe that we
>
>FUCKING WELL TOLD EVERYONE THAT IT WASN'T A LITMUS TEST
>
although he did quickly post a clarification after I (and I assume others)
called this to his attention.
You know, I generally support the notion that security problems are best
delt with by making them public, and I've tried to be as forthcoming as
possible in helping both to secure specific sites and getting general
fixes widely distributed. Lots of people have been working hard on
this latest problem, and the discussion on usenet has helped make things
like smrsh more secure and more useful.
Your abuse of everyone who doesn't agree with you or who questions something
you said (calling people lazy and incompetent for example), serves neither
to encourage people to help you nor to participate in the kind of
free discussion you claim to be advocating. What, exactly, are you
trying to accomplish?
-matt
Thor Lancelot Simon
Then learn to stick up for yourself. Supply and demand still holds true: if
you have skills which are in demand in the marketplace, you will get a fair
price.
>which happened to secretarial work after the invention of typewriters is
>happening to sysadmin? It's becoming a clerical job, and the pay and
>respect is dropping with this change.
>
> Is the network world a little more secure today than it was on
> November 4? You tell me.
>
>We are slowly and steadily improving the security of our network, and it's
>an ongoing task. The CERT post told me everything I needed to know; turn
>off the prog mailer, or install smrsh, or upgrade to sendmail-8.6.4. What
>more do folks need to know?
You still don't get it, do you? You _still_ think smrsh is an acceptable
mathod of dealing with this problem?
This is the legacy CERT has given us.
>The post came at a very bad time for me, and talking to some other folks it
>was bad for them too. My wife is expecting a baby any day now, a four month
>old two gigabyte /usr/local went south, the /usr partition on another
>fileserver/gateway went belly-up, and in the middle of all this someone
>posts details on how to exploit the latest sendmail hole. I was planning to
>do the upgrade to sendmail-8.6.4 the next morning anyhow, but instead I laid
>awake all night, staring at the ceiling, wondering what might happen.
Well, why didn't you stay awake for another ten minutes and turn off your prog
mailer? Then you could have slept all night, and dealt with the rest of the
problem in the morning!
>I realize (and agree) that sysadmin is a twenty-four hour job, but I
>*resent* someone else dictating my schedule for me. The CERT posting had
The above two statements are inconsistent.
>all the information I needed, yet didn't advertise how to exploit the hole.
It obviously didn't contain all the information you needed, since you still
think that smrsh is a valid solution as described in the CERT posting. Grrr!
>The later posting containing details made it possible for every single
>weenie on this campus to go play with sendmail. That's reprehensible.
Ever consider a lower-stress job?
--
Thor Lancelot Simon t...@panix.COM
"When I wanna talk sense to you, it's like spitting at the rain." -- Op Ivy
Thor Lancelot Simon
>Among other things, t...@panix.com (Thor Lancelot Simon) writes:
>>If you weren't deliberately suffering from memory loss in a pitiful attempt to
>>hold your tenuous ground, you might observe that we
>>
>>FUCKING WELL TOLD EVERYONE THAT IT WASN'T A LITMUS TEST
This is inexcusably rude. I am ashamed to have written it.
>>
>Let's be fair here. jhawk's original post was not at all clear on this point,
>although he did quickly post a clarification after I (and I assume others)
>called this to his attention.
>
>You know, I generally support the notion that security problems are best
>delt with by making them public, and I've tried to be as forthcoming as
>possible in helping both to secure specific sites and getting general
>fixes widely distributed. Lots of people have been working hard on
>this latest problem, and the discussion on usenet has helped make things
>like smrsh more secure and more useful.
>
>Your abuse of everyone who doesn't agree with you or who questions something
>you said (calling people lazy and incompetent for example), serves neither
>to encourage people to help you nor to participate in the kind of
>free discussion you claim to be advocating. What, exactly, are you
>trying to accomplish?
Good question. I believe I owe everyone involved an apology.
Peter Busser
>mar...@netcom.com (Roger Marquis) writes:
>>Come on John, I've read and heard LOTS OF NEGATIVE CRITICISM of your post.
>>Are you blind? Personally I think it was incredibly shortsighted,
>>inconsiderate of the entire population of Internet connected system
>>administrators, and just plain stupid.
>And *I* think it was necessary to the long-term safety of the Internet
>community as well as being incredibly helpful to those not in the security
>elite.
And don't forget that a CERT advisories like "upgrade your sendmail" does not
help people who use work-alike software like smail.
Groetjes,
Peter Busser
--
Linux, the choice of a GNU generation.
Peter Busser
>In <marquisC...@netcom.com> Roger Marquis writes:
>>Thanks to the bad Internet citizens like John I suspect we'll soon be
>>seeing legislation to criminalize this sort of thing. I will lament the
>>restrictions on our currently free forum. I will not lament seeing
>>criminals paying restitution.
>If we have to hold our tongues for fear of legislation, it is not a
>free forum NOW.
Not exactly true. There are 3.750.000.000 people who don't live under US
legislation, so they are not affected in any way. For those 250.000.000 who
live in the States there are workarounds. One can post an anonymous posting,
or ask someone from abroad to post it.
>Personally, I think that in the medium and long term, dissemination of
>cracking information will lead to security holes being fixed and
>distributed in a timely manner.
Seconded.
Kyle Jones
> cas...@fwi.uva.nl (Casper H.S. Dik) writes:
> > In the CERT advisory it said: sendmail is a risk, only 8.6.4 is know
> > to be safe. A sysadmin worth his salt should change hist sendmail
> > daemon.
>
> Not all sysadmins have time to keep up with the latest elitisim of
> security people. Some barely have time enough from serving their
> users to read their mail. Are these people not worth their salt?
And therefore blatting step-by-step instructions how to exploit
the hole to the net is the answer? I don't see the logic here.
Matthew T. Russotto
>t...@panix.com (Thor Lancelot Simon) writes:
>
>>That's really interesting. You're saying CERT abandoned their "information
>>black hole" position just so they could tell you this? The only thing I've
>>ever heard from them along these lines is "we cannot give information on other
>>incidents."
>
>No, he is probably saying that Ed DeHart of CERT made this comment to probably
>a couple of hundred Sys Admins who were at the CERT BOF at the LISA conference
>last week (and yes I was there to hear him say it), not just to him. Mr DeHart
>also pointed out that under US law it is possible (note the possible!) that the
>person that made the post could be sued by one of the sites that got broken
>into, and that the same possibilty exists if CERT had made such a post.
Under US law, you can sue for anything-- the only questions are whether
you win and how much trouble you can cause if you don't. Here's an
analagous situation, though: The TV show "MacGyver" demonstrated, step
by step, how to build a "Drano bomb". Many children tried out the
procedure, and were probably quite delighted when it worked. However,
at least one child was injured when the thing went off in his hand. You
don't see "MacGyver" being sued.
CERT is probably trying to bring up lawsuits in order to attempt to shut
people up so they don't look silly.
Alec Muffett
>CERT is probably trying to bring up lawsuits in order to attempt to shut
>people up so they don't look silly.
Nah, that's too paranoid. Occam's razor applies, and anyway, it's a
rare quango which can afford to indulge a vindictive or malicious
streak...
You have to be in the treasury department to do that sort of thing.
8-)
I think that CERT are merely expressing their fears; fear of being sued
or fried alive is probably what makes them so reticent about publishing
*detailed* explosions of security holes.
- That's why it's up to us.
Graham Toal
:>into, and that the same possibilty exists if CERT had made such a post.
:
:Under US law, you can sue for anything-- the only questions are whether
:you win and how much trouble you can cause if you don't. Here's an
:analagous situation, though: The TV show "MacGyver" demonstrated, step
:by step, how to build a "Drano bomb". Many children tried out the
:procedure, and were probably quite delighted when it worked. However,
:at least one child was injured when the thing went off in his hand. You
:don't see "MacGyver" being sued.
:
:CERT is probably trying to bring up lawsuits in order to attempt to shut
:people up so they don't look silly.
What happens if someone breaks into your system, and you later discover
that CERT knew about the hole for ages, but was keeping quiet about it?
Would you then be in a position to sue CERT for negligence? (Are they
Government funded? Having taken on this role, do they have any legal
obligation to make the info available? I suspect not, but I'd like
to here what the net IANALBs think...)
G
Dave Hayes
>Dave Hayes writes:
> > Not all sysadmins have time to keep up with the latest elitisim of
> > security people. Some barely have time enough from serving their
> > users to read their mail. Are these people not worth their salt?
>And therefore blatting step-by-step instructions how to exploit
>the hole to the net is the answer? I don't see the logic here.
Not "cookbook how to exploit" but "what causes and how to patch". Not just
"how to patch" because some people may not be able to patch unless they
understand the causes.
Once causes are more understood and less mysterious, some SAs will do
the right thing *before* the advisories come out.
--
Dave Hayes - Institutional Network & Communications - JPL/NASA - Pasadena CA
da...@elxr.jpl.nasa.gov da...@jato.jpl.nasa.gov ...usc!elroy!dxh
Angels can fly because they take themselves lightly.
Roger Marquis
>I appreciate John's posting. I had already installed smrsh, as well
>as sendmail 8.6.4 (heck, I was in the middle of it anyway), but
>finally I knew why and could evaluate what I had previously done out
>of blind faith.
Good for you. Obviously you have enough time on your hands to hack on
sendmail source but what about the other 97% of internet sysadmins? I
suppose they're simply out of luck, especially those who were broken into
as a direct result of John's post?
Maybe I'm old fashioned but this argument seems profoundly egocentric.
"I patched my sendmail, now how about posting some cracking code?"
Doesn't the greater good rate consideration?
Roger Marquis.
Roger Marquis
>Inconsiderate of the entire population of Internet connected _lazy_,
>_incompetent_ system administrators, who in my opinion have to learn to swim
>or be let sink. Yes, I include you in this estimation.
An excellent example of the self-serving attitude which exemplifies the
cracker (and criminal) community.
>Any cracker who couldn't figure out the hole John posted about, given the
>original anonymous post, was such a fool that I doubt he could have used
>John's help.
Fool or not it's clear that many crackers did require John's code to break
into other systems.
>"spate of attacks" occurred, you could have used to to turn off the prog
>mailers on your hosts and get to work. If you knew how to or had motive to
>get to work.
If only it were so easy. Simple minded solutions for simple-minded admins
I guess. Unfortunatly our site is not yet on the 'net'. At this rate audit
is not going to ever approve of it either. We simply don't have the
manpower to dedicate someone full-time to reading this group. In your mind
that apparently disqualifies us for internet worthyness.
>ROTFL. And just how long have _you_ been an "Internet citizen", sir?
Is it my imagination or do posters with little substance behind their
arguement frequently site irrelevant counter-arguments? I think 6
years on the net should 'qualify' me to reply to this post.
>I don't think you quite "get it" yet...
>Thor Lancelot Simon t...@panix.COM
Hey, that's my line...
Roger Marquis
Christopher Samuel
mar...@netcom.com (Roger Marquis) doodled:
> Maybe I'm old fashioned but this argument seems profoundly egocentric.
> "I patched my sendmail, now how about posting some cracking code?"
> Doesn't the greater good rate consideration?
Sigh, this was already being generally exploited, and my guess is that
if you'd gone onto IRC and asked around you'd probably been able to find
someone to tell you how to do it..
Personally I'm glad that it was disclosed, as it let me test our
non-sendmail mailer, which I would not have otherwise been able to do..
Chris
--
Christopher Samuel, Computer Unit, U.W Aberystwyth, Aberystwyth, WALES
E-mail: c...@aber.ac.uk PGP 2.3 public key available on request
"Some say the gods are a myth, - The Waterboys
but guess who I've been dancing with." "The Return of Pan"
Paul King
de...@enterprise.nrl.navy.mi writes,
> And you are really just kidding yourself if you think that crackers do
> not have any information before you do. Crackers have their own mailing
> lists to get this kind of info out.
The "Crackers" aren't the ones who benifit from posting the how-to
notification. It's the wanna-be crackers or the clueless newgrazer who
thinks this may be a nifty thing to try. If all the crackers knew about
it beforehand, why have we started seeing more attempts at this attack?
-Paul
Mark E. Mallett
>>I appreciate John's posting. I had already installed smrsh, as well
>>as sendmail 8.6.4 (heck, I was in the middle of it anyway), but
>>finally I knew why and could evaluate what I had previously done out
>>of blind faith.
>
>Good for you. Obviously you have enough time on your hands to hack on
>sendmail source but what about the other 97% of internet sysadmins? I
>suppose they're simply out of luck, especially those who were broken into
>as a direct result of John's post?
Just to be specific: Eric Allman et al hacked on sendmail source,
I merely installed it.
And maybe I'm reading this wrong, but you seem to be complaining that I took
the time to do the smrsh and sendmail installation. Somehow this seems
backwards to me. 97% of sysadmins didn't have the time to install smrsh?
It took me 10 minutes -- including examining the source code. What kind of
job description must these people have? As for having time on my hands,
well, it's almost 4am. NOW I have a few minutes on my hands.
>Maybe I'm old fashioned but this argument seems profoundly egocentric.
>"I patched my sendmail, now how about posting some cracking code?"
>Doesn't the greater good rate consideration?
I did not make that argument.
Is the greater good preserved by relying on a false tendency of
information to remain hidden?
Not knowing frustrates me. Not knowing, I still have to wonder if I'm
still vulnerable. And perhaps selfishly, I like to know about
security holes just for the sake of knowing. More than that, it is
frustrating to know that there is a problem that nobody will tell me
about; it is satisfying to know about a problem that I can personally
vouch for having a fix for. It is unsettling to think that somebody
is relying on obscurity to keep security holes hidden: more, that
somebody is making this decision for me.
Pat Myrto
/>t...@panix.com (Thor Lancelot Simon) writes:
/>
/ [ ... munch-munch ... ]
/CERT is probably trying to bring up lawsuits in order to attempt to shut
/people up so they don't look silly.
Or to preserve the status quo, which it seems they strongly favor.
--
p...@rwing.uucp [Without prejudice UCC 1-207] (Pat Myrto) Seattle, WA
If all else fails, try: ...!uunet!pilchuck!rwing!pat
WISDOM: "Travelling unarmed is like boating without a lifejacket".
[Stop the Clipper/Capstone assault on privacy]
Matthew T. Russotto
>russ...@vnet.IBM.COM (Matthew T. Russotto) writes:
>
>>In <marquisC...@netcom.com> Roger Marquis writes:
>>>Thanks to the bad Internet citizens like John I suspect we'll soon be
>>>seeing legislation to criminalize this sort of thing. I will lament the
>>>restrictions on our currently free forum. I will not lament seeing
>>>criminals paying restitution.
>>If we have to hold our tongues for fear of legislation, it is not a
>>free forum NOW.
>
>Not exactly true. There are 3.750.000.000 people who don't live under US
>legislation, so they are not affected in any way. For those 250.000.000 who
>live in the States there are workarounds. One can post an anonymous posting,
>or ask someone from abroad to post it.
If the problem is the THREAT of legislation, it doesn't matter what
country is being posted from. Any country could make legislation
forbidding revealing security holes. The US would probably have more
trouble than most countries in getting such legislation passed, as our
First Amendment does act as a slight deterrent on our Congress, and
our courts do pay attention to it quite often.
What I'm saying is: Don't worry about the threat of legislation. If
you refrain from speaking because you are afraid of having that speech
made illegal, you are no better off than if they do pass the legislation.
R Agent
(Matthew T. Russotto) writes:
[...]
>If the problem is the THREAT of legislation, it doesn't matter what
>country is being posted from. Any country could make legislation
>forbidding revealing security holes. The US would probably have more
>trouble than most countries in getting such legislation passed, as our
>First Amendment does act as a slight deterrent on our Congress, and
>our courts do pay attention to it quite often.
Hell, they could pass a law forbidding the _existence_ of security
holes. Doesn't mean they won't happen.
>What I'm saying is: Don't worry about the threat of legislation. If
>you refrain from speaking because you are afraid of having that speech
>made illegal, you are no better off than if they do pass the legislation.
Absolutely. It's funny, how I read about all the 'voluntary curbs'
Hollywood is considering. Then on the next page I read about the
'self-censorship' that is going on in Saudi Arabian media. Words are
powerful things.
RA
ro...@ccs.neu.edu (Rogue Agent/SoD!/TOS/KoX) - pgp key on request
-----------------------------------------------------------------
The NSA is now funding research not only in cryptography, but in all areas
of advanced mathematics. If you'd like a circular describing these new
research opportunities, just pick up your phone, call your mother, and
ask for one.
Roger Marquis
>And maybe I'm reading this wrong, but you seem to be complaining that I took
>the time to do the smrsh and sendmail installation. Somehow this seems
>backwards to me. 97% of sysadmins didn't have the time to install smrsh?
If you've never worked at a large site, where there are business
critical applications depending on mail, it might be a simple matter to
upgrade sendmail. If your job is on the line on the other hand, change
control is critical. Nothing gets changed without thorough testing and
management approval. It's not simply a matter of 'cp ./sendmail*
/usr/lib' at many Internet sites.
>Is the greater good preserved by relying on a false tendency of
>information to remain hidden?
I think the greater good, and CERT, is more concerned with keeping the
number of break-ins to a minimum than with reducing the number of security
holes. Are you arguing against this?
>Not knowing frustrates me. Not knowing, I still have to wonder if I'm
>still vulnerable.
It also frustrates all the hell out of 'wanna-be' crackers. This is
the reason CERT doesn't make this info available. After all, who's to
say which sites will use this info responsibly and which won't. CERT
simply isn't capable of making such an evaluation.
Roger Marquis