Re: Gauntlet: source code anyone ?

[David Lang <dlang () diginsite com>]

-----BEGIN PGP SIGNED MESSAGE-----

There is a much smaller difference between the meaning of the current
trademardk "open source" and the NFR licence then ther is between the NFR
licence and Microsoft's policy. Refering to the NFR source as "open" for
many years has ment that you could get it, and examin it. you still can,
the licence has not changed. It is not any more closed. The trademark
"Open Source" has now redefined the term (if you want to be picky about
it), but that is not the issue we are debating. we are not debating wheter
or not the NFR source should be freely distributable, under anyones name,
with any changes to it. we are debating whether or not you should be able
to get the source code to examin. To avoid confusion we should probably
use a new term "source code availibility" if the idscussion is going to
get that picky, but most people are not that wooried about the differences
(except Marcus of course so that he can make money on it :-)

As people are starting to get picky, the NFR licence was used as an
example only. There are (or were) many other products that would fit the
example just as well.

David Lang

 On Mon, 22 Mar 1999, Mark E. Smith wrote:

> Date: Mon, 22 Mar 1999 15:36:28 -0500
> From: Mark E. Smith <mark () pearl grand gdats com>
> To: firewall-wizards () nfr net
> Subject: Re: Gauntlet: source code anyone ?
>
> 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

"If users are made to understand that the system administrator's job is to
make computers run, and not to make them happy, they can, in fact, be made
happy most of the time. If users are allowed to believe that the system
administrator's job is to make them happy, they can, in fact, never be made
happy." 
- -Paul Evans (as quoted by Barb Dijker in "Managing Support Staff", LISA '97)

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQEVAwUBNvfV7T7msCGEppcbAQGC6Af/Zq9KJxW7aSSEqcqOMKd//cF2UfRFgsfM
yzri9AxZZDfc4H/15w1s9i/Z5HbF7ox368xk5egZtACJS0EWLQMdxHU17VBKq3bZ
DcginOwm4fBTfH3JAsuQeiK8zVdINtu8QkvVeLikIgfBlzin451U06ev+qNAFqmB
6GdEZD6CJSSYYrfms5bVo0vGkbGu8W4wEdSyNrT0DpCHNqE5bproryUgd2pzOnQF
1RwOIKUUbZaZ24v4bg/s43NG7nQ688ys0xfwKc+ARPNNHpLCQ5CyNrrCrWwEUFjd
iolsqT5ze9HcQ+bEkJyruGAb/B4kov7YYZlizh3MKFqxcFcQ5q3O+Q==
=oAU7
-----END PGP SIGNATURE-----