In article <KARL.94May18162...@bagpuss.demon.co.uk>,
        >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

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.  If you have mailed me, or 8...@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: k...@bagpuss.demon.co.uk
"VI. THE SHELL" - BSD PS2:1-9 :-)         | or:  karl%m...@bagpuss.demon.co.uk

In article <KARL.94May18162...@bagpuss.demon.co.uk>,

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

In article <2rdkk3$...@charm.magnus.acs.ohio-state.edu>, ceme...@magnus.acs.ohio-state.edu (Charles E Meier) writes:
[snip]
[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.

[snip]           Building trust and solving problems is
|> what usenet/internet should be here for.

Yes!

--
+-----------------------------------+-------------------------------------- +
| Mike Connally, Systems Consultant | internet:  Mike.Conna...@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.   |
+-----------------------------------+-------------------------------------- +

: In article <2rdkk3$...@charm.magnus.acs.ohio-state.edu>, ceme...@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

Charles E Meier (ceme...@magnus.acs.ohio-state.edu) wrote:
[Big SNIP <g>]

I concur with Mr. Meier's sequence. Add one vote in the appropriate
column.

-Reto
--
R A Lichtensteiger
System Administrator            r...@hri.com
Horizon Research Inc            (617) 466-8304

Q: What goes "Pieces of seven! Pieces of seven!"?
A: A parroty error!!

In article <2rdkk3$...@charm.magnus.acs.ohio-state.edu> ceme...@magnus.acs.ohio-state.edu (Charles E Meier) writes:

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                          |

I'd like to add my voice to the "much appreciated, but please not on the
weekends" group.

'Nuff said,
--
  _____ _  _   Francisco X DeJesus -/ S A I C /- deje...@c3ot.saic.com   -{----
 | ___/< \/ >  -------------------------------------------------------   /
 | __|  >  <   [disclaimer: opinions are mine, typos and errors yours]   \/> _
 |_|   <_/\_>  "Hack the hardware, not the Constitution." -B. Sterling   |#\/`

Karl Strickland <k...@bagpuss.demon.co.uk> says:

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

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 czeran...@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