[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Badly formatted 'ls -l'
From: |
Jim Meyering |
Subject: |
Re: Badly formatted 'ls -l' |
Date: |
Tue, 09 Dec 2003 09:31:17 +0100 |
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. :-)