Cash registers in Poland fail due to new year bug (PL) | Hacker News Reader

Cash registers in Poland fail due to new year bug (PL)

translate.google.pl

54 pointsDonmario23 comments

I wouldn't be surprised if something alone the lines of `split("20")` or `replace("20", ““)` was the culprit somewhere (to turn it into a 2-digit year). I've seen the most absurd date handling code...

Yeah, and I could imagine some developer fixing a Y2K big in the late 90s thinking, "Hmm, this may cause a problem in 2020, good thing I'll be long gone by then."

And that proves that the Y2K problem was real: even in 2020 some companies that had only these printers apparently simply can't do their business until the repair of the printers is made.

On the topic of dates broken around New Year's, there is this perennial favorite:

http://dangoldin.com/2019/01/06/javas-simpledateformat-yyyy-...

So far I've heard of the following fail due to some sort of 2020 bug:

Parking meters: https://www.nytimes.com/2020/01/03/nyregion/nyc-parking-mete...

Video games: https://www.dsogaming.com/news/star-wars-jedi-fallen-order-w...

Now cash registers.

Anything else?

Maybe we'll hear about more on Monday. I wonder if there will be a central site with stories like these

Trains in Hamburg: https://www.ndr.de/nachrichten/hamburg/Software-Fehler-legt-...

article mentions another game, WWE2K20

Similar issue in NYC with parking meters: https://www.nytimes.com/2020/01/03/nyregion/nyc-parking-mete...

The official explanation from the vendor is that this was an "anti-fraud security setting".

Can anyone familiar with CC processing provide insight on whether that's a reasonable explanation?

Regardless, a problem that requires a "software fix" from the vendor and manual visitations to each individual machine doesn't sound like a mere "setting"

I assume the meters are network-connected because they take credit cards, but they can't be remotely updated? Seems like an obvious omission.

Or a deliberate security measure. Embedded devices often use Harvard architecture, with separate memory for code and data, so not allowing remote updates makes remote code execution impossible.

Sure, but there are at least two other options that are essentially as secure, assuming the “remote attack” threat model:

1. Allow customers to download updates and flash over USB.

2. Boot device into a limited mode that allows signed updates. Certificate should be stored in secure memory.

I don't deal with PCI personally, so $0.02, but we're talking retail or unattended devices here.

I.e. low wage, minimal training, not technically proficient users with unsupervised physical access to the machine

A machine through which a large amount of cash (virtual or otherwise) flows.

The criteria of (a) being updatable by a semi-technical customer & (b) being secure against technically malicious or socially engineered ignorance attacks seem challenging to simultaneously satisfy.

allowing easy update over usb is its own thread model, lessened with only allowing signed updates. Like almost everything, it's likely these parking meters have terrible security design. the parking meter I use commonly is incredibly slow, every button push takes 1/2 a second to update the small lcd ui, I really wonder what it can be doing to be so slow. It's probably using multiple levels of interpolation to run a js program or something.

>Can anyone familiar with CC processing provide insight on whether that's a reasonable explanation?

It is not.

It's BS. They've already been handling cards with expiration dates beyond 2020. The broken part can only be their internal date handling.

"anti-fraud security setting" might be expired cert

Apparently it's a "bug in the software of popular Delio cash printers from Novitus". The product page of the printer mentioned is:

https://www.novitus.pl/en/produkty/systemy-fiskalne/delio-pr...

It can be seen that the printer already existed in 2009 and then got something ("Polish Promotional Emblem" according to Google Translate) https://www.novitus.pl/sites/default/files/certyfikaty_tp_55...

Even if it's only one model, if the companies have only that one model of printers they won't be able to sell anything until the printers are serviced.

Effectively, having such a bug in software, even in multiple units of the same model translates to a single point of failure for the company using it.

I would love to hear what bizarre encoding they used that resulted in 2020 being an issue.

(I'm assuming these machines aren't all < year old and just break on any new year)

2020 was a common pivot year used in the "windowing" workaround to the Y2K bug. 2-digit years < 20 are defined as 20XX, while years >= 20 are defined as 19XX.

https://en.wikipedia.org/wiki/Date_windowing

Thanks for sharing.

Y2K used to be just an interesting story from the past. Never guessed that it would still be biting people 20 years later. Ouch...

I would assume that they were made Y2K compliant by pushing the cutoff date back to 2020, so date math are operating on 1920 dates by accident.

Reply on news.ycombinator.com