Hi, 2011/6/12 Måns Rullgård <[email protected]>: > Alex Converse <[email protected]> writes: >> 2011/6/12 Måns Rullgård <[email protected]>: >>> "Ronald S. Bultje" <[email protected]> writes: >>>> On Tue, May 24, 2011 at 8:14 AM, Anton Khirnov <[email protected]> wrote: >>>>> From: Michael Niedermayer <[email protected]> >>>>> >>>>> This may be security relevant depending upon the used terminal. >>>>> >>>>> Signed-off-by: Michael Niedermayer <[email protected]> >>>>> Signed-off-by: Anton Khirnov <[email protected]> >>>>> --- >>>>> libavutil/log.c | 9 +++++++++ >>>>> 1 files changed, 9 insertions(+), 0 deletions(-) >>>>> >>>>> diff --git a/libavutil/log.c b/libavutil/log.c >>>>> index c44130c..fe9a54e 100644 >>>>> --- a/libavutil/log.c >>>>> +++ b/libavutil/log.c >>>>> @@ -80,6 +80,14 @@ const char* av_default_item_name(void* ptr){ >>>>> return (*(AVClass**)ptr)->class_name; >>>>> } >>>>> >>>>> +static void sanitize(uint8_t *line){ >>>>> + while(*line){ >>>>> + if(*line < 0x08 || (*line > 0x0D && *line < 0x20)) >>>>> + *line='?'; >>>>> + line++; >>>>> + } >>>>> +} >>>>> + >>>> >>>> What idiot (sorry) would av_log() such characters? Isn't this pebkac? >>> >>> The patch author presumably. >>> >>> I agree, this is pointless. Such characters can end up in av_log() >>> output in one of two ways: >>> >>> 1. They are part of the format string. >>> 2. They are part of a %s argument. >>> >>> Only a complete idiot would do 1. 2 could happen only if a buffer with >>> unknown content were passed as argument to %s. If the contents are not >>> known, it is probably not null-terminated either, and you have a much >>> bigger problem. In other words, only an idiot would that too. >>> >> >> What about trying to print a fourcc or the like with "%.4s"? > > Don't do that.
To elaborate, we should take a hexdump-style approach here, assume data is unsafe and fix it up before printing. Printing a fourcc is fun, but it's even more useful if it gives us the hex if not a normal alphanumerical character, etc.. printf-style-formatting allows this, and we should not be lazy but take advantage of this. Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
