8LGM: The Future. Your views please.
H. Milton Johnson
Karl Strickland <ka...@bagpuss.demon.co.uk> wrote:
>We are currently considering what we can do to make our advisories
.
.
.
My only suggestion is to avoid posting on Friday, Saturday and
Sunday.
--
H. Milton Johnson Voice: (305) 585-7787
Systems Analyst Digital Pager: (305) 734-0050
UM/JM Burn Center Email: mil...@picard.med.miami.edu
Miami, FL emtek!jmh!milton
Karl Strickland
all input. If you have mailed me, or 8l...@bagpuss.demon.co.uk and
made your views known, then your views will be taken into account. If
you have posted your views here, they will be taken into account also.
Please recognise that it is impossible for us to please everybody.
Differences in time zones, working patterns, newsfeed latency and other
issues make it impossible for us to do one thing thats going to suit the
world. What we're trying to achieve is the best compromise possible, so
that more people find our `service' useful, and hopefully nobody will find
our service less useful.
We will not be posting further advisories until this `review' is complete,
and we have announced any changes that we may decide to make.
We are still committed to Full Disclosure. Having said that, this is
your chance to have some input on how we do things - we await your views
and (hopefully constructive) suggestions.
--
------------------------------------------+-----------------------------------
Posted using GNUS 4.1 on FreeBSD | Karl Strickland
PGP 2.3a Public Key Available. | Internet: ka...@bagpuss.demon.co.uk
"VI. THE SHELL" - BSD PS2:1-9 :-) | or: karl%mv...@bagpuss.demon.co.uk
Charles E Meier
My $0.02
Assume you find the security flaw/bug on day zero.
On day 1, mail the vendor and CERT an advisory that contains a description
of the bug, an exploitation script, and whenever possible, an interim
suggested fix. Give them 48 hours to look it over and reply.
On day 3, post the description of the bug and your interim suggested fix.
Unless day 3 falls on a Friday, and then wait till Sunday nite or Monday
morning to post. The description should contain enough information that
a competent programmer could write their own exploitation script. The 48
hour delay gives the vendor a chance to suggest modifications to the short-
term workaround in your fix.
Wait three weeks. This is a long enough time span that most sysadmins should
have received the bug report and had some time to put the interim fix in
place. Now again post the description of the bug, the suggested fix, AND NOW
include the exploitation script. The script should be "harmless" in the sense
that it should create file /var/tmp/foo rather than overwriting /etc/passwd
or whatever. This at least makes the ignorant "wannabe cracker" work a little
harder.
We get full disclosure out of this which I believe does put pressure on the
vendor to fix the problem in a timely manner. But the harm caused by letting
the half-competent crackers have immediate access to the explotation script is
lessened by the time delays given above. Finally, by giving the vendors a
pre-release of your usenet post, they might be a little more willing to
work with you to solve the problem. Building trust and solving problems is
what usenet/internet should be here for.
cem
Brad Powell
:In article <KARL.94Ma...@bagpuss.demon.co.uk>,
And don't post while I'm on vacation or near holidays :-)
Please check with me for vacation times first before posting.
:-) :-) :-) :-)
Sigh, there is NO WAY your going to solve this problem and not piss
*someone* off. Someone is going to be "out sick" or something no matte what.
Karl/Neil (whomever else in 8lgm) take a look at the way you post and modify
as *you* see fit.
Censorship of your right to post should be discouraged.
*I'd* suggest this time-line:
1) get the exploitation code or a good detailed writeup to the
vendor right away.
(yeah I know the e-mail path can be snooped; so anything going to
Mark....@Sun.COM or securit...@foo.com gets snooped once in a while;
so use PEM)
2)At the same time (or within a couple days) post a simple explanation of the bug,
and any workaround(s) possible to the net. Something that points to the bug
but makes the wannabee crackers do some work to create a exploitation script of
their own (they need education too). Heck maybe this will work better since when
a fix does come out there are more different exploit scripts to ensure it works
(keeps your vendor honest :-})
3) then followed up by the exploitation script. after N days.
I leave the "N days" days up to the user.
I'm willing to believe 8lgm is _trying_ to do what they percieve is the
right thing.
Time will tell.
=======================================================================
Brad Powell : brad....@Sun.COM |
|
Full Time: Sr. Network Security Analyst |Part time: Cyberspace PI
ENS Network Security Group | and Consultant
Sun Microsystems Inc. |
=======================================================================
The views expressed are those of the author and may
not reflect the views of Sun Microsystems Inc.
=======================================================================
Mike Connally
[snip]
> On day 1, mail the vendor and CERT an advisory that contains a description
|> On day 3, post the description of the bug and your interim suggested fix.
|> Wait three weeks. This is a long enough time span that most sysadmins should
|> have received the bug report and had some time to put the interim fix in
|> place. Now again post the description of the bug, the suggested fix, AND NOW
|> include the exploitation script. The script should be "harmless"
On the face of it, that seems a pretty good plan to me. Exact timings are subject
to debate (three weeks may be too long), but I like the idea of a three-stage process
as outlined.
[snip] Building trust and solving problems is
|> what usenet/internet should be here for.
Yes!
--
+-----------------------------------+--------------------------------------+
| Mike Connally, Systems Consultant | internet: Mike.C...@cdl.cdc.com |
| Control Data Limited | |
| 3 Roundwood Avenue | My opinions may or may not be my own.|
| Stockley Park, Uxbridge UB11 1AG | I borrow freely. |
| England | Share them at your own discretion. |
+-----------------------------------+--------------------------------------+
Karim Saouli
: In article <2rdkk3$g...@charm.magnus.acs.ohio-state.edu>, cem...@magnus.acs.ohio-state.edu (Charles E Meier) writes:
: [snip]
: > On day 1, mail the vendor and CERT an advisory that contains a description
: [snip]
: |> On day 3, post the description of the bug and your interim suggested fix.
: [snip]
: |> Wait three weeks. This is a long enough time span that most sysadmins should
: |> have received the bug report and had some time to put the interim fix in
: |> place. Now again post the description of the bug, the suggested fix, AND NOW
: |> include the exploitation script. The script should be "harmless"
: [snip]
: On the face of it, that seems a pretty good plan to me. Exact timings are subject
: to debate (three weeks may be too long), but I like the idea of a three-stage process
: as outlined.
But if as some peoples did suggest, sun was already knowing about the bugs and
didn't fix them I do not see the point to make such a 3 steps procedure, a 2
step procedure would be far more then enough.
If the bug correction on the security level would be as coherent as most of
the talks that are going around I don't think that 2,3,4 years old bugs would
have remained in an OS distribution.
There are inherantly weak points(networking), but why aren't things like
passwd, tar, mail and some 20 other "problem making" utilities been re-written?
they are release after release exactly the same. They do generate problems for
everyone (I guess that the avg time invested in modification of such
applications is to be evaluated at around 1000$ per system administrator,
that means that a few millions US$ are wasted because US$ 100000 were not
invested in debugging and security).The impact of the investment would be
something like $US 2 or 3[it could be US$ 20 it would still be a serious
saving] increase on the cost of each cd but wouldn't that
be good for The vendor and for the customers?
And as I said before a 2 steps operation with a delay of 2 weeks would be
enough for everyone to fix the security hole.
Regards,
K. Saouli
--
Karim Saouli Math Department of the
System administrator Swiss Fed. Inst. of Tech (ETHZ)
Room: HG G 14.2
S-Mail: HG G 14.2 Email: sao...@math.ethz.ch
ETH Zentrum Phone: ++41-1-632-2230
CH-8092 Zurich FAX : ++41-1-252-3401
Thomas M Kroeger
[snip]
: *I'd* suggest this time-line:
: 1) get the exploitation code or a good detailed writeup to the
: vendor right away.
: (yeah I know the e-mail path can be snooped; so anything going to
: Mark....@Sun.COM or securit...@foo.com gets snooped once in a
: while; so use PEM)
: 2)At the same time (or within a couple days) post a simple explanation
: of the bug, and any workaround(s) possible to the net. Something
: that points to the bug but makes the wannabee crackers do some
: work to create a exploitation script of their own (they need
: education too). Heck maybe this will work better since when a fix
: does come out there are more different exploit scripts to ensure it
: works (keeps your vendor honest :-})
: 3) then followed up by the exploitation script. after N days.
: I leave the "N days" days up to the user.
Hear Hear!!!
I'd say not too much time for N because some of us don't have the time to
write these scripts on our own, but still want the confirmation and detail
that they provide... Meanwhile we become vulnerable to those Crackers
that do have the free time for this. 2-3 days sounds fair!
As someone who's just starting up in a security position
and has been struggeling to learn as much as posible, these advisories have
taught me a great dea about security and what to look for. They've been
of far more value than all the noise about non-disclosure! Some of us
don't have the time, support and resources we'd like, and that security
deserves. I am extremely grateful to see someone offering the openness
that education has always been based on!
Thanks 8lgm, there's always a cold one waiting for you out this way.
The bottom line!!
: Karl/Neil (whomever else in 8lgm) take a look at the way you post and modify
: as *you* see fit.
: Censorship of your right to post should be discouraged.
--
tmk
-----------------------------------------------------------------------
Tom M. Kroeger Pray for wind
University of Hawaii Computing Center \ Pray for waves and
2565 The Mall, Keller Hall |\ Pray it's your day off!
Honolulu HI 96822 (808) 956-2408 |~\
e-mail: t...@uhunix.uhcc.hawaii.edu |__\
,----+--
Francisco X DeJesus
weekends" group.
'Nuff said,
--
_____ _ _ Francisco X DeJesus -/ S A I C /- dej...@c3ot.saic.com -{----
| ___/< \/ > ------------------------------------------------------- /
| __| > < [disclaimer: opinions are mine, typos and errors yours] \/> _
|_| <_/\_> "Hack the hardware, not the Constitution." -B. Sterling |#\/`
Neil Woods
Don't be suprised if I take you up on that, I could do with a few beers
after the past couple of weeks!
For this thread in general, we have pretty much decided that the following
will happen:
We'll publish early in the week (Mornings, Mon - Wed seems o.k. by most people?)
Exploit scripts won't leave you with a root prompt (even though in most
cases the vulnerability provides an easy route to this). We don't have any
problems in writing scripts in this manner.
Exploit scripts will be made available a few days after the original advisory.
I think the minimum suggested period is three working days, a week would seem the
best bet as it makes scheduling a bit easier for us and would guarantee everyone
that this too is provided early in the week.
We're also considering having scripts by request only (i.e. you have to fetch it
from the 8lgm fileserver, rather than mailing/posting it out to everyone.) This
will hopefully mean that sites banning our posts will no longer see fit to do so.
Views on that suggestion please!
Also should the discussion section remain in the original advisory, or should
this be provided with the script? Majority view dictates that it should go out
immediately, but if anyone has strong feelings against this, we will again give
greater consideration to such requests.
We are also going to try and put some sort of 8lgm FAQ together, which is a popular
request.
I'd just like to say I'm encouraged by recent announcements that we're
actually getting some progress!
Cheers,
Neil
--
Bull in the Heather, Me and My Charms, The Lights, Sensual World, Go, Ritual,
Handsome and Gretel, Take Me, Blue Room, Drunken Butterfly, She's Lost Control.
...like a badger with an afro throwing sparklers at the Pope...
Frank Peters
>We are currently considering what we can do to make our advisories
>more acceptable to EVERYONE, rather than just the majority. We welcome
>all input.
My 2 cents worth:
Don't post advisories on Fridays or right before common holidays. I'd
actually recommend that you only post in the mornings (to give 8 to 5
types a chance to get it the same day) and cut off after Thursday
morning but that might seem like overkill to some.
I don't feel that strongly about separating the fix from the
exploitation script but I don't think its a particularly bad idea and
if it makes more people happy...
--
Frank Peters - UNIX Systems Programmer - Mississippi State University
Internet: f...@CC.MsState.Edu - Phone: (601)325-7030 - FAX: (601)325-8921
Reto Lichtensteiger
[Big SNIP <g>]
I concur with Mr. Meier's sequence. Add one vote in the appropriate
column.
-Reto
--
R A Lichtensteiger
System Administrator ra...@hri.com
Horizon Research Inc (617) 466-8304
Q: What goes "Pieces of seven! Pieces of seven!"?
A: A parroty error!!
H. Milton Johnson
Neil Woods <ne...@legless.demon.co.uk> wrote:
>Don't be suprised if I take you up on that, I could do with a few beers
>after the past couple of weeks!
>
>We'll publish early in the week (Mornings, Mon - Wed seems o.k. by most people?)
>Exploit scripts won't leave you with a root prompt (even though in most
>cases the vulnerability provides an easy route to this). We don't have any
>problems in writing scripts in this manner.
No problem with this or a root prompt.
>Exploit scripts will be made available a few days after the original advisory.
>I think the minimum suggested period is three working days, a week would seem
>the best bet as it makes scheduling a bit easier for us and would guarantee
>everyone that this too is provided early in the week.
Why not say that the first advisory comes out on Mon - Wed with the exploit
script the following Monday?
>We're also considering having scripts by request only (i.e. you have to fetch
>it from the 8lgm fileserver, rather than mailing/posting it out to everyone.)
>This will hopefully mean that sites banning our posts will no longer see fit
>to do so. Views on that suggestion please!
Is it possible for them to ban just the post with the exploit script? If so
then do it that way. If you go with a fileserver then be prepared for a lot
traffic, especially if you move the discussion section to the script.
>Also should the discussion section remain in the original advisory, or should
>this be provided with the script? Majority view dictates that it should go out
>immediately, but if anyone has strong feelings against this, we will again give
>greater consideration to such requests.
The discussion should remain in the original advisory.
>We are also going to try and put some sort of 8lgm FAQ together, which is a
>popular request.
Excellent!
>I'd just like to say I'm encouraged by recent announcements that we're
>actually getting some progress!
>
>Cheers,
>
>Neil
Question: Since you are moving towards a "there's a hole, here's the
workaround, proof in a week" situation, would it be possible for
you to post signed (ala pgp) advisories so that tampering/forgery can
be eliminated?
[snip]
Thanks
Neil Woods
: In article <Cq3z...@legless.demon.co.uk>,
: Neil Woods <ne...@legless.demon.co.uk> wrote:
: >Don't be suprised if I take you up on that, I could do with a few beers
: >after the past couple of weeks!
: Anyone from 8LGM who comes to Miami has a 6-pack waiting.
Cheers! (I've got some "Best Bitter" here, but there's not
much "Best" in this can 8@)
: >Neil
: Question: Since you are moving towards a "there's a hole, here's the
: workaround, proof in a week" situation, would it be possible for
: you to post signed (ala pgp) advisories so that tampering/forgery can
: be eliminated?
: [snip]
Yes, we had decided to do this, I just forgot to mention it! The rest
of your post is taken into consideration, thanks for that.
Steve Uurtamo
>Don't post advisories on Fridays or right before common holidays. I'd
>actually recommend that you only post in the mornings (to give 8 to 5
>types a chance to get it the same day) and cut off after Thursday
>morning but that might seem like overkill to some.
Post whenever you feel like. If it makes you happy, post on weekdays, but
please, don't hold onto security problems without letting others know about
them. This only makes things worse.
>I don't feel that strongly about separating the fix from the
>exploitation script but I don't think its a particularly bad idea and
>if it makes more people happy...
If you don't release the exploitation script with the hole, you don't do
too much more than CERT. Sorry, but it's true.
I think that the exploitation script is the best thing that happened to
security advisories since 8lgm. It is the easiest way to figure out
EXACTLY how the hole works and what will and won't work to fix it. I'm
for full release on the first day. If security is important to your
sysadmin, he can install it. You've never released a hole w/o a fix, and
the fixes have never been rough to implement.
I say, all hail freedom of information.
John Caruso
>
>We're also considering having scripts by request only [...]
Please do post the scripts (after a week as you'd said you plan to do).
You might want to make the scripts available by request only during the
week waiting period, and then post them at the end of the week. That
way admins who didn't want to act on the fix information without details
could get the details first.
>Also should the discussion section remain in the original advisory, or should
>this be provided with the script?
I'd say include the discussion section in the original advisory. The
real problem with posting the scripts in the first advisory isn't that
experienced crackers will see it and use it, since they probably don't
need it anyway--it's that those *other* crackers (kids with too much
times on their hands, hey-look-a-script-let-me-try-it types) are given
a cookbook method to get root on a system. Having the discussion in
the advisory won't help these people. We had an unsuccessful crack
attempt here in which the attacker tried to use the rdist script, and
had obviously typed it in line for line since "BullInTheHeather" was
mistyped as "BullInTheHeater" :-). If there had been just a discussion
in the advisory and no script he wouldn't have had a clue about how to
exploit the hole.
---------------------------------------------------------------------
John Caruso car...@nova.umd.edu
Unix/VMS System Administrator caruso@UMUC (Bitnet)
University of Maryland University College (301) 985-7447
---------------------------------------------------------------------
Rahul Dhesi
(Karl Strickland) writes:
>We are currently considering what we can do to make our advisories
>more acceptable to EVERYONE, rather than just the majority. We welcome
>all input.
First of all, please don't even try to make them acceptable to
EVERYONE. I don't think it's possible. I think things are fine they
way they are. (See below for reason.) You might want to consider
releasing advisories only on Mondays, so sites that are unmanned on
weekends have some time to act on the advisories.
You could consider releasing advisories in two parts.
PART I. Sufficient information to figure out whether a problem exists,
and a quick work-around. This would be like a typical CERT warning,
but (I hope) with more specific information about how to figure out
whether one is vulnerable.
PART II. The rest of the story, as told in recent 8lgm postings. Part
II should come about two weeks after part I.
If you do the above, however, you will come under TREMENDOUS pressure
to not release part II. Many (most) vendors will prefer that you never
release part II. Then they don't need to fix the problem! They may
contact you, or your service provider, or local authorities, accuse you
of sabotage, etc. The pressure may be enough to prevent you from
releasing part II.
For this reason I think things are fine they way they are, other
than that it might help to release advisories only on Mondays.
--
Rahul Dhesi <dh...@rahul.net>
also: dh...@cirrus.com
Casper H.S. Dik
>PART II. The rest of the story, as told in recent 8lgm postings. Part
>II should come about two weeks after part I.
Two weeks would seem to be best.
>If you do the above, however, you will come under TREMENDOUS pressure
>to not release part II. Many (most) vendors will prefer that you never
>release part II. Then they don't need to fix the problem! They may
>contact you, or your service provider, or local authorities, accuse you
>of sabotage, etc. The pressure may be enough to prevent you from
>releasing part II.
I don't think so: if that was the case, 8lgm wouldn't have continued
operating past their first set of advisories.
Vendors should realise that their alternatives are worse. If 8lgm
is made to stop, others will start to post. The more responsible
8lgm seems to be, the less tempting it will be to take action.
Casper
Kevin Johnson
> On day 1, mail the vendor and CERT an advisory that contains a description
> of the bug, an exploitation script, and whenever possible, an interim
> suggested fix. Give them 48 hours to look it over and reply.
This assumes that all vendors are identifiable.
--
--
#include <std_disclaimer>
"Frank Zappa is dead - the world is a duller shade of gray" - me
.-----------------------------------------------------------------------------.
| Kevin Johnson k...@phx.mcd.mot.com |
| Information Technologies Network Administrator Motorola MCG |
| MCG postmaster, MCG Network Security Administrator |
Neil Woods
: Sorry to sound like a radical, but:
I can assure you a lot of people feel the same way, including ourselves
obviously, we're just trying to find a way that pleases as many people
as possible. I don't know if these changes are going to work, I can
envisage all sorts of problems cropping up. However we're prepared to
give it a try, if you don't like the way things turn out, let us know!
Bernd Felsche
ne...@legless.demon.co.uk (Neil Woods) writes:
[please "wrap" your lines before column 80]
>For this thread in general, we have pretty much decided that the following
>will happen:
>We'll publish early in the week (Mornings, Mon - Wed seems o.k. by
>most people?)
It can take 3-4 days to reach even "well-connected" sites and to be read!
Some administrators wear other hats too. I can be otherwise occupied
at remote locations for a few days, without access to news, especially
after a weekend.
>Exploit scripts will be made available a few days after the original
>advisory. I think the minimum suggested period is three working days,
>a week would seem the best bet as it makes scheduling a bit easier for
>us and would guarantee everyone that this too is provided early in the
>week.
A week is reasonable. It doesn't give the better-connected bunnies
from hopping onto remote systems which they know would be vulnerable.
I presume you that intend to send the advisory and exploitation
script to the vendor (a couple of days) prior to posting the advisory.
>We're also considering having scripts by request only (i.e. you have
>to fetch it from the 8lgm fileserver, rather than mailing/posting it
>out to everyone.) This will hopefully mean that sites banning our
>posts will no longer see fit to do so. Views on that suggestion
>please!
Please continue posting. One week should be enough time to remove
the vulnerability and to frustrate remote intruders short-circuiting.
>Also should the discussion section remain in the original advisory, or
>should this be provided with the script? Majority view dictates that
>it should go out immediately, but if anyone has strong feelings against
>this, we will again give greater consideration to such requests.
The discussion should adequately describe the nature of the
vulnerability, including some hint as to which configurations are
sensitive, without giving away the means of attack. It should not be as
vague as some security announcements from vendors which simply state
that "there's a problem - please update"!
A workaround/patch should always be provided with the initial advisory.
--
+-----+ Bernd Felsche, MetaPro Systems Pty Ltd ,,, Phone: +61 9 362 9355
| | | | ber...@metapro.DIALix.oz.au (o o) Fax: +61 9 472 3337
| | | | 328 Albany Highway, Victoria Park -oOO--(_)--OOo- Western Australia
|m|p|s| Dodging traffic on the information Super-Highway
matthew green
[ ... new description ... ]
i -like-. i espcially like the idea of mail serving the
scripts - makes it even harder for joe newbie to try to
be a cracker.
this idea has my support.
Paul Szabo
Woods) writes:
> For this thread in general, we have pretty much decided that the following
> will happen:
later by exploit scripts; scripts not to give root prompt ]
With such responsible attitude you will have my complete support. (Not that
it is worth the electrons it is written on...)
> Also should the discussion section remain in the original advisory, or should
> this be provided with the script? Majority view dictates that it should go out
> immediately, but if anyone has strong feelings against this, we will again give
> greater consideration to such requests.
Initial discussion should be enough to give a 'feel' for the seriousness or
veracity of the bug, but not enough to exploit it; in some cases this may
mean no discussion whatever in the initial advisory. Complete discussion
should come a week later, with the exploit scripts.
Paul Szabo - System Manager // School of Mathematics and Statistics
sza...@maths.su.oz.au // University of Sydney, NSW 2006, Australia
Neil Woods
: In article <Cq3z...@legless.demon.co.uk> ne...@legless.demon.co.uk (Neil
O.K, we'll do our best to find the right balance with the discussion section,
although this really depends on the nature of the vulnerability.
Can I just make this point, that even though a script will not be immediately
available, this does not mean that one should apply the fix at leisure. Given
even the sparse details of a CERT advisory, it is possible for many people to
piece together how to exploit the vulnerability. (Who knows, it may turn out
that other parties make a script available before ours!)
Christopher Samuel
cas...@fwi.uva.nl (Casper H.S. Dik) doodled:
> Vendors should realise that their alternatives are worse. If 8lgm
> is made to stop, others will start to post. The more responsible
> 8lgm seems to be, the less tempting it will be to take action.
Hear hear, just chucking in my 2 penneth in support of 8LGM as well.
I'll join Alec in buying Karl & Neil a drink if you can ever get me and
him into the same pub with you two.. :)
Chris
--
Christopher Samuel Phone: +44 684 895311 ch...@rivers.dra.hmg.gb
N-115, Defence Research Agency, St Andrews Road, Great Malvern, England, UK
"A hollow heart and an empty head make the streets run red" - The Levellers
PGP key available from keyservers.
Tom Fitzgerald
details a few days later.
I like the idea of publishing test scripts that say "secure" or
"Insecure!!!" but do not generate a root shell.
I do NOT like the idea of delaying posts until Monday when you find out
information on a Thursday or Friday. By then, rumors have already started
circulating around someplace (the Linux group, or bugtraq or whatever) and
you're delaying getting the information to the people who need it
*immediately*. The whole point of bugtraq and 8lgm were to get information
to admins without delay. Once 8lgm starts delaying the release of its
information, it's just another CERT, i.e. it's useless to us, we can't
depend on it, and someone will have to create another organization that
does do immediately postings, even on Friday.
Really, Monday is no better than any other day. Besides the timezone
problems, people go on vacations or get sick, different countries have
holidays on different Mondays, and there are delays that prevent news from
getting through. (When people say 'post only on Monday', they really mean
'post only when I'm at work', ignoring the fact that different people are
not at work at the same time.) Any site that wants to remain secure MUST
have someone checking in a couple of times over the weekend. If you let
your systems run unattended for 60 hours, it could be a smoking ruin when
you get in on Monday. If someone has to log in to check on things anyway,
they can just as easily check for security alerts.
For some reason, all the interesting security holes seem to show up on
Friday.... the sendmail hole, INN UCBmail hole, the rlogin hole, all of
these caught fire just as the weekend was beginning. Delaying 8lgm
postings won't change this a bit, because Friday is when the information
starts circulating around by other means, and that's when the breakins
could start happening.
--
Tom Fitzgerald Wang Labs Lowell MA, USA 1-508-967-5278 fi...@wang.com
Pardon me, I'm lost, can you direct me to the information superhighway?
Neil Woods
: In article <2rlu5t$r...@mail.fwi.uva.nl> of comp.security.unix,
: cas...@fwi.uva.nl (Casper H.S. Dik) doodled:
: > Vendors should realise that their alternatives are worse. If 8lgm
: > is made to stop, others will start to post. The more responsible
: > 8lgm seems to be, the less tempting it will be to take action.
: Hear hear, just chucking in my 2 penneth in support of 8LGM as well.
Thanks, we appreciate it!
: I'll join Alec in buying Karl & Neil a drink if you can ever get me and
: him into the same pub with you two.. :)
8lgm meets are always an excuse to get extremely drunk... well
actually, come to think of it, getting drunk is the only reason for
8lgm meets!
Colin Campbell
The consensus mseems to be post problem then post break-in script some
time later. With this I agree. The problem appears to be the length of
`some time'. A week sounds good but the time taken for the news to
reach the far reaches of the globe always leaves someone vulnerable for
up to a week, probably longer. Nasty people do not have to be in the
country of the host they attack. If a Nasty Person sees your post an hour
after it goes to air, that NP will have a week or longer to use your
breakin script to attack sites far removed on the news network.
Solution? Maybe. How about posting from a number of sites spread around
the globe to reduce the latency factor. I know there are people on the
various continents who support you. Get them involved in the release
procedure. Mail them `this week's hole' with instructions to post at
`06:00 GMT next Monday'. If the world gets hit from half a dozen spots
the time for Nasty People to attack gets reduced to hours/days instead
of weeks.
Colin
Karl Strickland (ka...@bagpuss.demon.co.uk) wrote:
[ lots of good stuff nobody wants to see again and only wastes bandwidth ]
Kevin Luster
>I do NOT like the idea of delaying posts until Monday when you find out
>information on a Thursday or Friday. By then, rumors have already started
>circulating around someplace
[8lgm] for the most part is not posting about the hot new bug of the week.
Their posts are about bugs which have been around for awhile. In which
case I vote for disclosing on a Monday.
-K
Tom Fitzgerald
> [8lgm] for the most part is not posting about the hot new bug of the week.
> Their posts are about bugs which have been around for awhile. In which
> case I vote for disclosing on a Monday.
While 8lgm's first few postings (that I have copies of, anyway) were
longstanding bugs, most of the ones since then have been new things. I'm
thinking of passwd -F, the /bin/mail bug introduced (or at least altered)
by the Sun patch, and the rsh -r -f bug. I don't recall whether there was
an 8lgm post about the AIX tprof bug, but that's another one that came to
light suddenly, with enough publicity that it's a good justification for
publicizing as soon as possible.
I still feel that if 8lgm doesn't post advisories as soon as they can,
someone else will, and people will stop paying attention to 8lgm. This
will happen the first time a site is broken into on a Saturday, using a
security problem that 8lgm knows of and is sitting on. Delaying posts
about known security problems is STO. It's extremely tempting, but harmful
in the long run.
Joerg Czeranski
> My 2 cents worth:
> Don't post advisories on Fridays or right before common holidays. I'd
> actually recommend that you only post in the mornings (to give 8 to 5
> types a chance to get it the same day) and cut off after Thursday
> morning but that might seem like overkill to some.
But don't forget checking with common holidays in Germany.
And only post at a time that ensures that the posting will reach
Germany in the morning. :-)
I think it doesn't really matter, _when_ you post; only _what_ you
post. Well, you may consider not posting on christmas. :-}
joerg
--
Joerg Czeranski EMail czer...@rz.tu-clausthal.de
Osteroeder Strasse 55 SMTP injc@[139.174.2.10]
D38678 Clausthal-Zellerfeld Voice (at work) +49-5323-72-3896
Germany Voice (at home) +49-5323-78858
William R. Ward
) The consensus mseems to be post problem then post break-in script some
) time later. With this I agree. The problem appears to be the length of
) `some time'. A week sounds good but the time taken for the news to
) reach the far reaches of the globe always leaves someone vulnerable for
) up to a week, probably longer. Nasty people do not have to be in the
) country of the host they attack. If a Nasty Person sees your post an hour
) after it goes to air, that NP will have a week or longer to use your
) breakin script to attack sites far removed on the news network.
I don't think this is a very good argument. MOST of the people who
need this information (sysadmins) will receive it within at most a
couple of days from the original post. Others can join 8lgm's mailing
list, which should be delivered the day of the original post.
--Bill.
--
William R. Ward Unix contractor Apple PIE DTS
Work phone: 408/974-3668 Voicemail: 408/479-4072
Work email: wa...@newton.apple.com Personal email: her...@cats.ucsc.edu
Home email: her...@bayview.com (Finger her...@ucscb.ucsc.edu for PGP)
------------------------------------------------------------------------
Disclaimer: I do not speak for Apple Computer or anyone but myself
John Gordon Thompson
As an added twist how about logging all the email requests and then
publishing them! Publish either in the newsgroup (some people may not
like THAT one), or to the list of everyone who requested the script
(Hey! Whats Joe in agronomy doing requesting that script??).
Of course, you can't accept email requests from root.
JGT
--
John G. Thompson Oracle Secure Systems
Phone: 415-506-4705 400 Oracle Parkway
Fax: 415-506-7221 Box 659405
jgth...@us.oracle.com Redwood Shores CA 94065
John Hawkinson
>country of the host they attack. If a Nasty Person sees your post an hour
>after it goes to air, that NP will have a week or longer to use your
>breakin script to attack sites far removed on the news network.
>Solution? Maybe. How about posting from a number of sites spread around
>the globe to reduce the latency factor.
This won't help. You can look at Usenet organization as a backbone
with tons of other networks hanging off of it. Once an article
finds its way to the backbone, it propagates across it in seconds,
and then gets feed to these other networks. If you experience
a latency in news, it's because:
a) the people posting it are not well-connected (close to the
backbone)
b) the people getting it (you) are not well-connected.
Demon (bagpuss's Internet provider) is fairly well connected; as of
April's Top 1000 listing, they were 92 with 1.68% of all news
travelling through them. As a result, the problem is not a).
Thus, if you want to get advisories better, you need to get a better
newsfeed.
If articles were posted simultaneously from a whole bunch of different
places, then they would all find their way to the backbone (The most
well-connected site's article getting there first), and all would be
the same, except those few networks which happened to be transit paths
to the backbone would have slight advantage.
Of course, this is all an oversimpliciation, but hopefully it clarifies
the situation.
--
John Hawkinson
jh...@panix.com
Karl Strickland
> In article <mrgreen.769623671@circlip> mrg...@mame.mu.OZ.AU (matthew green) writes:
> >In <Cq3z...@legless.demon.co.uk> ne...@legless.demon.co.uk (Neil Woods) writes:
> >
> >[ ... new description ... ]
> >
> >i -like-. i espcially like the idea of mail serving the
> >scripts - makes it even harder for joe newbie to try to
> >be a cracker.
> >
> >this idea has my support.
>
> As an added twist how about logging all the email requests and then
> publishing them! Publish either in the newsgroup (some people may not
> like THAT one), or to the list of everyone who requested the script
> (Hey! Whats Joe in agronomy doing requesting that script??).
> Of course, you can't accept email requests from root.
I for one, have nothing against Joe Newbie requesting scripts, advisories or
anything else, as long as he doesnt then use the script to break root on
someone elses machine. This information should be available to whoever wants
it, not just ro...@some.great.big.internet.site.
We get a lot of email, saying that one reason why people like our advisories
is that they can *learn* stuff from them - how common security flaws work etc.
That is a great benefit, because when these same people write their own
programs, they will be more aware of the security-related issues, and will
hopefully not fall into the same traps.
Joe Newbie may well end up being ro...@some.great.big.internet.site one day -
I'm all for helping him learn this stuff before he gets there.
--
------------------------------------------+-----------------------------------
Posted using GNUS 4.1 on FreeBSD | Karl Strickland
PGP 2.3a Public Key Available. | Internet: ka...@bagpuss.demon.co.uk
"VI. THE SHELL" - BSD PS2:1-9 :-) | or: karl%mv...@bagpuss.demon.co.uk
Karl Strickland
> In <Cq3z...@legless.demon.co.uk>
> ne...@legless.demon.co.uk (Neil Woods) writes:
>
> [please "wrap" your lines before column 80]
haha - well Neil is a MAC user, and uses weird size windows and weird size
fonts :-). Im trying to persuade him to put the window size and the font
name in the 'Subject' line, so that we can all adjust our windows to his
size before reading his posts. :-)
> >For this thread in general, we have pretty much decided that the following
> >will happen:
>
> >We'll publish early in the week (Mornings, Mon - Wed seems o.k. by
> >most people?)
>
> It can take 3-4 days to reach even "well-connected" sites and to be read!
> Some administrators wear other hats too. I can be otherwise occupied
> at remote locations for a few days, without access to news, especially
> after a weekend.
We cannot guard against this. As the saying goes, `You can lead a horse
to water...' :-)
> >Exploit scripts will be made available a few days after the original
> >advisory. I think the minimum suggested period is three working days,
> >a week would seem the best bet as it makes scheduling a bit easier for
> >us and would guarantee everyone that this too is provided early in the
> >week.
>
> A week is reasonable. It doesn't give the better-connected bunnies
> from hopping onto remote systems which they know would be vulnerable.
>
> I presume you that intend to send the advisory and exploitation
> script to the vendor (a couple of days) prior to posting the advisory.
Well for all our advisories (with the exception of the passwd one - the
circumstances will a little different for that), the vendors/software
maintainers all received notifications of the bugs well in advance. In
most cases, this was done via CERT, and in some cases it seems that this
information had not been passed on, even after 12-18 months.
> >We're also considering having scripts by request only (i.e. you have
> >to fetch it from the 8lgm fileserver, rather than mailing/posting it
> >out to everyone.) This will hopefully mean that sites banning our
> >posts will no longer see fit to do so. Views on that suggestion
> >please!
>
> Please continue posting. One week should be enough time to remove
> the vulnerability and to frustrate remote intruders short-circuiting.
>
> >Also should the discussion section remain in the original advisory, or
> >should this be provided with the script? Majority view dictates that
> >it should go out immediately, but if anyone has strong feelings against
> >this, we will again give greater consideration to such requests.
>
> The discussion should adequately describe the nature of the
> vulnerability, including some hint as to which configurations are
> sensitive, without giving away the means of attack. It should not be as
> vague as some security announcements from vendors which simply state
> that "there's a problem - please update"!
>
> A workaround/patch should always be provided with the initial advisory.
For some vulnerabilities, this is fine. For some however (mainly - but by
no means exclusively - those involving source patches), giving a fix is the
same as giving away an exploit script. Eg, look at sendmail 8.6.7's -oE
read-any-file bug. One byte of code was changed in the source. In a kind
of attempt at STO, a patch wasnt produced between 8.6.7 and 8.6.8 - we had
to ftp the whole package. In an attempt to stop people diff'ing it with
earlier versions, those earlier versions were chmod'd to 600 :-)
The point being, that advisories involving source patches will likely give
the game away on the first post. There is no way around this.
Bennett Todd
>As an added twist how about logging all the email requests and then
>publishing them!
Last I checked, authenticating the originator of email was an unsolved
problem.
-Bennett
b...@sbi.com
John Gordon Thompson
>In article <1994May24.1...@oracle.us.oracle.com> jgth...@us.oracle.com (John Gordon Thompson) writes:
>> In article <mrgreen.769623671@circlip> mrg...@mame.mu.OZ.AU (matthew green) writes:
>> >In <Cq3z...@legless.demon.co.uk> ne...@legless.demon.co.uk (Neil Woods) writes:
>> >i -like-. i espcially like the idea of mail serving the
>> >scripts - makes it even harder for joe newbie to try to
>> >be a cracker.
>> >
>> >this idea has my support.
>>
>> As an added twist how about logging all the email requests and then
>> publishing them! Publish either in the newsgroup (some people may not
>> like THAT one), or to the list of everyone who requested the script
>> (Hey! Whats Joe in agronomy doing requesting that script??).
>> Of course, you can't accept email requests from root.
>
>I for one, have nothing against Joe Newbie requesting scripts, advisories or
>anything else, as long as he doesnt then use the script to break root on
>someone elses machine. This information should be available to whoever wants
>it, not just ro...@some.great.big.internet.site.
>
>We get a lot of email, saying that one reason why people like our advisories
>is that they can *learn* stuff from them - how common security flaws work etc.
>That is a great benefit, because when these same people write their own
>programs, they will be more aware of the security-related issues, and will
>hopefully not fall into the same traps.
>
>Joe Newbie may well end up being ro...@some.great.big.internet.site one day -
>I'm all for helping him learn this stuff before he gets there.
From you post I see I didn't take enough time to explain myself. My
apologies.
I do not have a problem with Joe Newbie as well. I agree that he should be
able to get this information. Security through obscurity of information
is the worst kind. It hurts the admin trying to protect the system and it
hurts the user who would help protect the system if he knew what the risks
were.
My point was to collect who is accessing the information that could be used
to break into a system for the first 2 or 3 weeks the information is available
and useful for breaking in. Make it known that this is going to happen and
publish the list. The idea being that if Joe Hacker knows his name is going
to show up on a list, he might think twice about asking for the information
in the time frame he would be able to make use of it. For Joe Newbie this is
not a problem because he is only getting the information for education
(and his name, account or site information isn't going to end up in a
security log) and if he is worried about his account showing up on the
list, he waits for the reporting period to end.
My point about Joe in Agronomy is that alot of security problems come
from inside a site. At the internet firewall I worked at (not my current
job) we made every effort to educate and recruit users to help protect
the system. If we discovered someone violating the system policy and
creating a security hazard we didn't kick them off, we made them part of
the team. Two times we gained valueable resouces.
If the scheme above were in place and I noticed someone inside getting
the advisories I would have watched more carefully to see if he was Joe
Newbie or Joe Hacker. If I never saw him in security logs I would never
have bothered him. If he showed up I would have recruited him for the
team. Unfortunately, I can't say everyone would use the information is
such a nice manner.
My point about root was that ANYONE can get a root account by buying a
machine and installing unix. This reduces the ability to see who is
requesting the information.
Now, having written all the above I can see that my proposal is going to be
cumbersome to implement and of dubious value. Joe Hacker may have Joe Newbie
request the information and thus the trail is misleading.
I agree that the free flow of important security information is more
important than the ability to build a list of names to watch.
(Yikes! Shades of Orwell's 1984!)
Regards, JGT
Michael Sawyer
>
>Last I checked, authenticating the originator of email was an unsolved
>problem.
Less so (although not totally reliable) if the sender intends to get a
reply (as would be the case if requesting information)...
--
Michael Sawyer - My opinions are mine, not necessarily UH's, NSF's, or NASA's
University of Hawaii Physical Oceanography/Satellite Remote Sensing
RIPEM public key available, MD5OfPublicKey: C3363F8BE94B4D2A32B93E1A19B6B925
Bernd Felsche
>In article <Cq6L6...@metapro.DIALix.oz.au>
> ber...@metapro.DIALix.oz.au (Bernd Felsche) writes:
>> In <Cq3z...@legless.demon.co.uk>
>> ne...@legless.demon.co.uk (Neil Woods) writes:
>>
>> [please "wrap" your lines before column 80]
>haha - well Neil is a MAC user, and uses weird size windows and weird size
>fonts :-). Im trying to persuade him to put the window size and the font
>name in the 'Subject' line, so that we can all adjust our windows to his
>size before reading his posts. :-)
Well, it'd give me a chance to find a screwdriver to remove the case on my
terminal to read the lines which wrap around to the back of the CRT. :-)
Soft windows are for WIMPS! :-)
>> The discussion should adequately describe the nature of the
>> vulnerability, including some hint as to which configurations are
>> sensitive, without giving away the means of attack. It should not be as
>> vague as some security announcements from vendors which simply state
>> that "there's a problem - please update"!
>>
>> A workaround/patch should always be provided with the initial advisory.
>For some vulnerabilities, this is fine. For some however (mainly - but by
>no means exclusively - those involving source patches), giving a fix is the
>same as giving away an exploit script. Eg, look at sendmail 8.6.7's -oE
>read-any-file bug. One byte of code was changed in the source. In a kind
>of attempt at STO, a patch wasnt produced between 8.6.7 and 8.6.8 - we had
>to ftp the whole package. In an attempt to stop people diff'ing it with
>earlier versions, those earlier versions were chmod'd to 600 :-)
>The point being, that advisories involving source patches will likely give
>the game away on the first post. There is no way around this.
If the vulnerability exists in something not critical to system operation
(like rdist), then a workaround may be to remove some permission bits,
i.e. knobble the horse!
We still have a "vulnerable" rdist here, but permission bits are 0000.
Go ahead, flog the dead horse!
Admitedly, there will be some instances where giving a workaround
will give away the game... but probably only to the 10-20% (if that)
of people who would try to maliciously crack a system.
It's like a wheel dropping from the sky into a group of cavemen.
Some may be able to figure out what to use it for; others might
make it into a coffee table.
Szymon Sokol
: My point about root was that ANYONE can get a root account by buying a
: requesting the information.
If Joe Cracker has his own Unix machine, he can create any account on it
(for example, jgthomps, with full name 'John Gordon Thompson' :-) ), then use
that account to request information. How could you guess his *true* identity?
Let's forget the whole idea.
--
Szymon Sokol -- Network Manager
U U M M M M University of Mining and Metallurgy, Computer Center
U U MM MM MM MM ave. Mickiewicza 30, 30-059 Krakow, POLAND
U U M M M M M M M M TEL. +48 12 338100 EXT. 2885 FAX +48 12 338907
UUUUU M M M M M M finger szy...@galaxy.uci.agh.edu.pl for PGP key
WWW page: http://www.uci.agh.edu.pl/~szymon/