Re: [boost] Printf-style format specifiers

Subject: Re: [boost] Printf-style format specifiers
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-03-14 23:51:02

On 03/15/2010 01:34 AM, Vladimir Prus wrote:
> 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.

As I said, I understand its usage in C, because there's no other choice 
there. But in C++ we have better alternatives, ignoring which in favor 
of ellipsis seems not wise to me.

>> It is common knowledge
>> that sprintf-like functions are often misused, which results in buffer
>> overruns
>
> 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.

Are you implying that I'd have to reimplement sprintf in Boost.Log? 
Looks like a futile job to me.

>> 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.

Well, I don't render that point valid. In our company we develop under 
Windows, and MSVC doesn't give such warnings. Only GCC under Linux does, 
but many developers simply don't look at it since it compiles. You can 
argue it's our problem, but I'd say it's the problem with the API, if it 
allows such errors to slip silently.

Warnings are just an attempt (only partially successful) to solve the 
problems by some particular compiler vendors. I, as a lib developer, 
cannot rely on that the users of my lib will be using one of those 
"right" compilers.