Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 3 Feb 1997 06:45:46 -0600 (CST)
From:      "Thomas H. Ptacek" <tqbf@enteract.com>
To:        phk@critter.dk.tfs.com (Poul-Henning Kamp)
Cc:        tqbf@enteract.com, dg@root.com, torbjorn@norway.eu.net, freebsd-security@FreeBSD.ORG
Subject:   Re: Critical Security Problem in 4.4BSD crt0
Message-ID:  <199702031246.GAA24561@enteract.com>
In-Reply-To: <748.854973113@critter.dk.tfs.com> from "Poul-Henning Kamp" at Feb 3, 97 01:31:53 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> There is no reason to provide free munitions to criminals.

You're kidding yourself if you think the criminals don't have these
munitions already. As previously stated, the vulnerability we're
discussing is being actively exploited on the network. The case is
probably the same with every other vulnerability you have, or will, find
in your code. 

The "criminals" have far more time on their hands to find problems than
you do. Finding problems in your code is all they do. You have better
things to do. Partial (or non) disclosure is not an effective option for
the FreeBSD project (until the FreeBSD project gets someone like Mr. de
Raadt to comb the entire source tree). Until that time, members of the
FreeBSD project will probably not be the first people to become aware of
security issues with FreeBSD code.

> On the other hand, vulnerabilities that have been announced publically
> we answer publically with the relevant information.

freebsd-security@freebsd.org isn't considered "public announcement"?

> We could of course loudly praise our own genius and tell the world
> every time we fix a problem, but we would essentially sell all of

I hardly think fixing problems qualifies as genius. 

> No easy solution I'm afraid.

Sure there is. Every security vulnerability you find in your code needs to
be patched immediately by everyone running the vulnerable code. Nobody is
going to know that their code is vulnerable unless you tell them.
Therefore, it seems somewhat obvious to me that every time you find a
security vulnerability, you should post a security announcement to
freebsd-security, freebsd-announce, and CERT.

Chances are, someone has already found the vulnerability you're looking at
and is using it to comprimise hosts running the problematic code. 

If you don't intend to do that, the only recourse we have is to post
problem details publically as soon as they are found, including
exploitation details. This is the only way the problems will be taken
seriously by "security incident response teams", and announcement from
"security incident response teams" seem to be the only thing that ever
prompts the FreeBSD team to release a security announcement. 

This is, of course, the attitude I'm taking with the crt0 problem. I
assume you will come forward with an announcement regarding the problem in
the very near future, because I trust that you perceive the severity of
this problem in the same manner that I do. If you don't, I'll announce the
problem again, with exploit details, and if at that point you don't
release an announcement, the various CERT groups will. 

Seems to me like you can either choose to come forward with security
issues as you become aware of them, or you can find out about your
security problems from bugtraq by reading the exploits. I certainly won't
be sending in any problem reports if they're not going to be acted on, and
"acted on", to my mind, includes notifying your users.

It's your choice, of course, but people complain (loudly) when
exploitation details are posted to bugtraq (and the like). If immediate
public disclosure of all FreeBSD security problems is not a policy you
find acceptable, I suggest you take steps to provide an effective
alternative.

Thanks for listening!

----------------
Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com]
----------------
"I'm standing alone, I'm watching you all, I'm seeing you sinking."





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702031246.GAA24561>