Author Topic: The next millennium bug  (Read 3889 times)

The next millennium bug
« on: 13 April, 2021, 07:14:48 am »
Once upon a time millions of coders had to sit down and fix programs that had been written by other coders who forgot about four digit year numbering.

This time we have a problem because coders never imagined one day their code might be plumbed into a thing called ‘the internet’ where there are bad people.

Quote
Issues show up so often in these ubiquitous network protocols because they've largely been passed down untouched through decades as the technology around them evolves. Essentially, since it ain't broke, no one fixes it.

“For better or worse these devices have code in them that people wrote 20 years ago—with the security mentality of 20 years ago,” says Ang Cui, CEO of the IoT security firm Red Balloon Security. “And it works, it never failed. But once you connect that to the internet it’s insecure and that’s not that surprising given that we've had to really rethink how we do security for general purpose computers over those 20 years.”

https://www.wired.com/story/namewreck-iot-vulnerabilities-tcpip-millions-devices/amp
Move Faster and Bake Things

Re: The next millennium bug
« Reply #1 on: 13 April, 2021, 07:21:27 am »
Yup. That's why any organisation with any idea about security at all runs their IOT stuff on a separate logical network where it cant access any other stuff and firewalls it from the Internet too (at a minimum - better to be watching that network with some kind of threat monitoring tools as well).
For home networks I would stick all the IOT stuff on a separate VLAN or WiFi network and firewall it from your computers.
I think you'll find it's a bit more complicated than that.

Ben T

Re: The next millennium bug
« Reply #2 on: 13 April, 2021, 08:44:11 am »

rogerzilla

  • When n+1 gets out of hand
Re: The next millennium bug
« Reply #3 on: 13 April, 2021, 09:20:52 am »
Remember NNTP?  Designed for a time when only academics used the Internet.  By 2000, it was wall-to-wall Viagra spam and porn.
Hard work sometimes pays off in the end, but laziness ALWAYS pays off NOW.

Beardy

  • Shedist
Re: The next millennium bug
« Reply #4 on: 13 April, 2021, 09:40:13 am »
As a former IT security specialist, I have thus far rejected IoT and cloud based solutions because I don’t want to put my data or operations on other peoples computers. It’s becoming increasingly difficult to avoid largely because the subscription model is so attractive to the money grabbling bastards accountants in charge of most IT companies. The money grabbing bastards accountants also won’t pay to fix things that work* or to provide features that the customer can’t see or use.

*as mentioned in the OP
For every complex problem in the world, there is a simple and easily understood solution that’s wrong.

rogerzilla

  • When n+1 gets out of hand
Re: The next millennium bug
« Reply #5 on: 13 April, 2021, 09:46:22 am »
Cloud is horrible from a performance point of view.  It relies on the Internet, and the Internet can be slow or broken for many reasons, with no-one in particular to blame.
Hard work sometimes pays off in the end, but laziness ALWAYS pays off NOW.

Re: The next millennium bug
« Reply #6 on: 13 April, 2021, 10:02:54 am »
Cloud is horrible from a performance point of view.  It relies on the Internet, and the Internet can be slow or broken for many reasons, with no-one in particular to blame.

I was in a meeting a couple of years ago at one of the more important government departments. The kind of meeting where you have a guy from GCHQ sat in the corner just to make sure no one agrees to anything amazingly stupid from a security point of view. We were doing a strategic review of their ways of working with IT. One of the senior civil servants had drunk the Kool-Aid from the cloud companies. He had the idea that they could move all their IT into the cloud and review the cost every six months and if they could get it cheaper just move everything to a different cloud hosting at the flick of a switch. How we laughed and how the GCHQ bod scowled and pointed out that most of them are US companies and they certainly weren't putting sensitive government data in US hands.
The other thing I found amusing was the plan to replace all PCs with laptops, actually two laptops as civil servants couldn't be expected to carry a laptop home so they needed one for the office and one for home ....
I think you'll find it's a bit more complicated than that.

Re: The next millennium bug
« Reply #7 on: 13 April, 2021, 10:31:20 am »
Once upon a time millions of coders had to sit down and fix programs that had been written by other coders who forgot about four digit year numbering.

