Fix bad_format_imginfo

[aschmitz]

The previous behavior could segfault with an imginfo string such as "%s%s %lux%lu", whereas this correctly rejects that format string.

The segfault was exposed in a number of programs that call out to rrdtool, and can occasionally cause a denial of service condition for them as well.

If it's feasible for you to cut a new release given that bad_format_imginfo doesn't exist at all in 1.4.8, that would be helpful. The lack of bad_format_imginfo can be a more exploitable security concern, while this change is "just" a denial of service. (This pull request still addresses a security concern, but it's less important than the raw format string being exposed.)

[aschmitz]

This has been assigned CVE-2014-6262. It's not a huge deal on its own (generally leading to a segfault, or possibly an information leak), but it has some impact on applications that use RRDtool, so we wanted to make sure we can track it.

[oetiker]

you are aware, that your patch does NOT fix the problem, right? The whole bad_format_imginfo code is rather ... how shall I put it ... I should never have accepted it ...

I am a bit torn on this one ... if someone exposes a format string to uncontrolled outside configurability, which rrdtool does not. Why would you want to blame rrdtool and why not libc ?

Will look into sanitizing this properly ...

[oetiker]

64ed531 and
85261a0 fix this properly

[aschmitz]

Ah, indeed I missed the other places that may have been vulnerable to the
same issue. (And re-ordering the arguments might have also caused problems,
as I didn't try that either.) Thank you for providing what appears to be a
much more complete fix.

(As for it being libc's fault, it's somewhat hard for libc to check, given
the stack calling conventions. I do agree that it's a pain to have to guard
for everywhere, rather than nicely being able to handle it once in libc.)

On Tue, Sep 16, 2014 at 1:15 AM, Tobias Oetiker notifications@github.com
wrote:

you are aware, that your patch does NOT fix the problem, right?

—
Reply to this email directly or view it on GitHub
#532 (comment).