Re: Badly formatted 'ls -l'

[Jim Meyering]

Paul Eggert <address@hidden> wrote:
> Jim Meyering <address@hidden> writes:
>
>> Please let us know if this is of more than theoretical interest.
>> If it's the one I'm thinking of, there was so much slack in the other
>> terms contributing to that buffer's length that one would be very
>> hard-pressed to contrive circumstances to provoke an actual overrun.
>
> The only circumstances that I can see is when the attacker has some
> control over user names, and can request a very long user name (or
> group), e.g. for a nonce account.  This isn't likely in wuftpd-like
> scenarios.  I could probably construct a scenario where it is
> possible, but it's not one I've ever run into myself.

Hi Paul,

Could you construct such a scenario on a non-Hurd system?
I would have thought we'd be covered by the following definition
and with the three `ID_LENGTH_MAX + 1' terms:

  /* The maximum length of a string representation of a user or group ID,
     not counting any terminating NUL byte.  */
  #define ID_LENGTH_MAX \
    MAX (LOGIN_NAME_MAX - 1, LONGEST_HUMAN_READABLE)

  char init_bigbuf
    [LONGEST_HUMAN_READABLE + 1         /* inode */
     + LONGEST_HUMAN_READABLE + 1       /* size in blocks */
     + sizeof (modebuf) - 1 + 1         /* mode string */
     + LONGEST_HUMAN_READABLE + 1       /* st_nlink */
     + ID_LENGTH_MAX + 1                /* owner name */
     + ID_LENGTH_MAX + 1                /* group name */
     + ID_LENGTH_MAX + 1                /* author name */
     + LONGEST_HUMAN_READABLE + 1       /* major device number */
     + LONGEST_HUMAN_READABLE + 1       /* minor device number */
     + 35 + 1   /* usual length of time/date -- may be longer; see below */
     ];

I see that LOGIN_NAME_MAX is defined to 256 with linux-2.4.22/glibc.
Or maybe you're thinking of a system for which ID_LENGTH_MAX wasn't accurate?
I suppose the Hurd may not define LOGIN_NAME_MAX, or may define it
to be very large.  I don't have access to a Hurd system so can't check that.

>> I replaced these lines
>>   dired_pos += width;
>>   dired_pos++;
>> with this one
>>   dired_pos += width + 1;
>
> Actually, it'd be better to uniformly use
>
>   dired_pos += width;
>   dired_pos++;

Does the Hurd -- or any system -- really let struct passwd's pw_name
point to a string of length INT_MAX?

> since it works in some cases when the "width + 1" form does not work.
> For example, in the common case where int is 32-bits and size_t is
> 64-bits, "width + 1" will overflow when width is INT_MAX, but the
> two-line form will work correctly.  (Admittedly it's not very likely
> for strlen (username) to be INT_MAX, but I'm sure you can arrange it
> with the Hurd.  :-)