On Thu, Oct 21, 2004 at 01:19:55AM +0200, Alex Holst wrote:
> Ah yes. I recall someone mentioned rats once. Unfortunately, most static
> analysers aren't very good. In my experience, splint is the best one but
> the default config is not very usable, so you'd have to invest a lot of
> time into it.
IIRC someone posted output from several of them to the security list.
I'd have to go digging to see which ones. But sure these tools aren't
any guarantee that you have secure software.
> I wasn't trying to point out that the number of access methods is a
> problem. I tried to elaborate in the document. Please tell me if it's
> any clearer.
Yes much clearer.
> Oh, I wasn't referring to the size of the svn modules in this case. I
> was referring to the rest of Apache :)
>
> My point: Most users don't think like this. They don't realise how much
> code is exposed when they run Apache. They just install it, and it
> works. I will be documenting which Apache modules are required, which
> will bring the count down to a handful or so. Hopefully such
> documentation can fit into the book somewhere.
Hmm, I guess that's true. But I was already running Apache. If you're
already running Apache, using mod_dav_svn only increases your exposure
by a small amount.
But sure I'll agree that documenting what is really needed to run is a
good thing.
> I don't think that's an unfair statement at all. You know you look for
> security problems, but I didn't know you did. And you don't know who
> else looks for security problems either. I'm sure you'll agree that the
> more people who look, the better.
Of course more people is better. I guess I don't see how anyone can
honestly say they've reviewed code and not looked for security issues.
But if you follow the list, a lot of commits get comments on them.
Usually detailed comments. Not just "OMG you just broke the build" type
stuff. But stuff that shows clear understanding of the code and the
implications of using that.
> One or two people cannot do this alone. When someone reviews a patch,
> it would help to know how many people actually looked for security
> problems. Just because this is open source doesn't mean people are
> looking at the code for the reasons you'd like them to.
>
> Ok, that's great. I'll revise the document to reflect this. By the token
> that all vulnerabilities up until now have been introduced before 1.0,
> I'd still advocate that a structured review of the apache modules and
> svnserve take place.
Sure, it might be useful if we had a good way of nothing who reviewed a
rev. Maybe we should have a revision rev for this basis. Then revs
that aren't reviewed much can be found and looked at.
Lot's of people have said "You should do a security audit." Nobody has
really come up with a good way to organize and carry one out. We even
went so far as to send an email to Stephen Esser asking for advice on
how to carry it out. He couldn't really give us any specific advice.
So saying that a review should take place isn't very helpful. We've
gotten that far. The question on the table is "How do you carry out
that review?"
Additionally, there is some question as to if the review would even
really be beneficial. See Karl's email for that he covered it better
than I could have.
> Ah. This was not my understanding. sussman invited me to the security
> list once about 200 years ago and then changed his mind as he realised
> the list was used by people who can quickly fix a bug, commit and
> release a patch. I wasn't going to be of much use in that scenario. Has
> this changed?
I think the list can and should serve a much broader purpose than this.
A lot of discussion goes on that's not simply "Here's a problem how to
we fix it." So yes I think you would be valuable to be on that list.
> Ouch. There are people who, when they find a security problem, tell no
> one. They use the vulnerability for their own purposes. If the project
> members actively look for bugs, there are going to be fewer bugs to be
> found by hostile outsiders.
Sure but this has nothing to do with the issues we've released. They
weren't discovered by people that told no on. They were discovered by
people who told us about them. Stefen Esser (a security researcher)
found the first one. Why is it bad that Stefen Esser found one and we
didn't? It's almost a given that some bugs are going to be found by
outsiders. Especially, well versed security researchers. There's
simply no way that Subversion developers are ever going to know as much
as someone who spends all their time working on security.
Even if all 4 had been found by us would that mean that there aren't
ones we haven't found potentially found by somone who doesn't tell
anyone? Not really. It just means we've managed to find all the known
bugs. We might have done that by luck, due to the virtual that there
are no other bugs, or simply that nobody who is skilled enough to find
the remaining bugs is looking.
Most attempts to determine the security of software by looking at the
track record of who finds bugs and how often bugs are found are wrong
IMHO. It's one thing to say Internet Explorer isn't a secure piece of
software because there are known issues with it that Microsoft seems
unwilling or extermely slow to fix. It's a different thing to say that
IE is less secure than Firefox simply because it has more bugs found.
Like I said there are many reasons the data could come out the way it
does. You can't correlate existing bugs with future bugs, the number of
bugs or their severity with who finds them.
> I feel that I am. Experience tells me that this project gets much
> further if I can get *some* level of organised code audits started. I
> don't mean to be high and mighty. I promise. It won't make any
> difference at all if I sit down and review the code.
>
> I am of much more value to this project by helping developers with
> certain things than I would be if I sat down and found bugs: I won't be
> here always, but an established culture of security-aware developers
> *will* -- or at least has a greater chance of being so.
I certainly wasn't suggesting that you do it on your own. Or that you
do it and keep the knowledge of how to do it to yourself. Helping us do
it is great.
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 21 01:59:44 2004