headers
John Nemeth | 1 Jul 2002 01:46
Picon
Favicon

Re: rfc2228 in ftpd

On Nov 14,  3:29am, Jason R Thorpe wrote:
} 
} (FreSSH has addressed some of the issues with SSHv1 with some extensions,
} but the FreSSH developers haven't had time to work on FreSSH much for ...
} quite a while, and these extensions only work with FreSSH anyway.)

     The last time there was an OpenSSH issue, the FreSSH developers
said they would try to pick up the pace.  Even with their "famed
auditing", OpenSSH seems to have a serious security hole appear every
couple of months (this doesn't say much about the quality of their
code).  Every time, they do this, I have to update 20+ systems.  Many
of them are unique, so I can't just compile on one machine and sprinkle
it around like magic dust.  Also, given that they sounded a major panic
unnecessarily, I don't trust them.  They made it seem like I had to
update all 20+ systems on the spot, when there was no need to update
any of them, except to make a config change on a handful.  They just
happen to be the best choice available at the moment.  However, I would
really really like an alternative.

}-- End of excerpt from Jason R Thorpe
Permalink | Reply | 0 comments |
headers
itojun | 1 Jul 2002 02:22

Re: rfc2228 in ftpd

>it around like magic dust.  Also, given that they sounded a major panic
>unnecessarily, I don't trust them.  They made it seem like I had to
>update all 20+ systems on the spot, when there was no need to update
>any of them, except to make a config change on a handful.  They just
>happen to be the best choice available at the moment.  However, I would
>really really like an alternative.

	there were reasons why they couldn't annouce the config file workaround
	when 3.3 release was made.
	- saying "disabling challenge authenticaiton will make you safe"
	  will make the location of the bug apparent, letting script kiddies
	  create attack code in less than a day
	  (and in fact, did you see posting on bugtraq?  in fact attack
	  code appeared in less than a day)
	- ditto for "disabling protocol version 2"

	i suggested markus to include the reasoning behind the way 3.3 -> 3.4
	upgrade path was annouced.  i think it will help a lot of people to
	understand why it had to be handled this way.

itojun
Permalink | Reply | 0 comments |
headers
matthew green | 1 Jul 2002 02:28
Picon
Favicon

re: rfc2228 in ftpd


   >it around like magic dust.  Also, given that they sounded a major panic
   >unnecessarily, I don't trust them.  They made it seem like I had to
   >update all 20+ systems on the spot, when there was no need to update
   >any of them, except to make a config change on a handful.  They just
   >happen to be the best choice available at the moment.  However, I would
   >really really like an alternative.

   	there were reasons why they couldn't annouce the config file workaround
   	when 3.3 release was made.
   	- saying "disabling challenge authenticaiton will make you safe"
   	  will make the location of the bug apparent, letting script kiddies
   	  create attack code in less than a day
   	  (and in fact, did you see posting on bugtraq?  in fact attack
   	  code appeared in less than a day)
   	- ditto for "disabling protocol version 2"

   	i suggested markus to include the reasoning behind the way 3.3 -> 3.4
   	upgrade path was annouced.  i think it will help a lot of people to
   	understand why it had to be handled this way.

i will never understand why it had to be handled that way.  it was
*SO EASY* for me to go to all my machines and turn off skey.  it
had started to prove to be a REAL PAIN IN THE ASS to update them
to a newer version (that STILL included the problem) that i'm not
sure i'd done more than 1 machine before the ISS advisory came out
and the sane workaround became known.

protect the users?  this sounds so much like "protect the children"
to me it makes me sick.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason R Thorpe | 1 Jul 2002 02:41

Re: rfc2228 in ftpd

On Mon, Jul 01, 2002 at 09:22:30AM +0900, itojun <at> iijlab.net wrote:

 > 	there were reasons why they couldn't annouce the config file workaround
 > 	when 3.3 release was made.

There is NO reason that this work around could not have been disclosed
by the OpenSSH developers through the appropriate channels (e.g. CERT, who
then privately communicates with the security contacts of the various other
organizations).  There was also no reason not to provide a patch against
older versions of OpenSSH which fixed the problem through those same channels.

This would have allowed:

	* Projects such as NetBSD and FreeBSD to (silently) protect their
	  servers.

	* Software vendors to have new binaries, patches, whatever available
	  when the advisory is made public.  Again, this could have been
	  done silently, without the general public's knowledge.

	* Vendors to determine that no action is necessary on their part
	  based on how their software is configured.  Again, this can take
	  place without the general public's knowledge.

Instead, what happened is that a rumor of a nasty exploit was floated, with
the suggestion to upgrade to a new version (which includes new, non-mature
code, something which is especially dangerous to do, considering the security-
sensitive nature of the code in question), and a general sense of panic in the
community.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bill Sommerfeld | 1 Jul 2002 02:46
Picon

