Greg Stein <gstein@lyra.org> writes:
> There is nothing to support that Apache has problematic buffer overflows.
Let me get very very blunt right now. You want to get Microsoft's
reputation here? Because we know what those guys are like.
You don't get anywhere by putting your head in the sand. There is a
reason that people come out with large scale security advisories all
the time, and it is because application programmers treat the security
issue like a giant fat joke.
The only exception I can think of is Wietse Venema's work on Postfix
and DJB's work on qmail, and in both instances the programmer in
question came from a security background, not an application
programming background.
There are principles people writing secure software use: least
privilege, aperture narrowing, etc. Those of us who are security
conscious have been worrying about how to do good design for years and
actually understand the problem. If you want to ignore all that and
just say "oh, no one has proven Apache has any more bugs, lets thumb
our nose at those horrid security dweebs", well, you're acting like
Microsoft.
Part of the issue here is that the larger the exposed codebase, the
greater the chances of a problem. It has nothing to do with how macho
a programmer you are, how wonderful your education was, etc. It is
just an obvious principle. More lines of code, more moving parts. More
moving parts, more possible bugs. Marcus Ranum's smap/smapd mail front
ends that were used for whitehouse.gov were a couple of pages of code
each to make them auditable, and I *still* managed to find several
serious security bugs in them.
The larger the codebase talking to the network, the worse the problem
is. If you're only talking to CVS once sshd is through with you, you
just have to worry about sshd vulnerabilities, but the way things are
structured in Subversion, you have a very substantial amount of code
that is a problem.
To you the security issues may be a giant joke ("who cares about
security?") but to people who are operating system writers that use
source control and worry about people inserting trojans straight into
their release base, the repository system is a holy of holies and is
not supposed to be exposed cavalierly.
> Heck, there isn't anything that says that Subversion doesn't have buffer
> overflows. New code. New problems.
>
> And you know... for that matter, has anybody actually audited CVS? Hoo... I
> have seen its network code. Ohmigod. I double-dare you to audit that.
CVS's overflows don't matter, because until you get past the remote
access method they can't be invoked. At worst you're going to have an
insider attack you, and they have other ways to do that (i.e. by
introducing subtle bugs intentionally in otherwise "clean"
commits).
The point of trying to make sure that the remote access method is well
protected is to reduce the size of the vulnerability aperture.
> > not whether the system enforces protection if functioning
> > correctly. The nice thing about sshd is that although it is not
> > perfect, it is at least one narrow interface one has to worry
> > about (and have to run on our systems anyway).
>
> One port for subversion is not a big deal.
Yes it is. It is a whole new bunch of code you have to deal with.
> Your admins will still need the
> sshd port, but you can reduce your logins to *JUST* the admins.
My problem isn't the admin logins. The problem is bugs in sshd. Now I
have to add bugs in a much bigger program (Apache+Subversion) to bugs
in sshd.
> The devs don't need system accounts or access to the sshd port.
They don't need system accounts using rCVS either. At least not login
accounts.
> You're trading one port for another.
Nope.
> >...
> > > or, you can write ra_ssh (or ra_pipe, as people on irc were
> > > talking about, since there's no reason to require this to be used via
> > > ssh, we could use anything we can read and write to).
> >
> > That's more or less the point. We sort of need such a
> > thing. Unfortunately, I'm insufficiently skilled to do so on my own.
>
> That would be interesting, and we'd certainly accept the code, but I don't
> think it will buy you much (for your use case) relative to Subversion over
> SSL.
It would buy quite a lot.
Steve Bellovin did a great study a while back of CERT
advisories. There are almost never attacks these days based on bad
crypto. They're almost always based on buggy code. Less code being run
means fewer places for there to be bugs.
--
Perry E. Metzger perry@wasabisystems.com
--
NetBSD: The right OS for your embedded design. http://www.wasabisystems.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 16 17:32:01 2002