Re: Gauntlet: source code anyone ?

[Darren Reed <darrenr () reed wattle id au>]

In some email I received from Steve George, sie wrote:
[...]
> Solutions that come to mind are either for people to roll their own FW's
> or to support a Free FW.  The problem with everyone rolling their own
> FW's is that lots of clients and consultancies are resistant to it; it's
> time intensive, requires more knowledge on the part of the implementor
> and some clients view it as less secure than a commercial product.

Examining source code is also time intensive.  Do you have that sort of
time and is your company willing to pay you to do that ?  We're currently
plagued with one a Gauntlet bug in handling of CVP.  We have the source,
we could _possibly_ patch it but at the same time we have a service contract.
My estimate is that it would probably take no less than 1 day to fix and
test adequately (I've not looked at that source code before, so I need to
familiarize myself with it before I can attempt to safely change it).
$1000+ for a patch that the vendor should provide anyway.  If push came
to shove, maybe myself or one other person where I'm working could make
the change.  For an IT department, this is (in my experience) a rare
luxury for them in terms of the pool of talent available.

[..]
> The
> second option would be the development of a GNU/Free alternative,  which
> the community would support and use lots, a Linux of FW's as it were. 
> The problem with the second option is that there has never really been
> much drive in the community for developing a single(?) well-known
> alternative, rather there are lots of varying but often good options.

If glibc version 2 wasn't so bad, I'd say there is an answer: IP Filter
(although some of the `features' aren't supported on all platforms, the
 central idea of firewalling is).  But this glosses over the fact that
doing such is not trivial.  The differences just between *BSD and Linux
is enough to make you cry - TCP code calling interface output routines
(because it's faster I assume) is a classic example from the linux kernel
that makes me puke, and then you've got others making life hard for you
for no other reason than they want to move a structure which they don't
believe belongs in a certain header file (FreeBSD moved something from
/usr/include/net/if.h - I think - to another file which stopped many
things, including tcpdump, from compiling "out of the box").  Not to mention
that various people seem to enjoy making significant changes in the middle
of a major release or that perhaps a provided interface is weaker than it
could be so you need to provide your own.  And then you have to remember
you're expecting someone to do all this work for you and do it for free.
Sounds good when you're sitting down dreaming it up, the reality is *much*
different and not pleasant.

[...]
> The option
> should still be there for clients to fully inspect the product should
> they wish to: afterall they are buying security and an important way to
> assure this is to check the source code of the single point of failure.

Why must we only have such in-depth access for computer software based
security tools ?  What about locks for doors, swipe cards, etc ?  I've
never seen anyone argue that we need to see "inside" any of those devices,
although I'm sure if we could then we'd discover that they're not really
all that secure anyway.

In occurs to me that computing is becoming increasingly more appliance
based and that appliances, by nature, are typically black-boxes.  If I
feel I need to review the source code for a product, then there is
something fundamentally wrong.  Being able to obtain it is, IMHO, a
luxury and we've grown used to being spoilt.

Let me ask you a question: if vendors could in some way show that their
product was reasonably resistant to attack then is the time you spend
reviewing the source code searching for a bug time well spent ?

If I write a firewall in assembler, and make that available, what's
the likelihood of someone else being able to find a bug ?  Afterall,
it'd probably be the fastest firewall this side of the black stump >;-)

To end this, I'd suggest that perhaps the problem isn't availability of
source code, but the suggestion/perception that we need it because we're
not prepared to trust vendors.

Darren