Re: Gauntlet: source code anyone ?

["Mark E. Smith" <mark () pearl grand gdats com>]

Folk,

It seems to me that this thread could be interpreted as a refutation
of the open source philosophy, at least for some problem domains.

Based on Marcus' thoughts, you might conclude one of three things:

1) open source doesn't work
2) open source works fine for most stuff, but not for
security/firewall/IDS
3) NFR and Gauntlet aren't "true" open source
 
Anyone can get NFR source for basically free, but having a look at the
software license reveals:

"b.You may not publish, re-publish, print,
 re-print or otherwise redistribute the NFR Software,
 in any form, without written
 permission from NFR. This restriction is enforced to 
ensure that NFR is the sole source of NFR Software on the Internet and
 that published versions and bug fixes are kept current."

Sounds reasonable to me, but I don't think it's in the original
spirit of open source.  The best reviewers are folks with more of a
vested
interest than either third party reviewers or customers, or probably
even
your everyday integrator.  The best reviewers are other developers who
need to use the source for some particular need and run across the bugs
themselves.  The license restrictions above make it rather pointless for
these developers to find and fix bugs, I think.

See for example the quote in http://www.opensource.org/intro.html:

"The basic idea behind open source is very simple. 
When programmers on the Internet can read, *redistribute,
and modify* (stars mine) the source for a piece of software,
it evolves. People improve it, people adapt it, people fix bugs."

I think that the examples of true security
open source software have been largely "successful"
(that is, in wide use and where the consensus is that there are few
bugs).
Look at nmap, cops, satan.  The "exception" might be fwtk, which has the
same x-gw bugs as Gauntlet (naturally) though it is in wide use. 
However,
a look at its license reveals that it too has restrictions that, say,
nmap doesn't.  This makes me think that maybe there's really the root
cause
of the problem.

I'd be interested in knowing about other cases of
"truly open source" security tools that weren't "succesful"
by this definition.

The usual definition of success--making money--is probably tougher under
the true open source philosophy.
But that's not the issue.  The issue
is whether open source yields better quality software.

Mark

Marcus J. Ranum wrote:
> > There has been much discussion about "must have source code" by people
> > who populate these lists for security products, however, in line with
> > comments brought up before, there is apparently little benefit for the
> > vendor or customer (except that the customer has the ability to introduce
> > their own bugs ;).
>
> This matches my experience. Lots of people want source code
> but very few look at it, or would know what to do with it
> if they saw it. It marks a change in the Internet user
> community: fewer people have the time to look at code than
> used to, and there's a lot more code to look at with fewer
> expert coders proportional to the total number of code users.
>
> That being said, I _do_ think it's worthwhile (or my company
> wouldn't do it) because it's a gesture of good faith and
> sometimes you do learn something valuable. :) For example,
> someone (at the same time as we did) found a potential
> buffer overflow in an earlier version of NFR: they could
> not have done that without access to source. Neither could a
> hacker (as easily) so there's a tradeoff there, too. It's not as
> rewarding as it used to be to publish source code, either, since
> increasing the chance someone can find bugs can lead to
> your competitors using that as a way of deriding your
> product. :(  Thier code is "secure" because their flaws
> are hidden, but they'll still trumpet your flaws publicly.
>
> I've made source code available for _every_ product I've
> ever written (DEC SEAL, Gauntlet, NFR, BoF, Q-b failover)
> and I think that I'm going to stop, after this one. :(  :(
>
> > Why do I say that ?  Well, recently I was in a position to have the time
> > to do a quick review of Gauntlet source code.  Just for laughs, I tried
> > something stupid like "grep sprintf */*.c".  The scary part is that the
> > output was rather lengthy.
>
> Yup. :(
>
> That's a problem with writing UNIX-portable C circa 1992. Not
> every UNIX (in fact a minority of them!) had snprintf in their
> C library. I know I was pretty careful with a lot of the code,
> but you've also got to remember that stack smashing attacks
> were just beginning to appear on the scene at around that
> time... It wasn't a well-recognized threat, yet. That's just
> a little compu-archeology; I find it useful to look at security
> and security problems in their evolutionary context. Remember
> that a "mature" firewall product is all of 6 years old.
>
> > Upon having a closer look at one file (x-gw.c),
> > it became quickly apparent that fixed buffer sizes (some of which were
> > too small) were littered through the code and whilst single buffers
> > could be overflowed, by some stroke of luck it doesn't appear easy to
> > exploit.
>
> X-gw and http-gw both need to be looked at pretty closely.
> That was not deemed as critical, when they were written,
> as some of the other components of the system, because X-gw
> and http-gw are almost entirely intended as internal-to-external
> gateways, rather than external-to-internal. It's the
> external-to-internal that have a much higher likelihood of
> coming under attack. That's not an excuse for sloppy coding,
> though. In my opinion, both programs needed a rewrite
> desperately within days of their completion, but time and
> staffing didn't permit it.
>
> > To make it even worse, this was 4.1, not some early rev.
> > If you use Gauntlet and have the time, setup a host with a full length
> > domain name (256 characters) and try accessing each of the Gauntlet
> > services using it...
>
> Now, _THAT_ is embarrassing.
>
> > Getting back to the larger issue, this indicates a few of things to me:
> > 1. you can't trust firewall vendors to write good, secure, code;
>
> You can't trust _humans_ to write good, secure, code.
>
> > 2. vendors don't appear to do a lot of testing, particularly of boundary
> >   cases (just like all good s/w engineers should);
>
> Typically, zilch.
>
> > 3. vendors don't appear to have a very good quality control;
>
> Typically, zilch.
>
> > 4. those who buy commercial firewall products aren't interested in
> >   doing a code review of their vendor.
>
> Typically, zilch.
>
> > Of course these are generalised points given one experience, but one
> > would have though that of any firewall, Gauntlet would have been the
> > most correct...
>
> Want to know something scary? I suspect it _is_. Still.
>
> > Just before I finish, has anyone ever submitted a patch to TIS/NAI for
> > Gauntlet to fix security holes ?  Do they reject them or simply sit
> > on them ?
>
> After I left TIS in 1995 I submitted a few bug reports and
> when stack smashing started to become more popular, I let a
> couple folks there know that X-gw and http-gw were spaghetti
> code. I guess that your findings are some indication what
> gets done with outsider input. But then maybe they figured
> I was just a random crank who didn't know anything about
> Gauntlet internals... :)
>
> mjr.
> --
> Marcus J. Ranum, CEO, Network Flight Recorder, Inc.
> work - http://www.nfr.net
> home - http://www.clark.net/pub/mjr