On Thu, 7 Jan 2010, Stephen Craig Evans wrote:
I am VERY curious to learn how these happened...
My name is Steve. I had a 2010 problem.
An internal CVE support program was "hit" by this issue. Fortunately,
there weren't any fatal results and it was only an annoyance. However: I
had an input validation routine that did a sanity-check on dates, which I
wrote sometime around 2005. The check would generate a specific complaint
if a date was 2010 or later since, after all, it was 2005 - a time when
resources for development were extremely low - and it worked back then.
(Now I'm starting to rationalize that all my bad practices back then were
"Agile" instead of "cheap hacks." Yes, that was deliberately
inflammatory.)
The regexp to check the year was something like /^(199\d|200\d)$/, and the
informative error message would say that the year portion of the date
appeared to be invalid. There was a separate check that also made sure
that a given date wasn't in the future, so this message was basically a
secondary bit of detail.
Anyway, 5 years passed and I forgot about the limitation of that routine
until it started generating informational error messages when CVE team
members submitted new CVE content.
One could say that this was under the radar of my threat model when it
should have been part of the threat model for these major vendors, but it
was still a known bug/feature that never got fixed until it had to be
fixed.
I'm sure I have a few other date-sensitive dependencies that are not a
high priority to fix, given current conditions and practices. I'll
probably be close to retirement age come 2038 when the Unix year bug shows
up. If CVE is still around then, and my code is still being used, well,
it's gonna be someone else's problem.
Anybody else willing to admit their 2010 mistakes and the conditions that
led to them? Or was it just me and a couple huge companies?
- Steve
_______________________________________________
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
_______________________________________________
