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