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.

Reply via email to