[FFmpeg-devel] [BUG] UTF-8 decoder vulnerable to character spoofing attacks

Rich Felker dalias
Tue Oct 23 01:53:45 CEST 2007

On Mon, Oct 22, 2007 at 07:15:22PM +0200, Michael Niedermayer wrote:
> > lots of users have their locales set wrong, etc., but this is a
> > separate issue from the bug I reported of course.
> yes and a patch is welcome ...
> and a quick grep seems to indicate that only -f psp is affected
> asf assumes ASCII input, and actually i think there was a patch from
> someone which added UTF8 or some japanese encoding support to the asf
> muxer, dunno i dont remember
> also patch welcome

Glad you're interested in patches for these things. :)

> [...]
> > BTW, does ffmpeg even do anything with strings input from the command
> > line to convert them to UTF-8? AFAIK it's generating bogus files
> > unless the user's locale is UTF-8-based.
> add a check which exit() in ffmpeg.c if the locale is not UTF8 :)

This sounds like it would create a lot of angry users... :P
Surely we can come up with a better way..

> i think the case of just 0xff (without the terminating 0) at the
> top of the heap is quite obscure


> if such a invalid sequence can happen why not a the first byte of a
> valid one? the later would be undetectable and could crash even the finest
> UTF8 decoder

Nope, there's always a 0 byte at the end because this is a C string
(or at least that's my intent). Thus the unexpected 0 will throw the
illegal sequence and also termiante the loop that was calling

Actually the C multibyte functions have anothr approach that doesn't
need null-termination, passing a max length... I suppose that could be
done with the GET_BYTE implementation too..

> > If you look at the code, it's already inside { } except for one
> > statement at the beginning that could be moved inside. Then it's just
> but that would break gcc 2.95 ...

Just put it after the declarations... that was my intent anyway.

Actually I'm thinking of trying gcc4, since I have an idea to try
disabling all the stupid optimizations it does (stupid == noop unless
the coder is an idiot) and see if that makes the compile speed
comparable to 2.95..


More information about the ffmpeg-devel mailing list