In some companies.  But not in others where internal dates were stored as number of days since Jan 1, 1901 and there was a central date routine called to convert between any two date formats.  I remember in 1996-1998 that although we spent those two / three years testing everything, there was very little that needed “fixing”.

Re: The next millennium bug
« Reply #8 on: 13 April, 2021, 01:48:48 pm »
This time we have a problem because coders never imagined one day their code might be plumbed into a thing called ‘the internet’ where there are bad people.

Yes, people writing TCP/IP code had no clue the internet would exist one day in the future.

Reading the technical report* the problem is in some packet parsing code written in C, which is the worst language to choose to write sensitive secure code, but in the past it was the only thing considered (and still is in too many places now).

The exploit requires returning a specially crafted invalid DNS response packet, so presumably requires man-in-the-middle access to exploit, and could potentially be blocked at the router.

(* gloriously the Name:Check link in the Wired article shows me a Site Not Secure page due to an expired certificate)

Re: The next millennium bug
« Reply #9 on: 13 April, 2021, 03:53:46 pm »
Once upon a time millions of coders had to sit down and fix programs that had been written by other coders who forgot about four digit year numbering.

In some companies.  But not in others where internal dates were stored as number of days since Jan 1, 1901 and there was a central date routine called to convert between any two date formats.  I remember in 1996-1998 that although we spent those two / three years testing everything, there was very little that needed “fixing”.
ICL's (British company) operating systems did that. Handled dates long into the future. All you had to do was put calls to the built in date routine into your programs. Didn't stop people who used their computers screwing things up, though. Yellow Pages, for example, introduced a system in the 1980s for storing all their subscriber data. Directories could be generated & printed straight from the database, with the standard lline entry or additional ads. That worked pretty well, as I recall - in 1988.

All dates on the database were stored as YYDDD.  :facepalm:

When I (a humble contractor) suggested in a meeting at the end of the 1980s that given the lead times on major developments, future dates on the database, & the mad rush for staff there would be in the late 1990s, perhaps someone should pencil in as a point for consideration changing the date handling (just converting to CCYYDDD would do it) in a few years, the head of IT laughed out loud, & mocked me.

In 1998 I was an employee of another company, & among other things, fixing programs that foolish people had rendered incapable of functioningly correctly in 2000 despite the availability of a built-in date function that worked perfectly, e.g. a bit of code in a program to work out whether a year was a leap year or not (Doh! No need! Just use the bloody built-in routine!) which assumed that 2000 would not be a leap year. The silly billy thought that just because 1800 & 1900 weren't leap years & 2100, 2200 & 2300 wouldn't be, that 2000 wouldn't be. It's except when it's divisible by 100, & not by 400. Tut tut! And there were others. But we found & fixed them all in time. IIRC we had a total of four reported problems. One was a corrupt file header from someone else: logged, referred back to the company sending it. They'd fix it, because if the data couldn't be read we couldn't reimburse them for calls our subscribers had made on their network. ;D Another was our Dutch subsidiary having failed to implement a fix we'd sent them the year before. They spotted it & put it right while I was looking at the problem. Laugh, log & get back to my book. Ten minutes wasted. The others were equally trivial.

But I digress. Back to the point - I saw an advert for contractors who knew the OS, language, & database that the Yellow Pages system used, for a company that was not named but which was obvious. Urgent requirement! Good rates! A discreet enquiry to a former colleague whose contact details I still had told me that yes, it was still in use, & he was bloody glad he'd left before the clusterfuck which he'd heard was now going on. IIRC nothing had been done to the old system because it would be replaced just in time  - but then it got too far behind the rather tight schedule, not helped by the difficulty hiring because of everyone panicking about Y2K . . . .

My turn to laugh.
"A woman on a bicycle has all the world before her where to choose; she can go where she will, no man hindering." The Type-Writer Girl, 1897

TheLurker

  • Goes well with magnolia.
