Slashdot Mirror
Software Bug Behind Biggest Telephony Outage In US History (bleepingcomputer.com)
An anonymous reader writes: A software bug in a telecom provider's phone number blacklisting system caused the largest telephony outage in US history, according to a report released by the US Federal Communications Commission (FCC) at the start of the month. The telco is Level 3, now part of CenturyLink, and the outage took place on October 4, 2016.
According to the FCC's investigation, the outage began after a Level 3 employee entered phone numbers suspected of malicious activity in the company's network management software. The employee wanted to block incoming phone calls from these numbers and had entered each number in fields provided by the software's GUI. The problem arose when the Level 3 technician left a field empty, without entering a number. Unbeknownst to the employee, the buggy software didn't ignore the empty field, like most software does, but instead viewed the empty space as a "wildcard" character. As soon as the technician submitted his input, Level 3's network began blocking all incoming and outgoing telephone calls — over 111 million in total.
According to the FCC's investigation, the outage began after a Level 3 employee entered phone numbers suspected of malicious activity in the company's network management software. The employee wanted to block incoming phone calls from these numbers and had entered each number in fields provided by the software's GUI. The problem arose when the Level 3 technician left a field empty, without entering a number. Unbeknownst to the employee, the buggy software didn't ignore the empty field, like most software does, but instead viewed the empty space as a "wildcard" character. As soon as the technician submitted his input, Level 3's network began blocking all incoming and outgoing telephone calls — over 111 million in total.
Check the spec - perhaps it was by design or not called out to ignore empty entries?
A null/blank input taken as a wildcard is certainly not a feature.
Even labeling that as a mere bug is putting it mildly. More like gargantuan fuck-up.
But "not called out"? I haven't yet met either a programmer or a tester who wouldn't have at least tried out the 'null entry' scenario and flagged it as a problem..
Have you never worked with offshore developers or testers? If it isn't itemized, they won't think to do it.
It's a bug no matter what the spec says. Anything where you can shut down phone service for 110 million subscribers simply by hitting enter (without filling a field) isn't just a bug, it's a twelve-storey bug with a magnificent entrance hall, carpeting throughout, 24- hour portage, and an enormous sign on the roof, saying 'This Is a Massive Bug'.
Why are you blaming the programmer? The feature must have been designed; did the design call for empty being interpreted as a wildcard? It must have been tested; something as important as this has a testing budget associated with it, surely? Some company executive must have signed off on it. There will have been a formal handover from development to production. Did the programmer have the power to correct the design? Did he have the power to enforce testing? Did he have the power to stop deployment? Or was he just some underpaid wage slave who was paid by the hour to stamp out code as quickly as possible? Someone told by his manager he is just a warm body who can be replaced at a moment's notice? What was written in the user manual? Was there a procedure for blocking a number, and if so, was it followed? Was training given on how to use the software correctly? How can it be that the company has no liability, but somehow, someone who formed only a tiny part of the chain (and certainly not the best-paid part of it) should, according to you, now face prison time?
Why are you blaming the programmer? The feature must have been designed; did the design call for empty being interpreted as a wildcard?
Don't assume it was designed. It's amazing how much gets "designed" at implementation if something isn't expressly stated in the specification. The only thing we know is that we don't know who to blame.
That said the GP's assertion that someone should face prison time is completely stupid. Even by American "jail everyone for everything" standards.
Ha ha. No, this is not just a bug. The fuckup goes much deeper than that. "An empty field acts as a wildcard" is the least of your problems. It may or may not be expected behaviour for a GUI. "Not finding it during testing" is par for the course for GUIs for this sort of thing. You're not supposed to give wrong input, even accidentally!
The real problem is thinking a GUI is appropriate to feed lists of boring numbers through. By hand, no less. It's way too easy to accidentally leave a field empty or --if it's a micro-managing form like windows IP address entry type things-- copy part of a numer in the wrong line, shift it a sub-field, or something else similarly silly.
What we have here is a mismatch between user interface and purpose, cooked up without thinking. This is the same mode that makes users stupid, but now it was the designer who wasn't thinking. The focus was on "getting some input fields done", not on "how will this be used and what might the consequences be?" The deeper problem is TFIing such lists. GUIs are entirely stupid for this.
Compare "here, have a GUI" with this sequence: Check the list then feed it to the system as a textfile. It gets queued. Then check the list as it appears in the system against your original list. The system probably should make explicit just what it will do with each entry, like "block one number" or "block a range of numers". Possibly have someone else look over the proposed actions. THEN activate it.
So the problem is that the workflow is entirely too stupid to live. And it was shaped into that form by a GUI.