bugtraq - Re: SecurityVulns.com: Microsoft Visual C++ 8.0 standard library time functions invalid assertion DoS (Problem 3000).

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

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: bugtraq@...urityfocus.com, full-disclosure@...ts.grok.org.uk
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.