Re: possible su local D.o.S

[Jose Nazario <jose () biocserver BIOC cwru edu>]

On Thu, 13 Dec 2001, H VC wrote:

> I have noticed that it only seems to work whe I parse a user string to
> su near the limit ( free mem. + swap ). Over this range is detected as
> a too many large string but also just over the available memory...

a quick perusal through the su.c source code in that SRPM reveals a likely
culprit: the function 'concat':

    190 /* Return a newly-allocated string whose contents concatenate
    191    those of S1, S2, S3.  */
    192
    193 static char *
    194 concat (const char *s1, const char *s2, const char *s3)
    195 {
    196   int len1 = strlen (s1), len2 = strlen (s2), len3 = strlen (s3);
    197   char *result = (char *) xmalloc (len1 + len2 + len3 + 1);
    198
    199   strcpy (result, s1);
    200   strcpy (result + len1, s2);
    201   strcpy (result + len1 + len2, s3);
    202   result[len1 + len2 + len3] = 0;
    203
    204   return result;
    205 }

basically the code happily xmalloc's the proper length argument to prevent
an overflow, but doesn't do ANY sanity checking on lengths ...

> Why su allows so large user names ?
> How long could be a unix/linux user name ?
> Why do not su limit the size of username to the unix/linux max. size of a
> user name ?

these are perfectly valid questions, and they should definitely be fixed
in the implementation. chop it off at the MAX_LOGIN_NAME size ...

looks like good intentions gone horribly awry.

____________________________
jose nazario                                                 jose () cwru edu
                     PGP: 89 B0 81 DA 5B FD 7E 00  99 C3 B2 CD 48 A0 07 80
                                       PGP key ID 0xFD37F4E5 (pgp.mit.edu)