[Uim-bugs] [Bug 11411] ParseComposeStringFile() is dubious

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=11411





------- Comment #4 from christianbiere at gmx.de  2007-07-11 06:50 PST -------
No, it is really possible to cause a buffer overflow, if the file changes after
you've determined its filesize because the code assumes no token will be larger
than the file itself. This is a reasonable assumption, if and only if you're
working with atomic objects or using atomic operations. That's not the case
here.

If you look at nexttoken() in gtk/compose.c (the old version before your edit)
you can see that there are two loops which only terminate if certain characters
are found and otherwise keep on writing to the pre-allocated token buffer. As
you basically you use getc() to fetch characters from the file, the originally
determined filesize is nowhere taken into account. Thus in case of a growing
file, you may very well run over the last element of the token buffer.

Note, I'm very well aware that this scenario is far from being a realistic
security issue or the like. This was not the point of my report. The point was
simply that this parsing algorithm was fundamentally flawed. If and only if you
read the whole file into memory for parsing and ensured that the last character
is a terminator, then this algorithm could be applied.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.