Re: The next millennium bug
« Reply #10 on: 13 April, 2021, 04:46:49 pm »
Quote from: asterix
...coders who forgot about four digit year numbering.
Ermm.  Not quite.  Disk & memory was horribly, horrribly expensive so you used as little of it as you could get away with because the machines didn't have very much to begin with. There were OSes that had sane, compact date storage formats that were amenable to the use of supplied or in-house libraries, Yay MUMPS!, but not all and there was, even up to the late 1980s, a general mindset that computer software was something with a useful life measured in a small handful of years rather than decades.   Truly, hindsight is the most precise of sciences.
Τα πιο όμορφα ταξίδια γίνονται με τις δικές μας δυνάμεις - Φίλοι του Ποδήλατου

Kim

  • Timelord
    • Fediverse
Re: The next millennium bug
« Reply #11 on: 13 April, 2021, 05:29:50 pm »
There's plenty of hardware that still works to a 2-digit year internally.  I used one of these for a project recently.  (I'm suspicious the datasheet author may be trolling us with the dates in the revision history on the last page.)


Anyway, we're all looking forward to the Unix epoch rollover in 2038...

DaveJ

  • Happy days
Re: The next millennium bug
« Reply #12 on: 13 April, 2021, 06:30:30 pm »
I remember being asked to look at a date routine back in the 80s that used a single digit.  The routine was there to translate single digit years to 2 digits for later programs that needed both digits.  The application was COBOL68, but the date "fix" was in assembler (which is why I was looking at it).  I didn't write it!!!

I can't remember what happened in the end, whether I updated it, or whether the application people recompiled all the programs which used that field and got rid of the kludge.  I have a vague memory that the source code for one of the programs (written in late 60 or early 70s) was missing, so maybe they didn't have any option.
   

Re: The next millennium bug
« Reply #13 on: 13 April, 2021, 10:08:13 pm »
Quote from: asterix
...coders who forgot about four digit year numbering.
Ermm.  Not quite.  Disk & memory was horribly, horrribly expensive so you used as little of it as you could get away with because the machines didn't have very much to begin with. There were OSes that had sane, compact date storage formats that were amenable to the use of supplied or in-house libraries, Yay MUMPS!, but not all and there was, even up to the late 1980s, a general mindset that computer software was something with a useful life measured in a small handful of years rather than decades.   Truly, hindsight is the most precise of sciences.
Yebbut yebbut in the late 1980s I was working with systems which had already been around long enough that assuming anything being written then would be replaced before 2000 made Bergholt Stuttley Johnson look sensible.

There were mainstream operating systems in the 1960s with date routines that could handle dates long after 2000. Even a date held in a 24-bit word (just 4 6-bit digits) could comfortably hold thousands of years, so you weren't going to save memory by, e.g., holding dates as YYDDD. That's more memory than the number of days since 1900. And the system I worked on that used YYDDD ran on an OS with 32-bit words.
"A woman on a bicycle has all the world before her where to choose; she can go where she will, no man hindering." The Type-Writer Girl, 1897

Afasoas

Re: The next millennium bug
« Reply #14 on: 14 April, 2021, 12:01:59 pm »
I know there are a few pfSense/FreeBSD users here so:

This is the CVE mentioned in the report. The reports description:

Quote
The vulnerability exists due to a boundary error when parsing option  119  data  in  DHCP  packets  in  dhclient(8).  A  remote  attacker on the local network can send specially crafted data to  the  DHCP  client,  trigger  heap-based  buffer  overflow  and  execute arbitrary code on the target system

I don't think it is a big deal; a potential remote code exploitation (RCE) vulnerability which you have to be on the local network to exploit.

frankly frankie

  • I kid you not
    • Fuchsiaphile
Re: The next millennium bug
« Reply #15 on: 14 April, 2021, 04:15:25 pm »
see also https://en.wikipedia.org/wiki/Year_2038_problem

Hmm.  Reading further on Wikipedia, I particularly like: (nb, my bold)

"Beginning 14 September 30,828, Windows will not accept dates beyond this day and on startup, Windows will complain about 'invalid system time'."
https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs
when you're dead you're done, so let the good times roll

Ben T

Re: The next millennium bug
« Reply #16 on: 14 April, 2021, 06:15:44 pm »
see also https://en.wikipedia.org/wiki/Year_2038_problem

Hmm.  Reading further on Wikipedia, I particularly like: (nb, my bold)

"Beginning 14 September 30,828, Windows will not accept dates beyond this day and on startup, Windows will complain about 'invalid system time'."
https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs

