Subject: Re: [boost] Printf-style format specifiers (was: Review - boost::log)
From: Vladimir Prus (ghost_at_[hidden])
Date: 2010-03-14 18:34:36
On Monday 15 March 2010 01:10:10 Andrey Semashev wrote:
> On 03/15/2010 12:50 AM, Vladimir Prus wrote:
> > On Sunday 14 March 2010 23:37:06 Scott McMurray wrote:
> >> On 14 March 2010 15:21, Tom Brinkman<reportbase2007_at_[hidden]> wrote:
> >>>> The printf style parameters is responsible for thousands and thousands of
> >>>> security vulnerabilities.
> >>> Just plain wrong.
> >> Some evidence for your position would be good, since it's trivial to
> >> find documentation of holes from printf-style parameters:
> >> http://en.wikipedia.org/wiki/Format_string_attack
> > I don't think that's hole from printf-style parameters. By reading that
> > page it's trivial to notice that it's the %n format specifier -- which
> > actually writes something into program -- is the key component of attack.
> > Clearly a printf-like function that does not support any way to modify
> > program state is safe. Am I missing something?
> You do understand that the use of ellipsis is error-prone, even if it
> doesn't lead to program modification, do you?
Error prone in what way? That you can pass integer for %s and get garbage? Well,
good compilers tend to help:
a.c:12: warning: format â%sâ expects type âchar*â, but argument 2 has type âintâ
And even without compiler help, a tradeoff between convenience and accidental
bug is a valid tradeoff. Saying that elipsis is a no-no seems a bit too much.
> It is common knowledge
> that sprintf-like functions are often misused, which results in buffer
Uhm. You cannot have buffer overrun if you don't have a buffer, don't you
think? I don't think anybody suggests that boost.log sprintfs anything into
a fixed-size buffer.
> or incorrect arguments being passed. In C++, the problem of
> accidental passing of non-POD typed arguments is added.
For all I know, there's no such problem:
a.c:19: warning: cannot pass objects of non-POD type âstruct Sâ through â...â; call will abort at runtime
Of course, some folks ignore warnings, but well, they probably have bigger problems.