[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Adapting svnstsw to use Subversion's build system

From: Richard Hansen <rhansen_at_bbn.com>
Date: Tue, 06 May 2008 22:59:11 -0400

Greg Hudson wrote:
> On Tue, 2008-05-06 at 21:41 +0100, Max Bowsher wrote:
>> Karl Fogel wrote:
>>> Richard Hansen <rhansen_at_bbn.com> writes:
>>>> The variable-length array usage is probably hardest to work around. A
>>>> functional snprintf is likely to be available, but if not, I can
>>>> probably steal snprintf from <http://www.ijs.si/software/snprintf/> or
>>>> one of the BSDs.
>>>
>>> Well, you can also use anything APR or APR-UTIL provides, since
>>> Subversion already depends on them. There is an apr_snprintf().
>>>
>>> There may be other things you can use to replace the variable-length
>>> arrays. Like
>>>
>>> svn_string_t
>>> svn_stringbuf_t
>>> apr_array_header_t
>>>
>>> ?
>>
>> Hmm, I think I'd prefer my setuid binaries to be sticking with C
>> builtins over library functions where possible, in the name of
>> minimizing the amount of code that runs with elevated privileges.
>
> I believe the code is already using APR.

It is, but only for command-line argument parsing (to stay compatible
with svnserve).

> I don't think using APR is a big deal for this. If APR has in-built
> security vulnerabilities due to coding flaws, they probably affect
> Apache httpd, which is going to be a much bigger deal than a security
> elevation exploit in svnstsw.

I mostly agree. Note that svnstsw execs svnserve, so even if svnstsw
doesn't use APR, vulnerabilities in APR may still lead to privilege
escalation via attacks on svnserve. However, this doesn't mean that
there are no additional risks to using APR in svnstsw. A flaw in an APR
function may not be exploitable in Apache or svnserve, yet might be
exploitable in svnstsw (perhaps because of how the function is used, or
because the role played by the return value is different).

-Richard

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-07 04:59:28 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.