Yet Another Cycling Forum
General Category => The Knowledge => Ctrl-Alt-Del => Topic started by: Asterix, the former Gaul. 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.
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
-
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.
-
see also https://en.wikipedia.org/wiki/Year_2038_problem
-
Remember NNTP? Designed for a time when only academics used the Internet. By 2000, it was wall-to-wall Viagra spam and porn.
-
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
-
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.
-
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 ....
-
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”.
-
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 (https://www.forescout.com/company/resources/namewreck-breaking-and-fixing-dns-implementations/)* 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)
-
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.
-
...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.
-
There's plenty of hardware that still works to a 2-digit year internally. I used one of these (https://datasheets.maximintegrated.com/en/ds/DS1307.pdf) 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...
-
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.
-
...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.
-
I know there are a few pfSense/FreeBSD users here so:
This (http://cve.circl.lu/cve/CVE-2020-7461) is the CVE mentioned in the report (https://www.forescout.com/company/resources/namewreck-breaking-and-fixing-dns-implementations/). The reports description:
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.
-
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 (https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs)
-
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 (https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs)
Optimistic :)
-
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.
-
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.
-
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.
-
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.
-
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.
-
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...
-
Made redundant a couple of years later. Found another job, but further from home & I suspect with worse pay & benefits.
-
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 😂
-
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.
Understanding other people’s code or APIs is hard work and it might have bugs you don’t know about it.
Writing your own code is easy and you know it works and it definitely won’t have bugs you don’t know about.
-
So - I should never call another program but always write my own. I should never use any operating system command, but write my own.
That's pretty much what you're saying in this case. That date function was about as reliable as code gets. The chance of it having a bug was essentially zero. Systems all over the UK & quite a few other countries would have been constantly failing if it was buggy.
And you've missed the really, really, important bit: the code he wrote was wrong. It did have a bug he didn't know about.
-
And you've missed the really, really, important bit: the code he wrote was wrong. It did have a bug he didn't know about.
I think you might have missed something too. :)
-
If a function you need is available from the OS / Framework you are targeting, I can think of no possible reason to re-invent the wheel and implement the function yourself.
I can't see that passing code review here.
I mean, seriously:
Are you going to ignore and re-write the .net framework, where that function is exposed, and target the win API directly Petzold-style yourself?
-
I think you might have missed something too. :)
I was of course adding evidence to Poe's Law.
If a function you need is available from the OS / Framework you are targeting, I can think of no possible reason to re-invent the wheel and implement the function yourself.
Plenty of reasons (in the general case, not necessarily for date functions):
- Your app works on multiple platforms and you already have an implementation and consistent behaviour is desirable.
- The function is known to be buggy or have unpredictable results.
- The function is not performant enough for your use case.
- The function requires and/or returns data in a different format to that you are using in your program, and converting the data back and forth is more work than just reimplementing the function.
- The function is only available as part of a larger framework that you don't want to create a dependency on.
- The function has some other undesirable side effects, like triggering a network call or disk access unnecessarily
- The spec requires the function to produce certain results. The results of the OS call look like they'll produce the right result, but can you be sure?
etc
9 times out of 10 a programmer reimplementing something is wrong, but not always.
-
I, for a while now, have insisted my developers write their code longhand. They get bonus points for illustrating the letters at the start of a routine and using a quill.
-
I, for a while now, have insisted my developers write their code longhand. They get bonus points for illustrating the letters at the start of a routine and using a quill.
This came up at university, where this sort of thing[1] was expected to happen in exams.
After much debate on the course newsgroup, the nerdiest socks-and-sandaliest of CS lecturers chipped in with the legendary advice: "Pointy end down."
[1] Not the quill part. Though there was a sufficiency of noisily rutting shitehawks on the sports hall roof that would have been first in line for donation of the required feathers.