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]
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: 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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