[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <460A9951.2040401@rowe-clan.net>
Date: Wed, 28 Mar 2007 11:35:29 -0500
From: "William A. Rowe, Jr." <wrowe@...e-clan.net>
To: 3APA3A <3APA3A@...urity.nnov.ru>
Cc: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com
Subject: Re: SecurityVulns.com: Microsoft Visual C++ 8.0
standard library time functions invalid assertion DoS (Problem 3000).
3APA3A wrote:
> 11.10.2006 Vendor response:
>
> "We believe this is not a security vulnerability but in fact a
> deliberate security feature to mitigate problems with invalid data
> propagating through the system".
Proving once again that MS has ordered all of it's copies of K&R burned,
and will not declare victory until MS C[++] is entirely abstracted from
all existing standards and other implementations?
> [...] incorrectly behave for a time_t argument larger than or equal
> to _MAX__TIME64_T (representing January, 1 3000 00:00:00). According to
> MSDN documentation, time functions must indicate error by returning NULL
> pointer or EINVAL (depending on function class) and must not invoke any
> invalid parameter handler. Instead, time function calls invalid
> parameter assert()-like macro, terminating calling application and
> creating Denial of Service condition for calling application.
Considering that since the inception of these functions they were *unbounded*
(the entire 32bit time_t space can be trivially represented), and that the
MSC 8.0 change to 64 bit time_t is a *Microsoft* imposed *default* behavior,
and that they don't cite MAX_TIME_T, the response seems especially foolish.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists