On Sat, 2004-05-01 at 12:05, C.A.T.Magic wrote:
> for example in the new fsfs.c :
> >>
> size_t keylen = (size_t) atoi (stringbuf->data + 2);
[...]
> for example if "-1" would be returned from atoi then the '\0'
> could go into dead memory.
> how do apr_palloc(0) and apr_palloc(-2) react?
size_t is an unsigned type. (We should be using apr_size_t there, but
that's an orthogonal issue.) So while reading -1 would cause us to
attempt to allocate a ridiculous amount of memory, it would not cause a
buffer overrun.
> some similar atoi based alloc code exists in 'load.c' and 'hash.c'(2x)
> and maybe other places too.
The case I am most concerned about is svndiff.c, because, unlike hash
dumps and FSFS files, we accept svndiffs over the network. It seems
like one way to DOS a server would be to send an svndiff window with a
huge instruction or new data length, and then get the server to buffer
some large amount of data. You'd need commit access to do that, so it's
not so bad, but I have thought about proposing a "maximum reasonable
window size" constant to address the issue.
> also 'parse_url' from client.c is using atoi on the portnumber
> and leads to strange errors if a typo is using characters
> where the port number is expected, like in
> svn checkout http://some.url.at:X/repos/file
> svn checkout http://some.url.at:0/repos/file
> svn checkout http://some.url.at:80XYZ/repos/file
> svn checkout http://some.url.at:/repos/file
client.c applies to the svn:// protocol, not the http:// protocol. I
don't get particularly strange behavior from those examples or from
variants of them.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun May 2 17:23:43 2004