Re: SSL?

[Eric Siegerman]

On Fri, Mar 16, 2001 at 05:18:27PM -0500, Derek R. Price wrote:
> Larry Jones wrote:
> 
> > Derek R. Price writes:
> > >
> > > Okay, that makes sense, but couldn't you achieve the same effect with a 
> > > library?
> > > Where the exec would have been, the server's main function gets called 
> > > and the
> > > whole process exits immediately upon return from that function?
> >
> > I don't think so.  I'm not a security expert, but my understanding is
> > that any code physically linked into the executable is suspect.

Yup.  If SSL code is linked into CVS, then a buffer overrun
anywhere in CVS has immediate and profound security implications.
If the SSL code is running in a separate Unix process, then a
buffer overrun in CVS doesn't provide any ways to attack it
(though the overrun may still be exploitable in other ways).

CVS is linked with RCS and GNU diff as well -- and these are
unlikely to ever get as much scrutiny as an SSL library, since on
their own they're "obviously" not security-related systems.  If
SSL is added to the mix, the whole cvs binary must be deemed at
least as insecure as GNU diff, even though one needs it to be as
secure as SSL is on its own.

This is a "chain is only as strong as its weakest link"
situation.  The (partial) solution is to isolate the security
code in its own small chain, with few links, and none that
haven't been heavily security-audited.

The other problem is a combinatorial explosion in un-understood
interactions, some of which may be exploitable -- and a
corresponding decrease in any one person's ability to understand
the whole thing.

Basically, it seems to me that this all boils down to the classic
Unix argument for small, cooperating, single-purpose tools as
opposed to a big, monolithic, Swiss-army-knife tool; it's just
that, as soon as security issues get involved, the stakes
suddenly become a lot higher.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
        - RFC 1925 (quoting an unnamed source)