Thank you for pointing this out -- it is fixed now.
-K
Change message:
Fix D.o.S opening reported by <[EMAIL PROTECTED]>:
* server.c (pserver_authenticate_connection): use new
getline_safe() during authentication phase, to avoid a
denial-of-service attack in which client sends arbitrary
amounts of data with no newlines.
* sanity.sh: new test pserver-14 for above.
* myndbm.c: #include getline.h.
(mydbm_load_file): pass new GETLINE_NO_LIMIT flag to getstr().
* getline.h, getline.c (getstr): take new limit arg.
(GETLINE_NO_LIMIT): new #define.
(getline_safe): new function, takes limit arg and passes it on.
(getline): pass GETLINE_NO_LIMIT to getstr().
[EMAIL PROTECTED] writes:
> In server.c , towards the beginning of pserver_authenticate_connection(),
> there is the following code which is attempting to determine if a valid
> authentication request is being made:
>
> /* Make sure the protocol starts off on the right foot... */
> if (getline (&tmp, &tmp_allocated, stdin) < 0)
> /* FIXME: what? We could try writing error/eof, but chances
> are the network connection is dead bidirectionally. log it
> somewhere? */
> ;
>
> Unfortunately, getline() imposes no restrictions on the amount of data
> it will try to get. Thus, a completely unauthenticated remote
> attacker can connect to a cvs pserver and cause it to allocate memory
> arbitrarily, since getline() just keeps reallocing as it gets fed
> data.
>
> Fix would be to create a getnline() function that took an additional
> argument restricting the amount that getline() was prepared to
> allocate, and use this to impose appropriate restrictions on line
> length.
>
> This is easy to do for the first getnline() - the maximum line length
> that could be validly sent to us is the length of the string
> "BEGIN VERIFICATION REQUEST\n" . The next three getline() calls would
> need more thought, since the maximum length of a repository name, a
> username, and a password are (presumably) determined by restrictions
> imposed by the OS on which the server is running.
>
> -patrick.