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 Jun 21 22:00:31 2004