Re: rfc2228 in ftpd

> 	i suggested markus to include the reasoning behind the way 3.3 -> 3.4
> 	upgrade path was annouced.  i think it will help a lot of people to
> 	understand why it had to be handled this way.

The reasoning was clear but unreasonable..

The idea that a significant fraction of end users could just
immediately drop everything and upgrade to 3.3 is completely
ridiculous...  particularly since the "privilege separation" features
necessary to defend against the unmentionable bug were *advertised* as
having functional regressions!

					- Bill
Permalink | Reply | 0 comments |
headers
Jason R Thorpe | 1 Jul 2002 03:11

Re: rfc2228 in ftpd

On Sun, Jun 30, 2002 at 07:01:36PM -0600, Theo de Raadt wrote:

 > Why are you bothering to have this witch-hunt conversation when our
 > responses are censored?

If your responses would actually address the issues outlined, then the
moderator of the list will certainly let them through.  However, it is
precisely the fact that they consistently do NOT stay on-topic that
they're not generally passed on.

--

-- 
        -- Jason R. Thorpe <thorpej <at> wasabisystems.com>
Permalink | Reply | 3 comments |
headers
itojun | 1 Jul 2002 03:37

Re: rfc2228 in ftpd

>Itojun and I) dislosed in 6 hours instead of via CERT because it
>became clear to us that FreeBSD and NetBSD security officers were BUSY
>LEAKING THE INFORMATION?!?  (I do not intend to play that blame game

	correction - NetBSD security officers did not leak any
	info (in fact, i did not even inform them until the rumor was injected
	into security-alert <at> netbsd from other side)

itojun
Permalink | Reply | 0 comments |
headers
Theo de Raadt | 1 Jul 2002 03:01
Picon
Favicon

Re: rfc2228 in ftpd

Why are you bothering to have this witch-hunt conversation when our
responses are censored?
Permalink | Reply | 5 comments |
headers
Theo de Raadt | 1 Jul 2002 03:42
Picon
Favicon

Re: rfc2228 in ftpd

Jason, please do not make false statements like this.

4 messages directly on topic were not sent through until I asked for
them to be sent through.  Then they were sent through.  Was sending
them through a mistake, or was blocking them a mistake?  Can you
please clarify?

Hugh's messages in port-vax with booting bug fixes were also censored
and he had to replace his email address.

This is a message which was blocked until after:

    http://mail-index.netbsd.org/tech-security/2002/06/27/0016.html

Was this above message not relevant?

It was in response to this message:

    http://mail-index.netbsd.org/tech-security/2002/06/27/0008.html

Does this above message meet the requirements, where mine doesn't?

> On Sun, Jun 30, 2002 at 07:01:36PM -0600, Theo de Raadt wrote:
> 
>  > Why are you bothering to have this witch-hunt conversation when our
>  > responses are censored?
> 
> If your responses would actually address the issues outlined, then the
> moderator of the list will certainly let them through.  However, it is
> precisely the fact that they consistently do NOT stay on-topic that
(Continue reading)

Permalink | Reply | 0 comments |
headers
Theo de Raadt | 1 Jul 2002 03:34
Picon
Favicon

Re: rfc2228 in ftpd

> > 	i suggested markus to include the reasoning behind the way 3.3 -> 3.4
> > 	upgrade path was annouced.  i think it will help a lot of people to
> > 	understand why it had to be handled this way.
> 
> The reasoning was clear but unreasonable..
> 
> The idea that a significant fraction of end users could just
> immediately drop everything and upgrade to 3.3 is completely
> ridiculous...

Well, I heard from one Fortune 100 company that updated 2300 machines
to 3.3 in 15 hours and accepted the functional problems for the 4 day
window; a very major foreign government agency that filtered protocol
22 on all of their core routers; a large ISP that went through their
sshd_config files and cut down the functionality as much as possible
(and luckily made the right guesses, without any disclosure hints from
me -- they asked "did we limit it enough?" and I said "perhaps.  I
cannot disclose" and they replied "we understand, thanks, we're going
to stick with this stance."), and also from hundreds of individual and
corporate users of unknown size, who disabled or filtered it in some
ways.  SPRINT NOC called me at home and asked some questions,
apparently they realized that our machines are on their network, and
wanted to make sure they would not suffer from this and stop us from
releasing a new version -- that was a real wow moment.  I have
received hundreds and hundreds of mails about this.

That is a very significant community that were fore-warned.

For those who couldn't respond with taking a security stance, I am
sorry.  Their situation is no different than no warning before
(Continue reading)

Permalink | Reply | 2 comments |

Gmane