nonsense in TR24731, §6.5.3.1

[Krzysztof Żelechowski]

TR24731, §5.6.3.1 brings a code sample that says { printf (argv); },
observes that it may leak information and concludes that printf is wrong and
it must be fixed. How does the introduction of printf_s fix this particular
case?

Further it examines the risks behind %n and argues that it can be used to
modify an arbitrary location in memory because ‘the corresponding argument
might be the literal characters in the format itself’. How could that
happen?

Chris

[James Kuyper]

On 05/12/2012 11:00 AM, Krzysztof Żelechowski wrote:
> TR24731, §5.6.3.1 brings a code sample that says { printf (argv); },
> observes that it may leak information and concludes that printf is wrong and
> it must be fixed. How does the introduction of printf_s fix this particular
> case?

ISO is charging CHF 108,00 for a copy of ISO/IEC TR 24731-2:2010. Is
there a cheaper way to get a copy of the text that you're asking about?

I've no idea which problem they might be thinking about, but at the very
least, printf_s(argv) will halt printing as soon as it runs into a "%n"
format specifier, whereas printf(argv) would actually attempt to write
to some garbage location in memory under those same circumstances.

> Further it examines the risks behind %n and argues that it can be used to
> modify an arbitrary location in memory because ‘the corresponding argument
> might be the literal characters in the format itself’. How could that
> happen?

Again, I'm not sure precisely what they're referring to, but on an
implementation which merges string literals, the following code will
probably have the described affect, unless there's an alignment issue,
in which case it has undefined behavior.

printf("%n\n", (int*)"%n\n");


--
James Kuyper

[Eric Sosman]

On 5/12/2012 11:00 AM, Krzysztof Żelechowski wrote:
> TR24731, §5.6.3.1 brings a code sample that says { printf (argv); },
> observes that it may leak information and concludes that printf is wrong and
> it must be fixed. How does the introduction of printf_s fix this particular
> case?

ITYM the Rationale, not the document, and 6.5.3.1 (as in your
Subject: line), not 5.6.3.1.

The program fragment is certainly a poor choice, since even a
C89 implementation is obligated to issue a diagnostic for it. As far
as I can see, substituting printf_s solves nothing: The diagnostic is
still required, and if the program executes anyhow the behavior is
still undefined (hence, could be just as undesirable).

> Further it examines the risks behind %n and argues that it can be used to
> modify an arbitrary location in memory because ‘the corresponding argument
> might be the literal characters in the format itself’. How could that
> happen?

The explanation given seems pretty clear, but also far-fetched.
"Since the format itself may be on the stack" is unlikely if the
format is some coercion of `argv' to `char*'.

But really, the `argv' thing is just an ill-thought-out red
herring. We can imagine a truly careless programmer doing something
along the lines of

char buff[500];
fgets(buff, sizeof buff, stdin);
printf(buff);

... which has all the dangers described in the Rationale, and others
besides. The proposed printf_s would address a few of them, but by
no means all.

--
Eric Sosman
eso...@ieee-dot-org.invalid

[lawrenc...@siemens.com]

James Kuyper <james...@verizon.net> wrote:
> On 05/12/2012 11:00 AM, Krzysztof ??elechowski wrote:
> > TR24731, ??5.6.3.1 brings a code sample that says { printf (argv); },

> > observes that it may leak information and concludes that printf is wrong and
> > it must be fixed. How does the introduction of printf_s fix this particular
> > case?
>
> ISO is charging CHF 108,00 for a copy of ISO/IEC TR 24731-2:2010. Is
> there a cheaper way to get a copy of the text that you're asking about?

He's talking about TR 24731-1 (which was just TR 24731 because we hadn't
planned on having a part 2 until after it was published). You can find
links to the final drafts on the committee web site on the Projects page:
TR 24731-1 is N1225 and TR 24731-2 is N1337. There's also a Rationale
for part 1 in N1173.

On further review, it looks like he's actually talking about the
Rationale, not the TR itself.
--
Larry Jones

I obey the letter of the law, if not the spirit. -- Calvin

[lawrenc...@siemens.com]

Eric Sosman <eso...@ieee-dot-org.invalid> wrote:
> On 5/12/2012 11:00 AM, Krzysztof ??elechowski wrote:
> > TR24731, ??5.6.3.1 brings a code sample that says { printf (argv); },

> > observes that it may leak information and concludes that printf is wrong and
> > it must be fixed. How does the introduction of printf_s fix this particular
> > case?
>
> ITYM the Rationale, not the document, and 6.5.3.1 (as in your
> Subject: line), not 5.6.3.1.
>
> The program fragment is certainly a poor choice, since even a
> C89 implementation is obligated to issue a diagnostic for it.

I believe the example was intended to be ``printf(argv[1]);'', which
does not require a diagnostic and may or may not be correct depending on
how the program is invoked.
--
Larry Jones

That's one of the remarkable things about life. It's never so
bad that it can't get worse. -- Calvin

[Eric Sosman]

On 5/12/2012 2:49 PM, lawrenc...@siemens.com wrote:
> Eric Sosman<eso...@ieee-dot-org.invalid> wrote:
>> On 5/12/2012 11:00 AM, Krzysztof ??elechowski wrote:
>>> TR24731, ??5.6.3.1 brings a code sample that says { printf (argv); },
>>> observes that it may leak information and concludes that printf is wrong and
>>> it must be fixed. How does the introduction of printf_s fix this particular
>>> case?
>>
>> ITYM the Rationale, not the document, and 6.5.3.1 (as in your
>> Subject: line), not 5.6.3.1.
>>
>> The program fragment is certainly a poor choice, since even a
>> C89 implementation is obligated to issue a diagnostic for it.
>
> I believe the example was intended to be ``printf(argv[1]);'', which
> does not require a diagnostic and may or may not be correct depending on
> how the program is invoked.

As I said, the constraint violation is just a red herring.
The vulnerabilities described in the Rationale would apply to
`printf(argv[1])', but as far as I can see the printf_s proposal
would eliminate only one of many. That's a gain, to be sure, but
perhaps not enough of a gain to warrant an "_s for safe" suffix.

--
Eric Sosman
eso...@ieee-dot-org.invalid