Re: Buffer overflows and asctime()

jacob navia <jacob@xxxxxxxxxx> writes:
James Kuyper wrote:
jacob navia wrote:
James Kuyper wrote:
jacob navia wrote:
Keith Thompson wrote:
...
I just can't imagine why tm->tm_seconds would have a value
of 999 in correct code!
I presume, therefore, that you are unfamiliar with the use of
mktime()'s normalization feature to perform date/time arithmetic.

Hello? Hello?

Mr Kuyper the subject of this thread is asctime() and what I say
it is within this context! I have never mentioned
mktime nor anybody else has.

I've mentioned mktime() at least twice in this thread, and several
more times in closely related threads in this newsgroup in the last
few days. Others have as well. You've posted at least one followup
to something I posted in this thread, so I know at least some of my
articles are getting through.

Perhaps if we didn't have to spend so much time correcting your
elementary factual errors, we could actually discuss your proposal.

Now read this carefully. I'm going to use the value 99 rather than
999 just to avoid buffer overflow issues that are not relevant to the
point I'm making in this article.

Calling mktime() with timeptr->tm_sec == 99 is explicitly permitted by
the standard ("the original values of the other components are not
restricted to the ranges indicated above"). (I'm aware that you
haven't claimed otherwise.)

Calling asctime() with timeptr->tm_sec == 99 is permitted, and has
well defined behavior, because the algorithm for asctime() is defined
specifically in terms of C code, and that C code has no problem with
timeptr->tm_sec == 99, and because nothing in the standard forbids
tm_sec == 99.

Any argument that calling asctime() with timeptr->tm_sec == 99 is
*not* permitted rests on the assumption that values outside the
"normal ranges" specified in C99 7.23.1p4 are "invalid values" as
described in C99 7.1.4p1. The standard does not say this, nor does it
define the term "normal ranges".

The behavior of asctime() is defined entirely by the implementation
presented in the standard. You cannot reasonably project your own
assumptions onto the standard's definition, however reasonable those
assumptions might appear to be.

[...]

where
the behavior of code calling asctime() is standard defined, the
behavior should remain unchanged, which would not be the case with
your proposed change.

No. Instead of writing out of range values even if they do not
overflow, asctime() should emit an error report according to
the general principle of fail safe programming.

You're saying it *should* do so. I don't disagree. I'm saying it
*doesn't* do so now, and *cannot* do so in all cases without violating
the (rather odd) requirements of the current standard.

[...]

The objective of this discussion is to clean up the C standard from
a reference implementation containing a buffer overflow. I propose
a version that will NEVER overflow its buffer and will diagnose
any overflow in the input values specifically for the field that
overflows.

I can't understand why you prefer to leave a code that contains a
buffer overflow. It is completely incomprehensible for me.

The current implementation of asctime() does not "contain" a buffer
overflow. It *can* cause a buffer overflow if you call it with
certain arguments. A program that performs a call to asctime() with
certain arguments contains a buffer overflow, one that simply does not
exist without those arguments.

A program that calls asctime() with "normal" arguments (all members
within their "normal ranges", and tm_year in the range [-2899, 8099])
*has no buffer overflow*.

The member values for which the behavior of asctime() is not defined
are not specied by the standard with sufficient clarity. I would like
to see that corrected, and I've made a concrete proposal for a change
to the standard that would do so.

There are dozens of standard C functions that can cause a buffer
overflow if you call them with in appropriate arguments (sprintf,
strcpy, strcat, etc., etc.). We're able to cope with that because the
circumstances under which these buffer overflows occur are reasonably
well defined. The corresponding circumstances for asctime are defined
unambiguously by the present algorithm, but are not stated clearly in
the English text. If that were corrected, asctime would be no more
problematic that strcat.

--
Keith Thompson (The_Other_Keith) kst-u@xxxxxxx <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
.

Relevant Pages

  • Re: Buffer overflows and asctime()
    ... Mr Kuyper the subject of this thread is asctime() and what I say ... that this was a standard piece of the toolkit of any programmer sufficiently competent to dream of actually implementing the C standard library. ... But if the new ones are approved, there's no point in doing any maintenance to the older functions beyond, for example, solving the the buffer overflow; ...
    (comp.std.c)
  • Re: Buffer overflows and asctime()
    ... It is a real detriment to the language to be the one ... Tweaking asctime() to avoid buffer overflows (at least when the ... a code that displays a buffer overflow from the TEXT OF THE STANDARD. ...
    (comp.std.c)
  • Re: Buffer overflows and asctime()
    ... discussion by disagreeing about what the standard says about asctime? ... There are numerous other library functions that have undefined behavior ... This buffer overflow looks like it is NOT a design feature since ...
    (comp.std.c)
  • Re: Performance considerations for asctime code
    ... The C standard is written for the real world where the existence of real machines with trap representations required the committee to add wording to allow conforming implementations of C on those machines. ... The C standard's definition of the behavior of asctime() should be compatible with the fact that the C standard allows such implementations. ... It's hard to come up with a realistic counter-example - almost as hard as it is to come up with a realistic counter-example that produces buffer overflow. ...
    (comp.std.c)
  • Re: Performance considerations for asctime code
    ... What will happen in that case when asctime() attempts to validate ... you're proposing a change to the standard. ... For year 120000 you will get a buffer overflow, ... behavior of this *strictly conforming* program. ...
    (comp.std.c)