| To: | 3APA3A <3APA3A@security.nnov.ru> |
|---|---|
| Subject: | Re: SecurityVulns.com: Microsoft Visual C++ 8.0 standard library time functions invalid assertion DoS (Problem 3000). |
| From: | "William A. Rowe, Jr." <wrowe@rowe-clan.net> |
| Date: | Wed, 28 Mar 2007 11:35:29 -0500 |
| Cc: | bugtraq@securityfocus.com, full-disclosure@lists.grok.org.uk |
| Delivered-to: | sp-com-lists@consult.net |
| Delivered-to: | bugtraq-list@securepoint.com |
| Delivered-to: | mailing list bugtraq@securityfocus.com |
| Delivered-to: | moderator for bugtraq@securityfocus.com |
| In-reply-to: | <4711942765.20070213014642@security.nnov.ru> |
| List-help: | <mailto:bugtraq-help@securityfocus.com> |
| List-id: | <bugtraq.list-id.securityfocus.com> |
| List-post: | <mailto:bugtraq@securityfocus.com> |
| List-subscribe: | <mailto:bugtraq-subscribe@securityfocus.com> |
| List-unsubscribe: | <mailto:bugtraq-unsubscribe@securityfocus.com> |
| Mailing-list: | contact bugtraq-help@securityfocus.com; run by ezmlm |
| References: | <4711942765.20070213014642@security.nnov.ru> |
| User-agent: | Thunderbird 1.5.0.10 (X11/20070302) |
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. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [SECURITY ALERT] osTicket bugs, eticket |
|---|---|
| Next by Date: | Cisco Security Advisory: Multiple Cisco Unified CallManager and Presence Server Denial of Service Vulnerabilities, Cisco Systems Product Security Incident Response Team |
| Previous by Thread: | Re: [SECURITY ALERT] osTicket bugs, eticket |
| Next by Thread: | Cisco Security Advisory: Multiple Cisco Unified CallManager and Presence Server Denial of Service Vulnerabilities, Cisco Systems Product Security Incident Response Team |
| Indexes: | [Date] [Thread] [Top] [All Lists] |