Just so people know:
I have not had sufficient time to do the security audit I started a
month ago; it's now clear that I won't be able to finish it. Wanted
to say so here, in case someone out there has the competence/desire to
work on this, but was holding off because they thought I was doing it.
Sorry!
-Karl
> I've started doing a security audit of Subversion's code. I'm not
> expert in this, but (as you probably noticed) we've had two security
> releases already, 1.0.3 and 1.0.5. It'd be nice to be ahead of the
> game for once, instead of catching up. Anyone who wants to help,
> please join me! You can post here to say what sort of inspection
> you're doing, but, for obvious reasons,
>
> +-----+
> *** DO | NOT | PUBLICLY POST SECURITY PROBLEMS HERE ***
> +-----+
>
> Instead, if you see something worrysome, send mail to:
>
> security
> ~@~
> subversion.tigris.org
>
> We'll discuss the problem on that list (keeping you CC'd, of course,
> as the original reporter) and decide what to do.
>
> (By the way, we're careful never to write that list's address
> directly. For maximum responsiveness, the list is unmoderated and has
> no spam-filtering. So far, it's been okay -- it doesn't get any spam
> yet. Let's try to keep it that way. :-) )
>
> I asked Stefan Esser, who has found vulnerabilities in both CVS and
> Subversion before, for some advice on security audits. His response
> was helpful, though of course he said up front that there is no set
> formula for doing audits. Below is his response, with some sensitive
> parts redacted. What I'm doing right now is looking at stuff
> described in his second paragraph.
>
> > From: Stefan Esser <s.esser@e-matters.de>
> > Subject: Re: advice on doing security review of Subversion
> > To: kfogel@collab.net
> >
> > [...]
> >
> > Giving advices how to security audit a program is not an easy task. First
> > of all I believe you have some advantages over an external auditor,
> > because usually the first thing one does is to learn the overall structure
> > of the source code. This is because one normally starts with auditing the
> > input and output routines of a program, because at these points the user
> > interaction takes place.
> >
> > Other things people usually do is to grep for strcpy, sscanf, *printf first
> > to catch the most obvious bugs. Like ordinary strcpy, or format string bugs.
> > Often this reveals some kind of logging functions which directly use those
> > functions. Then one starts greping for those...
> >
> > Other things I usually check is where memory is allocated in ways like
> > malloc(a+1) malloc(a*b) etc... And then I check all those places if an
> > integer overflow could happen at this place.
> >
> > [...]
> >
> > Ohh well and one thing you should always look at are memcpy()s. I usually
> > grep for them and then move all those with non static sizes to another list.
> > These I check first if I find a place where maybe the size is calculated
> > wrong, or a user supplied size is copied into a static size buffer...
> >
> > But this is usually only step 1. There are a lot of more possible
> > bugs which only wait to be found. Like things if (int_variable <
> > sizeof(buffer)) this will be turned into an unsigned compare and
> > therefore negative ints will pass this check.
> >
> > [...]
>
> -Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 26 17:58:33 2004