Slashdot Mirror
2010 Bug Plagues Germany
krou writes "According the Guardian, some 30 million chip and pin cards in Germany have been affected by a programming failure, which saw the microchips in cards unable to recognize the year change. The bug has left millions of credit and debit card users unable to withdraw money or make purchases, and has stranded many on holiday. French card manufacturer Gemalto accepted responsibility for the fault, 'which it is estimated will cost €300m (£270m) to rectify.' They claim cards in other countries made by Gemalto are unaffected."
OOk Ook eek eek oo-oo Ah AA!
from TOA
I wonder how does it compare to the losses from Y2K bug... I know it is hard to compare, because there was an unspecified money loss as part of unnecessary checks, difference in scale, anticipation and efforts to fix before manifestation.
I guess it hits you when you are least expecting.
I do not believe in karma. "Funny"=-6. Do good and forbid evil. Yours, Oft-Offtopic Flamebaiting Troll.
Who would have thought 2010 was going to be a big deal. We just had a 2010 programming problem at work. Everything worked great in December then in January our software simulation stopped sending the correct time to our hardware. Turns out the simulation handles 2010 incorrectly. We now have to set our PC clocks to 2009 until the team gets a fix out. I bet we see more of this.
"Although some cash machines were quickly reconfigured to override the 2010 problem, many bank customers were forced to queue to withdraw cash over the counter. Germany's economics minister, Rainer Brüderle, urged banks to 'ensure that credit and bank cards function without problem as soon as possible, or to replace them immediately'." My gosh standing in line to get money is so 1980
It only took 65 years, but they finally got their revenge for those invasions. Subtle, the french are, very subtle and patient. Like mice.
Those who have telepathy have no need to RTFA.
Come on, editors.
Today's weirdness is tomorrow's reason why. -- Hunter S. Thompson
Again, it's surprising that such an obvious software bug makes it into the real world. You really can never trust untested software at all. What disturbs me most are the proposed "solutions": the companies issuing the cards try to avoid the exchange of the cards by all means due to the costs involved. However, that comes at the cost of sacrificing the security gained by the introduction of the now ill-functioning chip. What has been mentioned as well was updating the software on the card at the banking terminal - I'm surprised that this is possible at all. Essentially, that opens another huge security gap (which might have been there for a long time but went unnoticed so far).
France makes German credit cards. The cards blow up.
Germany makes French cars. I wonder what will happen?
DUN DUN DUUHH......
And by that I mean RAT-A-TAT-A-TAT
Technology: 2016 Bug Hits Text Messages, Payment Processing
Experts (or excellence, YMMV) at work.
CC.
TaijiQuan (Huang, 5 loosenings)
Moreover, it makes you wonder who much of a problem Y2K may have actually been if we hadn't of looked for all the problems and fixed them.
Chances are things like this would have only been the beginning if Y2K hadn't have been anticipated and planned for, even if we over-reacted. Maybe we should be giving some people more credit than we do...
Even worse, some banks charge you a fee if you wait in line for a teller rather than use an ATM for withdraws. Hopefully they waived the fee in this case.
. . . use the magnetic strip.
I just saw a clip on a German news channel showing a chick covering the chip on her card with a piece of clear adhesive tape. Apparently this forces a dual card reader to use the strip. But I wasn't listening, so I'm working, you know.
Schroedinger's Brexit: The UK is both in and out of the EU at the same time!
Reminds me of a story I mention every so often. When I was an undergrad, I along with a few other enterprising students discovered that our university ID cards stored our social security numbers in the clear on the magnetic stripe. We eventually brought this to the attention of the school, who rushed to find a solution. They needed a unique identifier that was also not important information. They quickly settled on using our "university ID numbers" - arbitrary numbers whose value had no importance to the individual, and they reissued cards to the entire university.
A few weeks after they finished reissuing cards, one of us discovered that the "university ID number" was a primary key in the school's LDAP database. By using a directory browser, you could look up any student, staff, or faculty member by name, and obtain their university ID number. Since this was the number on their ID card, and their ID card controlled access to buildings, labs, etc., it was trivial to obtain access privileges to pretty much anywhere on campus. Want to make it look like the president of the university broke into the nuclear reactor? Look him up, write his ID number to a magnetic stripe card (we had built the hardware to do this, as well as to "fake" cards, which allowed us to simple type in numbers and generate signals, without actually making a card), and have at it.
Again, it was brought to the attention of the university. After a failed attempt to begin disciplinary action against one of us, they recalled everyone's cards and wrote new, presumably pseudo-random identifiers to them that were not publicly accessible.
Moral of the story? In your rush to fix one problem, make sure you don't create an even bigger one.
"Anyone who [rips a CD] is probably engaging in copyright infringement." - David O. Carson
This is just an "Up yours" to everyone who, after Y2K, decided "But now we won't have to worry about 4 digit years for another hundred years, so let's just use two digit years. What could be the harm?"
-- 'The' Lord and Master Bitman On High, Master Of All
Hah, hah, hah!
Their they're doing there hair.
Which countries were made by Gemalto?
Gemalto accepted responsibility for the fault, 'which it is estimated will cost €300m (£270m) to rectify.'
I hope that money isn't in a German bank...
I mean, who in the year 2000 could have predicted that a one day the important digit would roll over from 0, 1, 2, ... 9, and back to 0 again? Especially when you are so busy eating cheese and contemplating surrender.
The problem lies in the advanced security mechanisms (EMV chip). The fix (currently) is to disable advanced security features (either by disabling the chip by taping it or in POS device). I can already hear the Skimmers jubilating. They will profit greatly...
Another problem will be that a lot of people will become wary of security features.
The response for y2k was not planned for, and it was not an over reaction.
Y2k issues were known in the 80's. Had IT been allowed to respond in a timely manner, it would have cost much less, been checked more thoroughly and finished earlier. Instead they waited until the last possible moment and poured much more money into it, hiring as many developers as possible to put in a rushed hackjob and then firing them when the hack worked instead of retaining them to vet, verify and implement permanent solutions where needed. This issue is a result of the failure to react apropriately to y2k. The rushed temporary get-it-done-yesterday hacks are starting to fail.
I hear people going on about how using the magnet strip is horrible and a security problem. But I don't get it.
People say, the bad guys can easily copy the magnet strip, but not the chip, so taping over the chip is insecure, since it forces use of the insecure magnet strip. Now, what's to stop the bad guys from just copying the magnet strip anyway? ATMs and other card readers seem to work just fine with chipless cards, so having no secure chip on the card should be no problem for them.
Could anybody explain?
I think you mean "if we hadn't have looked", or more simply, "if we hadn't looked". The "of" you used sounds like the contraction of "have" ("'ve").
I don't know the exact nature of the bug, but I know that in the current economic crisis, managers first and foremost look for minimizing costs. This has laid to reductions in personnel, and ultimately in testing problems: not enough people to test the software and the people that are assigned the testing job are not experienced enough to do it properly.
I experienced this personally: I worked all throughout 2009 on a project that should have been ended by the end of 2008, because the contractor has laid off several people and they were unable to fully come out with a good specification and testing of their system. Most of the errors became apparent through the testing done by us, the subcontractor. The contractor was French, by the way.
2038 is only the limit on 32bit platforms. On a 64bit platform time_t is 64bits, which will last "forever". We are already significantly on the way to switching to 64bit-only CPU operation, and I'm going to bet that by 2038 we'll switch completely, if only to avoid the end of time. Heck, if you could only have a working 64bit flash plugin on Linux, all Linux users would go 64bit already.
I was running a Y2K lab at my company from 1999 to 2000, and we found a TON of serious problems. Nearly all of our internal stuff had major issues, as well as email, phone systems, backup systems, and several operating systems.
The tests I ran went from 1998->2012 in one year increments (with full tests by all teams at each year step) and most of those problems were nailed down.
I'm guessing not all shops tested much further out than 2001 or 2002 - probably due to poor planning and lack of funds. As it was we had to cut ours back to 2012 because of budget constraints, so I can only imagine other shops did likewise.
An operating system should be like a light switch... simple, effective, easy to use, and designed for everyone.
I suspect it's also aggravated by a bunch of sleazy contractors taking advantage of desperate clients who know that they're about to get bit in the behind, and deciding to cheap out and do a half-assed job in the first place.
Seriously, after what caused Y2K, only a complete moron or a crook would add 2000 to a single digit in a barcode.
Wow, somebody stood up, said it was their fault, and took responsibility - what a rare moment in the business world. I offer my gratitude and wish them well on what will undoubtedly be a perilous journey.
My card is working fine, but my parents had this problem today - both my mother's and my father's card did not work at the ATM with (for them) cryptic error messages, so they had to get money over the counter. What's most annoying about this is that when they got home, they checked their online banking website to see if there were any news there and saw that even though my mom's card got rejected at the ATM, it still showed the 100 euros she wanted to get at the ATM as having been withdrawn, even though she did not receive any cash.
How convenient then that the ATMs were down...
How does code get written to misinterpret a date? Why does code do anything to the date except to display the date or to poll data based on the date and the some how read a "10" as... "OMG MOTHERFUCKIN SNAKES ON A MOTHERFUCKIN PLANE"? Srsly, any examples out there? I am sure this isnt some big conspiracy, but I just cant imagine code that would shut down entire systems based on a date.
The rushed temporary get-it-done-yesterday hacks are starting to fail.
Wonderful rant, but pray tell, how does this issue link to y2k hacks when it's an update to previous cards limited to German market? Have you inside knowledge from Gemalto of what motivated the aforementioned update and the reason they used such a way to represent the year in that particular geographic location?
http://dilbert.com/2010-12-13
You forget TVM. Money spent fifteen years later is waaaaaaay cheaper than money spent today.
Plus, by waiting until the last minute, no labor was wasted in pre-fixing systems that would already be obsoleted by 1999. Guess what, lots of systems that were in use in 1980 were no longer in use in 1999 and so early Y2K fixes would've been a waste of time.
Oh pipe down, it's nothing of the sort; these cards are not that old. They just skimped a bit on QA.
FATMOUSE + YOU = FATMOUSE
Starting on 1/1/2010 Symantec Endpoint Protection Manager v11, the software that pulls down updates from Symantec and pushes them out to all the client systems, started repeatedly downloading the same virus def over and over and stashing them in randomly named temp folders on the C drive at the rate of about 1GB/hour. Party. Lots of folks on the Symantec support forms are experiencing the issue. Purging the temp folders and upgrading to the recently released v11 RU5 fixes the problem, but those without current support contracts to get the updates would be kinda screwed...
-c
"it makes you wonder who much of a problem Y2K may have actually been if we hadn't of looked for all the problems and fixed them."
Maybe if you assume that the economic losses due to such a bug are insignificant compared to the manufacturer's cost of correcting the bug.
The estimated cost relates only to the "no-workaround" option, if all the cards were to be replaced.
By the way : Symantec Endpoint Protection is affected by a 2010 bug too. SNAC users are not happy.
http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2010010308571348
I am not Remy Mouton, unfortunately: http://remy.mouton.free.fr/art/
But somehow, all this auditing, code reviewing and certification doesn't manage to uncover a simple date encoding bug.
It's actually worse: if during routine maintenance, a employee, partner or customer stumbled across the bug, he would be dismissed as mistaken, because such bugs are just not possible, or else the very strident auditing would have caught it.
How do you know it is obvious?
It could have been buried deep in the innards of code decades old.
IANAL but write like a drunk one.
Hi,
As an unrepentant OpenVMS fan, I have had to do some system programming dealing with
date/time issues. The native timekeeping uses 64 bit integers and midnight preceding
November 17, 1858 as the epoch. http://en.wikipedia.org/wiki/OpenVMS#Timekeeping
Although it takes a bit of trouble converting these dates to human readable form,
it rules out any rollover errors until July, 31 31086 02:48:05.47.
Perhaps we should standardize on this?
Bob Dobbs
Just got back from a trip in Asia (Vietnam and stopover in Thailand) and had problems using my creditcard. Wondering if it was related? (Only brought one creditcard so had problems at some stores and the airport in Bankok)
Je ne parle pas francais.
You know, companies make the conscious decision to not have permanent staff to oversee contractors. They get what they pay for. That doesn't excuse contractors, but there is this thing called due diligence.
Also, I'd say there is a 90% chance that the contractor spelled out exactly what they were doing and its implications, and somebody in the company signed off. Maybe they didn't read it all, but it is just as likely that they were given the choice of $600k to do it right, and $500k to do it cheap, and they picked the latter. Saving $100k probably got the decision-makers bigger bonuses, and by now they're all in different jobs or retired anyway.
The problem is that companies are WAY too short-sighted. As a result stuff like this never shocks me.
Finally time to release C++0x?
What's that line Wally says to Dilbert when PHB announces a cash reward for finding and fixing bugs in their own projects? "I'm going to code myself a new minivan." Or something like that.
The longer you put something off, the more likely it will become someone else's problem.
I would suggest to just switch to a one-byte storage format, this way we all can live up to 255 years, before insurance companies send us stupid letters intended for families with young children.
But then again, if anyone ever makes it to 127, she might turn -128 the next year. If only there were a solution to this problem..
Don't lose information.
If you have information (a four digit year) then don't throw it away (store as a two digit, or one digit [hex] year). Don't ask the user for a two digit year since it doesn't have enough information to compose a four-digit year without some (risky) guessing.
Every time I see a two digit year specified for software I want to scream, "DIDN"T YOU LEARN *ANYTHING* FROM Y2K!".
Fortunately there is a solution. It is the ISO 8601 specification for representing dates in text format. It simply says use something like:
2010-01-08
You don't have to use this in the user interface, just use it everywhere else dates are represented as strings. This format also sorts properly using regular alphabetic string sorting and is internationalized (unlike dd-mm-yy or the crufty US system of mm-dd-yy). Hope this helps some of you developers, architects and analysts out there. Two digit dates are the plague and anyone using them should be stripped of their license to practice in IT (what? there's no license to practice IT? no wonder so many bad design decisions are made!). Use ISO 8601 for date strings and most of your date problems will disappear.
the world is going to end anyways, so there's no sense programming past that.
I guess it hits you when you are least expecting.
Shouldn't that be, "It hits you when you are most expecting it"?
I'd reckon the unnecessary checks and public panic to have been much more expensive than EUR 300m.
Um yeah...
I was running a Y2K lab at my company from 1999 to 2000, and we found a TON of serious problems...
My wife was in charge of a Pick-based hospital IS back then. She put in a huge number of extra-long days getting the dates expanded so the hospital wouldn't have to "go manual" on 1-Jan-2000. She made the deadline, but it nearly killed her. Hospital administrators then gave her a sledge for making such a big deal over it, because clearly it was all a farce - nothing happened as a result of the date changing to year 2000.
The loss to her was any further interest in an IT career. She's now teaching immersive medieval history to a number of schools, where her work is at least appreciated by her clients.
Do not mock my vision of impractical footwear
So it's exactly like the game industry?
+0 Meh
Yeah - this was a real killer for me too. The company I was at was extremely grateful (thank goodness) but I keep seeing all these idiots who were not involved (either because they were still in school 10 years ago, or because they just don't get it) and it really does get me.
I think Y2K, the massive outsourcing wave that followed, and the complete destruction of IT as a viable career has really not yet caught up with us.
It will. The 2010 thing is just part of it. When the rest of the really skilled and dedicated people (like your wife, and many many others) have left, the void will be huge. It also won't be noticed for quite a while, because a side effect of a well designed system is that it can stand for quite a long time.
When it falls, however...
"Much that once was is lost, for none now live who remember it."
An operating system should be like a light switch... simple, effective, easy to use, and designed for everyone.
My bank called me 4 days ago and told me my card was 'compromised' and Mastercard had contacted Bankwest (Australia) to inform them of a list of cards with 'security issues'. It never occured to me this might be the same issue as the 2010 / 2016 one.
Traditionally when your bank calls you and offers a card swap over, it's a pretty quick process, however it's been 4 days and nothing so I'm thinking it's quite possible they got stung too.
Looks like it according to this too.
http://www.brisbanetimes.com.au/business/welcome-to-2016-eftpos-glitch-spreads-20100105-lqus.html?comments=19
Do I "KNOW"? No I do not, no personal knowledge in this precise case. It is however practically the same problem. Someone screwed up the date format. It has been happening all over the world in a very similar way. I have heard some other cases where the issue has been tracked back to y2k hacked fixes.
Yes somehow loads of countries who didn't spend big on y2k, like Italy, managed just fine.
Plus, by waiting until the last minute, no labor was wasted in pre-fixing systems that would already be obsoleted by 1999.
Yeah, but recall that in the Y2K bugs were mostly found in corporate COBOL programs, and COBOL code doesn't get retired. It just accumulates in the musty corners of old runtime libraries. There was a lot of COBOL code from the 1960s that was patched for Y2K
To see how bad the COBOL retention syndrome is, consider that IBM has had to supply emulators of older processors, so that customer companies could continue to run binaries for which the COBOL source has been lost. Yes, it really is that bad in the corporate DP/MIS/IT world. Of course, the binary-only programs generally couldn't be fixed for Y2K, and had to be rewritten. But they were rewritten by people adapted to the same corporate culture, and made the same mistakes in date/time handling that they've always made.
I remember reading a story by a fellow who got curious about the date problems in COBOL code, and started collecting examples of COBOL date-manipulating code. He said that when his count of the number of different date formats passed 180, he decided that he understood the problem quite well. This is still going on, as can be seen by looking at the date-handling code in newer software, and we still have the same problems.
Just last week, I gave a demo of some web code that I've been developing for a (mercifully) unnamed client. During the demo, some of the screens exposed the fact that the code internally saves all dates in ISO standard form, for the UT "time zone". I assured them that I could add the obvious translations to local time fairly soon, but this turned out not good enough. They were insistent that they didn't want the code "working on European time", and wanted the internal times all in local time. This despite the fact that they (and their visitors) are scattered across about 10 time zones. Just displaying all times in the local zone isn't acceptable; they object to Universal Time internally on general principles. I've seen this repeatedly on a lot of projects. It tells you a lot about why our software continues to have time-handling problems, whenever any particular ad-hoc time representation reaches a value ending with some number of zeroes (in base two or ten).
It was really funny a few days ago, when we read about spamassassin's bug triggered by the first day of the year 2010. I predict that we'll get reports like this in every year ending with a zero, for as long as any of us is alive. ;-)
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Y2k issues were known in the 80's.
Actually, they were known in 1970. During the first months of that year, a lot of banking software went insane. This is because banks had a lot of 30-year mortgages, and assorted other things of the same duration. For some reason, the banking system has long settled on 30 years as a reasonable "long-term" period for a lot of their business.
So in January of 1970, there were many reports of bank computers treating their oldest mortgages as having an expiration date in 1900, meaning that the loan had been paid off 70 years earlier, and the computers would no longer accept payments on such loans. In some cases, the computers started sending harrassing letters about the loans that weren't yet paid off, and overdue by 70 years. Depending on just how the date code worked (and failed), some very bizarre misbehaviors resulted.
Date-based bugs don't always wait for the critical date to manifest themselves. Any time the software has to deal with future dates, the bugs can pop up well before the critical time. They're just more visible when "now" passes a critical time, because "now" is on the other side of the divide from most of the previous dates stored in the databases.
(So far, I haven't read of any bugs that screwed things up more than 30 years before a critical date. But it wouldn't surprise me.)
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Why 10?
Surely the program doesn't have to represent 1910 and earlier? Besides which, any program that deals with 1910 is very likely to deal with 18xx and therefore wouldn't have Y2K problems in the first place (as the original programmer would have had to use 4* digit date codes). And if the cycle point could have been put further in the future, then it was extremely foolish of the Y2K compliance guy to put the cycle point so close in the future, where they might get their not-yet-dead butts sued (not that foolishness isn't a huge part of this decade-long debacle).
Besides, is that even technically a 2010-specific bug (this bug spate seems to be related to BCD->hex transliteration)? I mean, the Y2K compliance programmer could have picked 13 or 42 or 8 or 35 as the cycle point - and it's just a coincidence that they picked 10 (probably because it's a round number).
* Technically, they could have gotten away with using 3 digit codes, which WOULD have meant Y2K problems - but even this "fucking retarded" hack would have still not kicked up problems until ~900 years in the future (and I might have to kill myself if I thought for a second that such crap code could be in use ~900 years from now).
PS. If your solution was something APART FROM "push the cycle point forward" (or worse, futz with the clock - thereby adding a second layer of kludge), I'd be thrilled to hear it (assuming it doesn't violate an NDA).
The date jumped from 09 to 16 when the digits went from 09 tp 10. So what programmer in his right mind interprets any part of a date in HEX? Y2K was caused by programmers seeking to save space. This bug was caused by a programmer interpreting the last two digits as HEX! This was just a bonehead mistake not a space saving measure. So I really do not understand all the comparisons to Y2K. Just because they were errors in date fields does not make them the same at all.
I have an account with a German bank.
Today - a working week after the issue became apparent - there's still nothing on their website, their call center has no idea what to do and even more senior staff can't tell me if my cards are affected.
My experience here http://youmustbefromaway.blogspot.com/2010/01/y201k.html
I am sure, I just wasn't around to know about them in the 70s.
"By the way : Symantec Endpoint Protection is affected by a 2010 bug too"
Oh, the irony.
I do not believe in karma. "Funny"=-6. Do good and forbid evil. Yours, Oft-Offtopic Flamebaiting Troll.
That should be "viditur", not "vidutar"; Latin verbs don't end in -ar, but (deponent) ones do end in -ur. And, as you might guess from the "vidi" prefix, "appears" would be a more literal translation than "sounds".