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.

106 comments

  1. Bug or feature? by LynnwoodRooster · · Score: 0

    Check the spec - perhaps it was by design or not called out to ignore empty entries?

    --
    Browsing at +1 - no ACs, I ignore their posts. So refreshing!
    1. Re:Bug or feature? by geekmux · · Score: 5, Insightful

      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.

    2. Re: Bug or feature? by Anonymous Coward · · Score: 0

      No. I've seen plenty of software where an empty field is used similar to a wildcard. Yes, it's shitty UI design.

    3. Re:Bug or feature? by Anonymous Coward · · Score: 1

      No, it's just a bug.

      Not finding it during testing is the gargantuan fuck-up.

    4. Re:Bug or feature? by jenningsthecat · · Score: 2

      Check the spec - perhaps it was by design or not called out to ignore empty entries?

      The "by design" part is slightly plausible. 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. Heck, one of the most basic tests is to check what happens in the case of empty fields. This smacks more of somebody higher up ignoring test results and/or good advice.

      --
      'The Economy' is a giant Ponzi scheme whose most pitiable suckers are the youngest among us and the yet-unborn.
    5. Re:Bug or feature? by Anonymous Coward · · Score: 0

      If the null entry check was before the whitespace trim then it wouldn't have caught the issue. A dumb mistake, but how often have you heard of smart bugs?

    6. Re:Bug or feature? by guruevi · · Score: 1

      It could be either, just depends on what the original spec said. I would find it useful to be able to cover an entire set of numbers simply by leaving them blank, very similar to eg. IP addresses. Even in some configuration files, you can type in 10/8 and it will recognize it as being "10.0.0.0/8".

      --
      Custom electronics and digital signage for your business: www.evcircuits.com
    7. Re:Bug or feature? by Anonymous Coward · · Score: 0

      I suppose the idea would be you could block an entire block of numbers for a region in case a telemarketer bought them up.

      Like 1-900-762-

      The last four would be blank for any number. Except this would probably be a number for India or somewhere else.

      It would make more sense to use use a star symbol, but that is used on phone pads, so maybe the developers were unsure of what to do?

      Percent sign could have been used as a an alternative.

    8. Re:Bug or feature? by magarity · · Score: 4, Insightful

      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.

    9. Re:Bug or feature? by Anonymous Coward · · Score: 0

      Indochimps are great for jobs requiring nothing but rote memorization but suck terribly at creative thinking. It’s why outsourced code usually requires lots of rewrites because of the low quality.

    10. Re:Bug or feature? by Anonymous Coward · · Score: 0

      "...If it isn't itemized, they won't think to do it..."

      I have. Critical thinking involves challenging "authority". Many places that could land you in prison or worse.

      Programming languages will not think for you, that is left up to the programmer.
      Software specs should beside what you want it to do, also include what should not happen.
      Input data fields should have limits.
      How many examples have YOU seen of address entry asking for both State, City and ZIP when ZIP covers all three?
      How about adding the wrong zip and city the program is now aware of what the city should be and throws a fit?
      How about this always hiding your password, with no way to unhide it, like there's always a camera or a snooper behind you?
      With 1.5 billion login/pass available in plaintext on the darkweb, what good are complicated passwords anyway? Passwords are junk, a two factor with an RSA dongle or similar should be obligatory.
      Sorry for digressing.

    11. Re: Bug or feature? by arth1 · · Score: 2

      It is often useful to be able to enter regular expressions for filters. And an empty regexp without anchoring matches everything. That's a feature, not a bug. But it is only okay to design it that way if you can safely presume that anyone who will ever add a filter understands regular expressions, or will look it up before attempting to add a filter.

      Slightly safer (but only slightly) is to always add ^$ anchors, so empty fields only match empty entries.
      But safest is to presume that users don't grok regular expressions[*], and can only handle a case insensitive subset of DOS wildcards, without the special meaning of ? at the end.

      [*]: The most common error I see is with IP address filters, where someone will enter a bare IP address in a regexp field, and then wonder why the 1.2.3.4 filter blocks 71.223.4.50

    12. Re:Bug or feature? by Anonymous Coward · · Score: 0

      Even a wild card character is ambiguous in this way : does "foo*" include "foo"? It does not in DOS/Windows command line for instance, but if "*" also includes a string of characters of zero length, then it does.

    13. Re:Bug or feature? by rtb61 · · Score: 3, Interesting

      Not even close. Under law, a professional is a professional and that ties to responsibility for actions. That design was professionally criminally negligent and should be treated as such, with the penalty to reflect the harm causes and that means possible custodial sentence along with a massive fine. Let's not get freaky on the custodial sentence though, probably sufficient to let them 'cool their jets' with no more than a 90 day sentence if no one died but at least 30 days, sort of put the wind up them, focus their attention, remind them there are real penalties for being a crap professional, being in a role you should not be in. If anyone dies though, manslaughter charges.

      Find those individually responsible fine them, let them feel the weight of a custodial sentence, 30 days and fine the company much more. Custodial sentences should be the norm for criminal negligence as a professional, start licensing coders because of the harm they can cause. Differing grades, low grade licences for low risk work, high grade licences for high risk work. If you do not force them to do a good job, they will continue to do a shitty job, with a meh, someone else's problem for the shitty work the coder has done.

      --
      Chaos - everything, everywhere, everywhen
    14. Re:Bug or feature? by Anonymous Coward · · Score: 0

      I used to live in a "ZIP" code that served many little villages around the bigger one.
      Now it's the other way around, several "ZIPs" for one large-ish town/city.
      I also live in a country that doesn't have "States", the republic is explicitly stated as indivisible in the constitution. Yet I remember some internet forms that allowed me to live in my (non US) country but still seemed to require me to live in a US State, and pestered me with [red ink]* This field is required[/redink].

    15. Re:Bug or feature? by Darinbob · · Score: 1

      No, if the spec said it was supposed to be a wildcard, then someone should have strongly questioned this. Ie, a bug in the spec. A dev saying "I just follow orders" isn't a good excuse. That's like saying you're just a programmer and thinking isn't a part of the job.

    16. Re: Bug or feature? by Anonymous Coward · · Score: 0

      Go read up on The Principal of Least Surprise.

      What is more surprising? That an empty row entry should be ignored, or should act as a global wildcard and block a hundred million phone calls?

    17. Re:Bug or feature? by arglebargle_xiv · · Score: 4, Insightful

      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'.

    18. Re:Bug or feature? by johannesg · · Score: 4, Insightful

      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?

    19. Re:Bug or feature? by Anonymous Coward · · Score: 0

      start licensing coders because of the harm they can cause

      Terrible idea. Many other countries will be happy to welcome unlicensed coders. What then? Will you make unlicensed code illegal? Good luck enforcing that. Perhaps the most effective suggestion for destroying the American economy short of aerial bombing. Be more careful about what you wish for.

    20. Re:Bug or feature? by Anonymous Coward · · Score: 0

      Licensing individuals does not make them less incompetent at their profession -- it is simply a heuristic evaluation of a qualification by a third party.
      Criminalizing mistakes does not eliminate mistakes. It only increases the profits of lawyers, and maybe insurers if they manage to make a market for selling some insurance.

      My advice is to hate the sin not the sinner -- whatever You do You must understand that mistakes happen, and dealing with them is a part of life. Good and honest professionals do not produce perfect systems. There are no perfect systems. Furthermore, as the system gets larger, the total errors that happen must also increase, and the system must be built to accommodate errors of its parts or stop working -- and it is unavoidable, regardless of how a perfect Your coders can be (and it is still true for other systems as well, such as transport, management or engineering).

    21. Re:Bug or feature? by thegarbz · · Score: 3, Insightful

      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.

    22. Re:Bug or feature? by AHuxley · · Score: 1

      Like any other doctor, lawyer, engineer AC?

      --
      Domestic spying is now "Benign Information Gathering"
    23. Re:Bug or feature? by Greyfox · · Score: 2

      Well I'm pretty sure the desired number was blocked, so I'd call that a win!

      --

      I'm trying to teach myself to set people on fire with my mind... Is it hot in here?

    24. Re:Bug or feature? by LynnwoodRooster · · Score: 1

      That's why I think it may have been by design. Test a null entry, it does what it was supposed to - act as a wildcard...

      --
      Browsing at +1 - no ACs, I ignore their posts. So refreshing!
    25. Re: Bug or feature? by AC-x · · Score: 2

      It is often useful to be able to enter regular expressions for filters. And an empty regexp without anchoring matches everything. That's a feature, not a bug. But it is only okay to design it that way if you can safely presume that anyone who will ever add a filter understands regular expressions, or will look it up before attempting to add a filter. Slightly safer (but only slightly) is to always add ^$ anchors, so empty fields only match empty entries.

      Given how easy it is to write a non-empty regular expression that matches everything it would seem far more sensible to me to treat an empty regex field as "regex off / match nothing" rather than "match everything".

    26. Re:Bug or feature? by Hognoxious · · Score: 5, Funny

      If it says "filter by" and you enter nothing you're saying filter by nothing, i.e. don't filter, i.e. give me everything.

      Plenty of software works like that. Otherwise the user is going to have to enter * in 47 different fields.

      Now if there's a minimum number of selections (filter by at least one of foo, bar and froblgobl) that should be enforced somewhere in the software, twice.

      It was probably created by one of these full-stack unicorns I keep hearing about.

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    27. Re:Bug or feature? by Bite+The+Pillow · · Score: 1

      30 days in jail is a huge deal. I wouldn't recommend it for something like this. With so many people living paycheck to paycheck that's enough time to get behind on rent/mortgage, losing your home and if your marriage/relationship wasn't that strong that's an easy separation/divorce.

      You certainly wouldn't have a job after 30 days of not showing up, and your new job hunt doesn't happen while in jail.

      I really don't think you understand what you are recommending. Especially since I don't see you linking to any clear documentation proving someone was criminally negligent. "Cool their jets" would be more like 3-5 days. 36 hours without freedom would definitely be noticed.

    28. Re:Bug or feature? by Anonymous Coward · · Score: 0

      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.

      That's doing them a disservice. They may, but they're not being paid to be creative and think for themselves: they're being paid to follow the spec.

      The "offshore" humans are no different than the "onshore" ones: there are smart and dumb ones, and how much you pay them has no correlation to how much skill / intelligence they have. There are just as many dumb, uncreative developers and testers onshore as there are offshore.

    29. Re: Bug or feature? by Anonymous Coward · · Score: 0

      How many of these have you heard being outsourced?
      Putting restrictions on the development process and none of the finished product is just a sure way to have it all moved somewhere else.

    30. Re:Bug or feature? by K.+S.+Kyosuke · · Score: 1

      A null/blank input taken as a wildcard is certainly not a feature.

      It usually is in filter boxes, isn't it?

      --
      Ezekiel 23:20
    31. Re:Bug or feature? by Anonymous Coward · · Score: 0

      For reference, look at the Red Triangle Shirtwaist Factory Fire. Managers locked their staff in a factory floor several stories up, put buckets of water in the corners, and when a fire started, the majority of them burned to death because they were unable to escape.

      Who takes responsability? Back then, it was ruled the executive management acted reasonably and couldn't have known. Then people smartened up and stopped allowing yokels turned managers to run businesses that abused them. Today, if you don't have the appropriate safety mechanisms in place as a manager, it's not just big money, its jailtime.

      Civil engineering firms have a master architect sign off on blueprints so they know who designed what. What happens when a master architect "screws up" and a bad building design kills thousands? Oh wait, that never happens. Because there's criminal charges behind it for both the architect overseeing the design and construction project, as well as the building owner. We can somehow reliably design skyscrapers but not software?

      The management over the project in this case is 100% Liable, and 100% should, if someone died, be charged with manslaughter and if found guilty, should go to jail. Anyone who oversaw and managed the deisgn process is liable. If the law is found deficient to do this, then we need new laws. Otherwise, you're going to get a Red Triangle Shirtwaist Factory Fire, with hundreds or thousands dead which may possibly include YOU.

    32. Re: Bug or feature? by Joce640k · · Score: 1

      Who says it's a regexp?

      It could just be one of those weakly typed kiddy languages and somebody typed == instead of ===.

      --
      No sig today...
    33. Re: Bug or feature? by arth1 · · Score: 2

      Given how easy it is to write a non-empty regular expression that matches everything it would seem far more sensible to me to treat an empty regex field as "regex off / match nothing" rather than "match everything".

      Yeah, but then you don't follow the rules for how regexps work. You have introduced a custom exception, which is almost always a bad thing in programming. You introduce complexity, have to maintain the exceptions through library changes, refactoring and rewrites, regression test them whenever anything that's interfacing change specs, and also (remember to) bring them over to new code when you want to avoid surprises.
      Pre-populating any new field in an OR list with (?!), the common fail pattern, might be better. Also because it might make those who don't speak regular expressions stop and think.

    34. Re: Bug or feature? by arth1 · · Score: 1

      Who says it's a regexp?

      It could just be one of those weakly typed kiddy languages and somebody typed == instead of ===.

      It certainly could be. But lots of carrier code is written in C and Erlang.

    35. Re:Bug or feature? by Galaga88 · · Score: 1

      If I ran the risk of getting imprisoned for something as easy to mistype as the notorious "goto fail" I'd steer well clear of software development.

    36. Re:Bug or feature? by 140Mandak262Jamuna · · Score: 2
      Even by American "jail everyone for everything" standards.

      America does not have jail for everyone for everything standard.

      Usually if it looks like some ethnic minority is going to be on the receiving end, lots of internet warriors will post "jail time" posts. If it looks like it is going to be some white due the same posters will suddenly talk about onerous government tyranny, liberty and the founding fathers.

      Mercifully the actual courts are saner. Not perfect. But not as bad as these internet trolls make them out to be.

      --
      sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
    37. Re:Bug or feature? by jbmartin6 · · Score: 2

      The screw up wasn't this design decision. It was omitting basic double checks one should always have when making production changes, *especially* in a large environment like level 3. Where was the review by a second operator? Where was the warning "this change will block over $threshold numbers"? it is ridiculous that one person at one point could make a large scale change like this.

      --
      This posting is provided 'AS IS' without warranty of any kind, implied or otherwise.
    38. Re:Bug or feature? by Anonymous Coward · · Score: 0

      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.

      That's the difference between theory and reality. I worked at a Fortune 500 company that developed enterprise software and there was no such thing as any of that process. Programmers routinely released code directly to customers. No testing, no documentation, no approvals.

    39. Re:Bug or feature? by Nkwe · · Score: 1

      Find those individually responsible fine them, let them feel the weight of a custodial sentence, 30 days and fine the company much more.

      When looking for the "individual responsible", don't forget to consider whomever set the budget and didn't provide for enough resource to create a design, review the design, create a prototype, test the prototype with real users, perform failure analysis, make changes to the design and prototype as necessary, test those changes, etc. The root cause of many software (or any project for that matter) failures is insufficient resources being applied to solve the problem. Granted you have to balance what you spend with what you get and no one can afford a perfect system, but the true responsibility for system failures lies with those who set that balance. In other words the person who picks two out of the "Cheap, fast, good - pick two" is the really the one responsible.

    40. Re: Bug or feature? by AC-x · · Score: 2

      Yeah, but then you don't follow the rules for how regexps work. You have introduced a custom exception, which is almost always a bad thing in programming. You introduce complexity, have to maintain the exceptions through library changes, refactoring and rewrites, regression test them whenever anything that's interfacing change specs, and also (remember to) bring them over to new code when you want to avoid surprises.

      I think you might be overthinking this. This is purely a UI behavior issue, nothing to do with changing how the regex function behaves; If you have a mandatory regex field in a multi-field form, don't accept an empty value. If you have an optional regex field in a multi-field form, then leaving it blank should disable the regex call.

      Yes you have to remember the UI conventions you use, but you also have to remember things like checking for required fields so it's no more work than you should already be doing.

      Making an unintuitive and mistake-prone UI just because it mirrors how an underlying function behaves is asking for trouble, as in this example.

    41. Re:Bug or feature? by cascadingstylesheet · · Score: 1

      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.

      And thus they need an army of project managers and QA. Because cheaper!

    42. Re:Bug or feature? by Anonymous Coward · · Score: 0

      The problem is that it's likely impossible to know where the blame for the fuckup should lie.

      The tech who filled out a form incorrectly?
      The guy who "trained" the tech during the last afternoon of two weeks notice he'd been given that he was being made redundant, and didn't mention that if you leave this blank, it will fuck the entire phone system?
      The guy who wrote the operator documentation and didn't notice it?
      The programmer who implemented the stupid UI?
      The UI designer who threw together a poorly thought through wireframe and chucked it over to the devs?
      Each of the testers who missed this bug?
      The manager who promised that the latest release would be out on Tuesday come hell or high water, and didn't leave anyone enough time to do their jobs properly?
      The VP who told the manager that if they could get the release in time for the next board meeting, there was a chance that his department wouldn't be outsourced?
      The CEO who told his VPs that his number one priority for Q4 was cutting costs associated with project overruns, and that they were partnering with an outsourcing company to transition failing departments to a non-geographic service model?

      These high-profile failures are rarely as simple as "Jimbo pushed a button he shouldn'a".

    43. Re:Bug or feature? by Anonymous Coward · · Score: 0

      So why are corporate entities never held to the fires of "the law"?

    44. Re:Bug or feature? by Anonymous Coward · · Score: 0

      I work as a Senior Computer Programmer/Analyst in my local government. I get $39k per year, you think they are going to spend money on licensing me? Hell, they don't even pay to train me in new technologies and languages. I have to do that on my own and on my own time, but they will gladly reap the rewards.

    45. Re:Bug or feature? by Anonymous Coward · · Score: 0

      Why on earth would a phone relay blocking software even have the ability to "block everything"?

      Seems pretty stupid to me. Obviously it is a bug.

    46. Re: Bug or feature? by Anonymous Coward · · Score: 0

      Name the company. So we can avoid them.

    47. Re: Bug or feature? by Anonymous Coward · · Score: 0

      Grow a pair of balls and stand up for yourself. You might get a raise.

    48. Re: Bug or feature? by edris90 · · Score: 1

      No what it means is that you need to competent people, instead of brain dead biodrones. Obfuscating the function only reinforces bad thinking habits, which lead to mistakes in other areas

    49. Re: Bug or feature? by AC-x · · Score: 1

      Well that's a really stupid attitude isn't it? Purposefully create a UI that can take an entire system down without warning or logical reason by leaving a field blank just so you can sit there and smugly wait for someone to inevitably trigger the trap you laid for them?

      If you worked for me the person being fired would be you, not the person who left the field blank.

    50. Re:Bug or feature? by thegarbz · · Score: 1

      America does not have jail for everyone for everything standard.

      You're either living in a bubble as to how your country works, or you're actually in a horrible shit hole of a country worse than other countries your president refers to as shit hole. https://en.wikipedia.org/wiki/...

      And I've been to the USA, it's a lovely country so bubble it is. Step one is recognize you* have a problem.

      *Well not you specifically, your country has a problem, but you really should know about this problem.

    51. Re: Bug or feature? by Anonymous Coward · · Score: 0

      Maaaaaybe '.' shouldn't be used as a metacharacter in a field where '.' is typed regularly as part of the value.

      Then again, meta characters should be consistent across fields - no idea which other fields and formats might have been in that application.

      It might be useful to have another field right next to the field with the regex, a field where the user can input some test values and see immediately which ones match and which ones don't.

  2. Dancing around the fact by Anonymous Coward · · Score: 1

    It was Linux.

    1. Re: Dancing around the fact by Anonymous Coward · · Score: 0

      Let me guess. You like Star Wars right?

    2. Re:Dancing around the fact by Anonymous Coward · · Score: 0

      So the Linux Kernel is responsible for a programmer handling a NULL entry as a wildcard. Rightio.

    3. Re: Dancing around the fact by Anonymous Coward · · Score: 0

      Yes, I have sex with my Star Wars toys. Why do you ask?

    4. Re:Dancing around the fact by PPH · · Score: 1

      rm -rf / tmp/junk/

      --
      Have gnu, will travel.
    5. Re:Dancing around the fact by Anonymous Coward · · Score: 0

      rm -rf /
      The rest you send to /dev/null

      Nothing of value was lost

    6. Re:Dancing around the fact by Anonymous Coward · · Score: 1

      Windows gets the blame all the time on this site for userland software. What’s good for the goose...

    7. Re: Dancing around the fact by Anonymous Coward · · Score: 0

      Good point, Trump will die in prison either way.

    8. Re:Dancing around the fact by FrankSchwab · · Score: 1

      I did this once...on the first day of a new job.

      I was wondering why the delete was taking so long...until the other developers around started asking "what's going on with the server?".

      --
      And the worms ate into his brain.
    9. Re:Dancing around the fact by Anonymous Coward · · Score: 0

      I take it that was also your last day at the new job?

    10. Re:Dancing around the fact by Anonymous Coward · · Score: 0

      Windows gets the blame all the time on this site for userland software. What’s good for the goose...

      So given the following taken from the software datasheet for the software which is supposedly behind this

      Client Requirements

      • Intel Dual Core CPU @ 2.4GHz or higher
      • 2GB RAM or higher
      • Windows, Window XP, Vista
      • Microsoft Internet Explorer
      • Mozilla Firefox

      I assume that all the MS Trolls on here will be uninstalling Windows today and we will never hear from you again?

    11. Re:Dancing around the fact by bobbied · · Score: 1

      I did this once...on the first day of a new job.

      Who get's root privileges on the first day? Even if you are a sysadmin you don't get root privileges on your first day around here.... But what system admin doesn't have story like this? I once deleted ALL the E-Mail on a system with a wild card, but we had a full system backup that I made the night before so not much was lost beyond face.

      This is an example of why I NEVER run a console with admin privileges as the default. I do have "sudo", and any time I type "sudo" it's my reminder to pause and actually read the following command and make sure I know what I'm doing... We also have BACKUPS or I'm going to be complaining every chance I get.

      --
      "File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
  3. viewed the empty space as a "wildcard" character by Anonymous Coward · · Score: 0

    had me laughing out loud. I of course didn't rtfa but what was the abused language.

  4. CenturyLink by Anonymous Coward · · Score: 0

    I can see why CenturyLink sucked up such talented employees and wonderful software...it's right up their alley....

  5. Software did what it was suppose to. by pirodude · · Score: 4, Interesting

    I'm 99% sure they were using the Sonus EMS management software (L3 is a huge Sonus shop) to manage the PSX routing engine. The software works as longest match of the number. Since you have to always select the country, a blank entry would be treated as +1 and block everything after that or everything in the US.

    1. Re: Software did what it was suppose to. by Anonymous Coward · · Score: 0

      Same as your troll :)

    2. Re:Software did what it was suppose to. by SlaveToTheGrind · · Score: 1

      The software works as longest match of the number.

      Why?

    3. Re:Software did what it was suppose to. by Anonymous Coward · · Score: 0

      You always want to match longest match so yo can get the most specific route to the number.

    4. Re:Software did what it was suppose to. by pirodude · · Score: 5, Informative

      If you want to route all 212 area code numbers to a specific carrier you can just enter '212' and it will route them. If you want go do a NPA-NXX, just enter '212555'. Since it's longest match it will also work for a 'thousands block' (ie, 2125551) and even down to the individual number (2125551212). US numbers don't mean a whole lot, but in other countries they specify specific geographic regions, carriers or number types. The backend database takes longest match for the most flexibility and the EMS UI is nothing more than a glorified frontend directly to the DB. There's little business logic actually protecting you.

      In a lot of cases, you want a wildcard match. I route a number of prefixes to different carriers with longer matches but I have a blank entry to default fall back directly to Level3 if I don't have any other carriers to handle calls.

      Everyone who uses Sonus knows this is how it works. It sounds like they gave a task to someone and only trained them on one piece of data entry. The fact that 800 people had access to this highly specialized software without higher level tooling that adds in the required business logic is the terrifying piece.

    5. Re:Software did what it was suppose to. by SlaveToTheGrind · · Score: 1

      If you want to route all 212 area code numbers to a specific carrier you can just enter '212' and it will route them. If you want go do a NPA-NXX, just enter '212555'. Since it's longest match it will also work for a 'thousands block' (ie, 2125551) and even down to the individual number (2125551212).

      I may well be missing something, but I'm still not seeing why this scheme provides any benefit over one where you explicitly ask for a wildcard if that's what you want (using your examples, '212*' '212555*' or '212555????' and so on. A system where a blank entry means the rule will be applied to any and everything seems like it's just asking for the exact sort of trouble that arose here.

    6. Re:Software did what it was suppose to. by Anonymous Coward · · Score: 0

      So you can enter prefixes? Most of the time you want to block certain prefixes. Arguably every phone number works as a prefix because (except for special codes) all digits after connection is made are ignored.

    7. Re:Software did what it was suppose to. by Narcocide · · Score: 1

      It's just the simplest, most brain-dead way to code it that supports any form of multiple-matching entries. Probably not coincidentally it is also the method that takes the least amount of server load while still supporting the ability to test for any partial or full string equality whatsoever. I highly doubt whoever wrote that code even spent enough time thinking about it to realize this would be an inherent weakness to such an approach. If they did, they certainly didn't expect it would be handed over to someone who doesn't pay attention to detail.

    8. Re:Software did what it was suppose to. by Anonymous Coward · · Score: 4, Informative

      I may well be missing something, but I'm still not seeing why this scheme provides any benefit over one where you explicitly ask for a wildcard if that's what you want

      Phone numbers are hierarchical and variable length (as opposed to e.g. IP addresses which are fixed length). a) The most common mistake to make is to route only a particular number or set of numbers as opposed to the hierarchy - using the shortest match by default avoids this mistake b) the routing algorithm used normally also works on a hierarchy, so a wildcard match apart from the end of the number can be very costly and unwise c) that's the way it's "always" been done and so doing something different would be conusing.

    9. Re:Software did what it was suppose to. by Kjella · · Score: 1

      The backend database takes longest match for the most flexibility and the EMS UI is nothing more than a glorified frontend directly to the DB. There's little business logic actually protecting you. (...) Everyone who uses Sonus knows this is how it works. It sounds like they gave a task to someone and only trained them on one piece of data entry. The fact that 800 people had access to this highly specialized software without higher level tooling that adds in the required business logic is the terrifying piece.

      Well is any other API than the EMS UI supported for creating DIY management tools, like do they want you writing directly to the database? Creating your own, custom UI to behind the scenes call the real UI seems excessively complex for what you get. Seems like EMS could fix this quite trivially with a warning and/or permissions, like you can only add blocks over a certain length, that blocking single numbers/area codes doesn't mean permission to pull the plug on entire countries. Even as a paid enhancement request that can't be that expensive...

      --
      Live today, because you never know what tomorrow brings
    10. Re:Software did what it was suppose to. by Anonymous Coward · · Score: 0

      There are full documented APIs for the PSX (they're SOAP but they still work fine) and you can write directly to the database if you want. We're a small shop and even we've written custom tooling around the EMS software for our core engineers to perform routine business tasks.

  6. Code Examples? by Anonymous Coward · · Score: 0

    My best guess is the bug was: "block if phoneNumber.containsAnyFrom(blacklist)"

    Every phone number contains "" so all get blocked. I'm assuming the input field gets trimmed of whitespace and assuming it wasn't a feature.

    Any other ways it could have occurred?

  7. No sanity checks by Anonymous Coward · · Score: 0

    Bugs happen, and when they do you should fix them, but having no sanity checks on the input data nor on the the rules which govern critical infrastructure? That's irresponsible to the extreme.

    Also, why are naughty phone numbers being entered into a GUI, by hand, one at a time? Don't tell me these numbers are based on Caller ID, too.

    1. Re:No sanity checks by RhettLivingston · · Score: 1

      Exactly. No matter what the interface says, something at a lower level should have at least made it explicit that 111 million numbers were about to be blocked and verified the intention. Even better though, it doesn't sound as if they new this interface even had a wildcard capability. The lower level should probably not even implement it. The interface is not the right location to preclude things like this from happening.

    2. Re:No sanity checks by Anonymous Coward · · Score: 0

      Sanity checks? Please! We can't even get slashdot to do that when some dumbass insists on posting comments with their unicode bullshit. Of course that same dumbass will tell you that 'sanity checks' are censorship.

    3. Re:No sanity checks by AHuxley · · Score: 1

      Sanity checks would slow down local and federal law enforcement collect it all projects.

      --
      Domestic spying is now "Benign Information Gathering"
    4. Re: No sanity checks by Anonymous Coward · · Score: 0

      Thank you, Voice of Moscow.

  8. Facts missing in summary by Anonymous Coward · · Score: 0

    While empty fields are a stupid wild-card option, it's seems reasonable to assume this sort of error didn't happen all that often. Why wasn't the employee aware of the stupid UI? Was entering a malicious number rarely done? Was this the first time this employee performed this task?

  9. 1) Warning or 2) Only manager can block all calls by myid · · Score: 1

    1) There should have been a warning: "Do you want to block all calls?" If not, then require the employee to enter a phone number.

    2) Or for a better solution, that form should not interpret a blank field as a wildcard. If all phone calls are to be blocked, then someone must sign on with a manager's user id, and fill out a special form that lets you block all phone calls.

  10. I think that's totally cool! by Anonymous Coward · · Score: 0

    One guy can bring down a whole system so easily. For years I've been trying to tell you people your contraptions are not ready to be put online, just like your silly "self driving" cars. Maybe in 50 years or so you'll get it right, but for now, let's stick to slide rulers, pencil, and paper. That's how we built the 747 and went to the moon, and notice, we haven't been back, or built a superior airplane, why? Because we no longer use the tools that work!

  11. chmod -R .* by Anonymous Coward · · Score: 0

    and of course rm -r .* -- which might work if you're a restricted user deleting your .files, until you do it as root or with sudo.
    It should be an entirely reasonable thing to do, right?

    What about you doing a "ls -R" or "find" or anything recursive, and hitting a symlink or a network mount point? Perhaps you're now scanning a million files on a secondary HDD or on a slow network mount. Hope you're not doing something worse.
    What if you're automatically "backing up" your files?, then after you've written "banana" into all your files, your backup gets overwritten.
    What about "-r" vs "-R" and "-p" vs "-P" : a much milder issue but shows that user interfaces aren't all that great or consistent.

    What if I put a file named "-r" in your directory. (or "~")
    If all those examples are fine, then I'm thinking the phone exchange software worked as intended.

  12. Re: 1) Warning or 2) Only manager can block all ca by Anonymous Coward · · Score: 0

    Also, how about a dialogue box that says âyou are about to block 111 million phone lines from xxxx to xxxxxxxxx. Also manager authorization codes needeâ(TM)

  13. I used to think by Anonymous Coward · · Score: 0

    I used to think that US' FCC was this responsible organization being involved in all the tech stuff going on, but now it seems it is as tainted by corruption as the one and only CIA.

    I am a European though and I don't live in USA, though until recently until the dubious decision by FCC to work against net neutrality I had a fairly positive view on FCC. Admittedly I didn't know much about them.

    As an adult, it seems organizations I have heard about growing up is falling from grace with me.

    I can't help wonder if a major outage with comms tech in a country could perhaps be related to secret changes in a looming police state, though I might ofc be wrong, I am not surprised by anything anymore.

  14. Broken As Designed by Anonymous Coward · · Score: 5, Insightful

    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.

    1. Re:Broken As Designed by nospam007 · · Score: 2

      " You're not supposed to give wrong input, even accidentally!"

      I guess you never had a complaint from a user that your program behaved erratically, each time the secretary put heavy binders _on_ the keyboard?

    2. Re:Broken As Designed by bws111 · · Score: 2

      Nothing about your textfile method is in any way superior to using a GUI. Nothing. A text file can have blank lines, long lines, short lines, lines with characters you didn't expect, and other such stuff. The requirement for checking inputs is no different with a text file than it is with a GUI. The only difference really is that a good GUI can provide more immediate feedback on incorrect entries.

    3. Re:Broken As Designed by Anonymous Coward · · Score: 1

      Of course you need to give it well-formed input, you always have to do that. But programs can be much better at communicating what they're going to do with it that they usually do. Your argument is that I'm saying textfiles are inherently superior to GUIs. That's a straw man: I'm giving a counter-example of how GUIs are not inherently better than other methods, like the dead simple one-number-per-line textfile approach. That "GUIs are just better"-attitude is so entrenched it's the status quo to the point of evoking straw men against people who dare say otherwise. I'm saying that assumption is the ultimate source of this fuck-up.

      There is actually a giant hidden win in there, since reading such a file is dead simple and takes very little code, and will give results as good as or better than the giant pile of poo code that you usually get when you're trying to do GUI with some framework or other. But it's not the point. A textfile is not worse than a GUI, but simpler and more flexible, certainly given a decent editor more powerful. Funny how that works.

      But the point was this: It is the pretence that a GUI is somehow magically better when it obviously is not if you look beyond the GUI-ideology is what's holding you back here. Your "more immediate feedback" typically comes down to micro-managing the user, who is then lulled into a false sense of security that the GUI'll catch him when he falls. Except, of course, when the GUI doesn't because it considers, say, emtpy-field-is-wildcard a feature.

      And then the GUIistas can have massive debates on whether that's really a feature or is really a bug. It can be either way, depending on context, meaning that the whole "intuitive! no training needed!" pretence so inherent in GUIs is itself false. I'm really saying, you're better off not pretending.

      You're better off with something much simpler, much more straight-forward, less micro-manage-y, less filled with accidental death traps. And guarding against that latest part is especially what the review step does for you.

    4. Re:Broken As Designed by sydbarrett74 · · Score: 1

      You're misunderstanding him. He's saying that this GUI is entirely too fragile, where it should be fault-tolerant. In essence, you're preaching to the choir.

      --
      'He who has to break a thing to find out what it is, has left the path of wisdom.' -- Gandalf to Saruman
  15. The outage began by Wrath0fb0b · · Score: 1

    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.

    No, the outage began years ago when someone created a process in which a human being manually enters data directly into a production system.

    I swear, if I had a nickel for every time a major fuckup was root caused to "human error in a process that should have never had a human factor to begin with", I could buy a house in the Bay Area.

    1. Re:The outage began by Anonymous Coward · · Score: 0

      "No, the outage began years ago when someone created a process in which a human being manually enters data directly into a production system."

      so someone reports a number that has been spamming and you want to block it. you verify that it is indeed spamming. how do you block it in your system without someone manually entering the number somewhere?

  16. The 'Vendor Supplied' 100 second minute by TheRealHocusLocus · · Score: 5, Interesting

    In 1987 I had just taken a job at the local Telco and was hitting a steep learning curve. My experience to that point had been PC computers and networks, assembler, CBASIC dBase and the like. This was an IBM System/38 and their billing software used RPG/III, which was a real structured language unlike its spaghetti-GOTO RPG/II cousin, but aspects were still position sensitive and opcodes were silly-simple compared to languages with which I was familiar. It was more like assembler than anything else. Most data flows consisted of running commands that generated a relational input stream sort of like an SQL query, through simple RPG programs.

    We had just installed an ITT 1210 switch and ITT had sent over a block of sample RPG code demonstrating how to parse the various fields and flags appearing on call tapes. My boss provided specs for the internal call ticket system they were using and the simple (!) task was to write a shim that generated a batch of call tickets from each tape. Pretty straightforward, tedious without being intricate. But one part of their code slapped me across the face when I examined it.

    The tape recorded end time and call duration in whole seconds, call start time would need to be calculated. They had supplied a routine to do this but it didn't make any sense because I could see no modulo 60 arithmetic in it, they were applying the simple RPG subtraction opcode on the zoned fields. I spent the most mystified HOUR of my LIFE searching the language manuals for that surely described RPG's 'magic' ops for manipulating times and dates, which I assumed had to be there because IBM is GREAT and I am STUPID... finding none. Forced to conclude that I was looking at concept code that was dashed off hurriedly in two minutes I confronted my boss with it (and my solution) but it was a hard sell at first, because my boss was incredulous too.

    --
    <blink>down the rabbit hole</blink>
  17. So they could have .... by 140Mandak262Jamuna · · Score: 2

    So these phone companies have the ability to block all incoming calls from a malicious phones. All these days... All the complaints about spam callers... About scam artists posing as IRS employees .... They had the ability to block them. But they never did. Bastards.

    --
    sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
    1. Re:So they could have .... by Anonymous Coward · · Score: 0

      Actually, the truth is that a lot of telcos do set up a lot of these blocks, but they're only effective for as long as the caller keeps using the originating number. In general, this means they might be effective for hours/days at best before the spammer changes the originating TN.

      Network detection for these sorts of issues still winds up requiring manual intervention to validate prior to blocking it, and also means the spammer will get hours or days of being unchecked before there's enough data to hit one of those reports.

  18. name- now! by Anonymous Coward · · Score: 0

    Name the god damn supplier!

  19. Province, Prefecture, or Other Region by tepples · · Score: 1

    Does your country have a "Province, Prefecture, or Other Region" more general than city but more specific than a country? If so, that'd go in the State field. (Source: my experience integrating with postage software published by Endicia and UPS.) If the form states that the name or postal abbreviation of your province is invalid, then perhaps the business doesn't ship to your country.

  20. QA Is Good by Anonymous Coward · · Score: 0

    This is why QA is good and tech companies used to consider it a separate and necessary discipline.

    Awe, fuck it. We're too smart for that. Just throw it against the wall and see if it sticks. If it don't, we can just roll it back, right?