Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <jjvhb4$tgv$1@dough.gmane.org>
Date: Fri, 16 Mar 2012 15:05:18 +0100
From: finkler <finkler@...icinamentis.org>
To: musl@...ts.openwall.com
Subject: Re: utmpx support

On 06.03.2012 02:30, Rich Felker wrote:
> On Sun, Mar 04, 2012 at 08:10:36PM +0100, finkler wrote:
> Append mode is definitely not correct if you want to be able to
> overwrite existing entries.
Changed it to r+ and r

> I'm confused about the intent of this code.. Presumably it's supposed
> to modify the entry it just found (relying on getutxid leaving the
> file at the right position), but that's not going to work because the
> file is opened in append mode.
>
> Also, -(sizeof ut) is not a valid offset; it's almost SIZE_MAX. If you
> were using fseeko, this would result in a gigantic offset (rather than
> a negative one) after the conversion; with fseek (which takes a long),
> it should convert back to the desired negative value, but for safety
> you should cast to a signed type *before* negating the result of
> sizeof
Made the cast inside the function call.

> There's also the issue that there's absolutely no locking on updates,
> so if multiple apps try to add/update utmp entries at the same time,
> the file would be corrupted. This could be fixed by using an fcntl
> lock on fileno(f) for the duration of the function.
I added a lock, however, I am unsure whether I should use a lock that 
waits until it is free or not, and whether I should lock the whole file, 
or just the portion which is about to be written.
Right now I use a waiting lock, and lock the whole file.

 > Here strcmp is being called on data that was read from a file with no
 > validation. This is potentially a security issue (DoS); if the file
 > does not contain a null-terminated string, strcmp could run past the
 > end of the buffer and eventually segfault and crash the calling
 > program. It's probably hard to trigger the issue since the string for
 > comparison is also located in a utmp structure, but I think there
 > should be some validation, probably just fixing invalid data right
 > after the fread call so it never leaks out.
I changed it to use strncmp with the sizeof the respective struct field, 
is this enough?

Thank you very much for your time, I attached the reworked version.

View attachment "utmpx.c" of type "text/plain" (2053 bytes)

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.