Optimistic  :)

Re: The next millennium bug
« Reply #17 on: 16 April, 2021, 06:20:30 pm »
The year 292,277,026,596 problem (about 2.9×1011 years in the future) will occur when the 64-bit Unix time overflows at UTC 15:30:08.


Hmm, I’m sure 64 bit classical chips and OS will still be going by then.

Mr Larrington

  • A bit ov a lyv wyr by slof standirds
  • Custard Wallah
    • Mr Larrington's Automatic Diary
Re: The next millennium bug
« Reply #18 on: 16 April, 2021, 06:30:15 pm »
Oddly enough, the Several of “What day of the week” calculators I've tried for 14 September 30828 all insist that a year can only have 4 digits.
External Transparent Wall Inspection Operative & Mayor of Mortagne-au-Perche
Satisfying the Bloodlust of the Masses in Peacetime

Re: The next millennium bug
« Reply #19 on: 16 April, 2021, 07:53:30 pm »
I predict there will be a small but annoying number of century bugs in 2100 where lazy programmers, knowing that the only century change in their lifetimes was a leap year due to the divisible by 400 rule so didn't bother with the usual century adjustment.

Maybe I should confess at this point. Mind that system, despite being brand new, was pretty well obsolete technology when I was writing the code.
"No matter how slow you go, you're still lapping everybody on the couch."

ian

Re: The next millennium bug
« Reply #20 on: 16 April, 2021, 09:04:15 pm »
It's all nonsense, we'll be using qubits, so every day will spontaneously be Wednesday and Friday or Tuesday and Saturday and dates will be a statistical phenomenon, once you book a meeting on 17th May, it will be 21st August plus/minus 42 days.

Re: The next millennium bug
« Reply #21 on: 21 April, 2021, 12:19:37 am »
I predict there will be a small but annoying number of century bugs in 2100 where lazy programmers, knowing that the only century change in their lifetimes was a leap year due to the divisible by 400 rule so didn't bother with the usual century adjustment.

Maybe I should confess at this point. Mind that system, despite being brand new, was pretty well obsolete technology when I was writing the code.
In late 1998 I fixed a bug in a program which had been introduced by someone who'd 'fixed' the original code, which had treated February 2000 the same as February 1996 . . . . .

He (I knew who it was) had written some code to stop it treating 2000 as a leap year. He knew about the 100 year rule but not the 400 year rule. Doh!

The operating system it ran on had a built in date function which could be called from programs (& it was a standard thing to do that) which handled leap years correctly & could handle any date from 1st January 1901 to 31st December 9999. It would have taken less typing to call that than write his little bit of code. Or he could have done nothing at all . . .

Sometimes, it isn't even laziness.
"A woman on a bicycle has all the world before her where to choose; she can go where she will, no man hindering." The Type-Writer Girl, 1897

Kim

  • Timelord
    • Fediverse
Re: The next millennium bug
« Reply #22 on: 21 April, 2021, 12:21:06 am »
The operating system it ran on had a built in date function which could be called from programs (& it was a standard thing to do that) which handled leap years correctly & could handle any date from 1st January 1901 to 31st December 9999. It would have taken less typing to call that than write his little bit of code. Or he could have done nothing at all . . .

Sometimes, it isn't even laziness.

I'm betting he went on to an impressive career implementing his own cryptography algorithms...

Re: The next millennium bug
« Reply #23 on: 21 April, 2021, 12:12:35 pm »
Made redundant a couple of years later. Found another job, but further from home & I suspect with worse pay & benefits.
"A woman on a bicycle has all the world before her where to choose; she can go where she will, no man hindering." The Type-Writer Girl, 1897

Re: The next millennium bug
« Reply #24 on: 21 April, 2021, 12:15:23 pm »
The operating system it ran on had a built in date function which could be called from programs (& it was a standard thing to do that) which handled leap years correctly & could handle any date from 1st January 1901 to 31st December 9999. It would have taken less typing to call that than write his little bit of code. Or he could have done nothing at all . . .

Sometimes, it isn't even laziness.

I'm betting he went on to an impressive career implementing his own cryptography algorithms...

That weren’t secure by any measure of the word 😂