Re: Questions about C1x

jacob navia <jacob@xxxxxxxxxx> writes:
[...]
Because if you give it a year bigger than 8899, adding 1900 to it
will produce a number >= 10 000. This means that 5 positions of the
output buffer will be used isntead of 4, overwriting the terminating
zero.

This is a buffer overflow where there isn't any access to the [ ]
operator. As I told you before, I am not speaking about the possibility
that the month is bigger than 12, making it index a wrong position in
the table of months names. I am NOT speaking about THAT possibility.

I am speaking about the fact that any year bigger than 8899 will
overflow the buffer. No limitations are specified for that value.

The same problem happens if you pass it a negative value bigger than
-2899.
[...]

This is all correct. If you call asctime() with a tm_year value
greater than 8899 or less than -2899, the behavior is undefined.
If you call it with a tm_year value inside that range, and all other
members of the struct tm are within ranges that can also be easily
determined, then the behavior is well defined.

(asctime() *can* be used perfectly safely if the programmer exercises
a bit of care. In particular, it can be used safely with a struct
tm value generated by gmtime() or localtime() for the current time
for the next several thousand years.)

And you were able to derive all this information from the standard's
description of asctime(). Anyone else could derive the same
information.

The problem you keep complaining about doesn't exist, at least
not in the severe form that you claim.

--
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: Questions about C1x
    ... This is a buffer overflow where there isn't any access to the ... If you call asctime() with a tm_year value ... people who are *paying* for the privilege of doing the work might well consider that there are more important things for them to do than either making the limit more explicit or removing the undefined behavior. ...
    (comp.std.c)
  • Re: Buffer overflows and asctime()
    ... requires C implementations to have this buffer overflow? ... This is the same for all functions including asctime. ... Showing as *sample code* code that has an implicit buffer overflow ... Excuse me but a "potential buffer overflow" is for me a BUG! ...
    (comp.std.c)
  • Re: Writing a SECURE daemon
    ... If you are going to chroot the daemon, switch to chroot jail root ... More data can be copied into buffer that they can contain. ... normally the buffer overflow will alter saved EIP of the ... As consequence, attacker can substitute ...
    (comp.os.linux.security)
  • Re: main() in C90
    ... For the buffer not to overflow: ... With asctime(), the problem is non-obvious and merely quietly suggested. ... So one *will* spot the limited ... deduce the ranges that I did deduce (and not quite so trivial to spot that ...
    (comp.lang.c)
  • Re: lcc-win32
    ... >>overflow in the code of the asctime function, printed in the standard. ... The implication is that a call to asctimeinvokes undefined behavior ... if the result doesn't fit into the 26-byte result buffer (e.g., ...
    (comp.lang.c)