We occasionally make fun of new security vulnerabilities that have a catchy name and shiny website. We’re breaking new ground here, though, in covering a shiny website that makes fun of itself. So first off, this is a real vulnerability in Apple’s brand-new M1 chip. It’s got CVE-2021-30747, and in some very limited cases, it could be used for something malicious. The full name is M1ssing Register Access Controls Leak EL0 State, or M1RACLES. To translate that trying-too-hard-to-be-clever name to English, a CPU register is left open to read/write access from unprivileged userspace. It happens to be a two-bit register that doesn’t have a documented purpose, so it’s perfect for smuggling data between processes.
Do note that this is an undocumented register. If it turns out that it actually does something important, this vulnerability could get more serious in a hurry. Until then, thinking of it as a two-bit vulnerability seems accurate. For now, however, the most we have to worry about is that two processes can use this to pass information back and forth. This isn’t like Spectre or Rowhammer where one process is reading or writing to an unrelated process, but both of them have to be in on the game.
The discoverer, [Hector Martin], points out one example where this could actually be abused: to bypass permissions on iOS devices. It’s a clever scenario. Third party keyboards have always been just a little worrying, because they run code that can see everything you type, passwords included. The long-standing advice has been to never use such a keyboard, if it asks for network access permissions. Apple has made this advice into a platform rule — no iOS keyboards get network access. What if a device had a second malicious app installed, that did have Internet access permissions? With a covert data channel, the keyboard could shuffle keystrokes off to its sister app, and get your secrets off the device.
So how much should you care about CVE-2021-30747? Probably not much. The shiny site is really a social experiment to see how many of us would write up the vulnerability without being in on the joke. Why go to the hassle? Apparently it was all an excuse to make this video, featuring the appropriate Bad Apple!! music video.
Half-Double’ing Down on Rowhammer
A few days ago, Google announced the details of Half-Double, and the glass is definitely Half-Double full with all the silly puns that come to mind. The concept is simple: If Rowhammer works because individual rows of ram are so physically close together, does further miniaturization enable attacks against bits two rows away? The answer is a qualified yes.
Quick refresher, Rowhammer is an attack first demonstrated against DDR3 back in 2014, where rapid access to one row of memory can cause bit-flip errors in the neighboring row. Since then, there have been efforts by chip manufacturers to harden against Rowhammer, including detection techniques. At the same time, researchers have kept advancing the art through techniques like Double-Sided Rowhammer, randomizing the order of reads, and attempts to synchronize the attack with the ram’s refresh intervals. Half-Double is yet another way to overcome the protections built into modern ram chips.
We start by specifying a particular ram row as the victim (V). The row right beside it will be the near aggressor row (N), and the next row over we call the far aggressor row (F). A normal Rowhammer attack would simply alternate between reading from the near aggressor and a far-off decoy, rapidly toggling the row select line, which degrades the physical charge in neighboring bits. The Half-Double attack instead alternates between the far aggressor and a decoy row for 1000 cycles, and then reads from the near aggressor once. This process is repeated until the victim row has a bit flip, which often happens within a few dozen iterations. Because the hammering isn’t right beside the victim row, the built-in detection applies mitigations to the wrong row, allowing the attack to succeed in spite of the mitigations.
More Vulnerable Windows Servers
We talked about CVE-2021-31166 two weeks ago, a wormable flaw in Windows’ http.sys driver. [Jim DeVries] started wondering something as soon as he heard about the CVE. Was Windows Remote Management, running on port 5985, also vulnerable? Nobody seemed to know, so he took matters into hiis own hands, and confirmed that yes, WinRM is also vulnerable to this flaw. From what I can tell, this is installed and enabled by default on every modern Windows server.
I finally found time to answer my own question. WinRM *IS* vulnerable. This really expands the number of vulnerable systems, although no one would intentionally put that service on the internet.
— Jim DeVries (@JimDinMN) May 19, 2021
And far from his optimistic assertion that surely no-one would expose that to the Internet… It’s estimated that there over 2 million IPs doing just that.
More Ransomware
On the ransomware front, there is an interesting story out of The Republic of Ireland. The health system there was hit by Conti ransomware, and the price for decryption set at the equivalent of $20 million. It came as a surprise, then, when a decryptor was freely published. There seems to be an ongoing theme in ransomware, that the larger groups are trying to manage how much attention they draw. On the other hand, this ransomware attack includes a threat to release private information, and the Conti group is still trying to extort money to prevent it. It’s an odd situation, to be sure.
Inside Baseball for Security News
I found a series of stories and tweets rather interesting, starting with the May Android updates at the beginning of the month. [Liam Tung] at ZDNet does a good job laying out the basics. First, when Google announced the May Android updates, they pointed out four vulnerabilities as possibly being actively exploited. Dan Goodin over at Ars Technica took umbrage with the imprecise language, calling the announcement “vague to the point of being meaningless”.
Shane Huntley jumped into the fray on Twitter, and hinted at the backstory behind the vague warning. There are two possibilities that really make sense here. The first is that exploits have been found for sale somewhere, like a hacker forum. It’s not always obvious if an exploit has indeed been sold to someone using it. The other possibility given is that when Google was notified about the active exploit, there was a requirement that certain details not be shared publicly. So next time you see a big organization like Google hedge their language in an obvious and seemingly unhelpful way, it’s possible that there’s some interesting situation driving that language. Time will tell.
The Patch Gap
The term has been around since at least 2005, but it seems like we’re hearing more and more about patch gap problems. The exact definition varies, depending on who is using the term, and what product they are selling. A good working definition is the time between a vulnerability being public knowledge and an update being available to fix the vulnerability.
There are more common reasons for patch gaps, like vulnerabilities getting dropped online without any coordinated disclosure. Another, more interesting cause is when an upstream problem gets fixed and publicly announced, and it takes time to get the fix pulled in. The example in question this week is Safari, and a fix in upstream WebKit. The bug in the new AudioWorklets feature is a type confusion that provides an easy way to do audio processing in a background thread. When initializing a new worker thread, the programmer can use their own constructor to build the thread object. The function that kicks off execution doesn’t actually check that it’s been given a proper object type, and the object gets cast to the right type. Code is executed as if it was correct, usually leading to a crash.
The bug was fixed upstream shortly after a Safari update was shipped. It’s thought that Apple ran with the understanding that this couldn’t be used for an actual RCE, and therefore hadn’t issued a security update to fix it. The problem there is that it is exploitable, and a PoC exploit has been available for a week. As is often the case, this vulnerability would need to be combined with at least one more exploit to overcome the security hardening and sandboxing built into modern browsers.
There’s one more quirk that makes this bug extra dangerous, though. On iOS devices, when you download a different browser, you’re essentially running Safari with a different skin pasted on top. As far as I know, there is no way to mitigate against this bug on an iOS device. Maybe be extra careful about what websites you visit for a few days, until this get fixed.
“…and the glass is definitely Half-Double full…” , thanks that really made me laugh!
For those not in the loop, [Hector Martin] is better known in some circles as marcan, whose name will almost certainly ring a bell in the Wii, Wii U, PS3 and PS4 hacking scene, among others.
Ah, yes, I really meant to include a note about his other exploits.
This is one of the worst-written articles on here in years. Almost unintelligible, then you add a paragraph and a half on “the patch gap” in general, like we don’t know about the cycle (discover a vulnerability, create a fix, roll out said fix). Some of it was actually so jumbled I had to read it twice. And “Inside Baseball”? What does that mean??? People should stop assuming they’re clever, and just write clearly. Call me what you will, but please do so intelligibly.
Apparently “inside baseball” is pretty strictly an Americanism. It just means an inside look at something obscure. https://en.wikipedia.org/wiki/Inside_baseball_(metaphor)
I took extra time with the term “patch gap” because it’s the first time I’ve defined it on the column. Not every reader is already up to speed.
It’s got the word “baseball” in it, so it’s pretty obviously an Americanism.
The worst thing with sports metaphors is that the meaning of a term can vary between sports. E.G. I was in a meeting with a US exec who referred to something as a “drop kick scenario”, and we had to stop the presentation and make his explain what sport it was, and what it therefore meant to him. Because in rugby a drop kick is about to score you some points, and in soccer it means the goalie only just saved it, and we didn’t even know if drop kicks are a thing in American football or what they’d mean.
“Drop kick me Jesus through the goal posts of life!”
https://www.youtube.com/watch?v=rSCfjBmNpew
Yeah, I’m an American, even played baseball, never heard the term. That cuts down the demographic of people who could potentially understand your metaphor to mostly only Americans, and probably only those who spend a significant amount of time watching baseball and listening to inane commentary and obscure terms. Also, give your readers more credit: first, consider your audience. Then realize that everyone knows how a vulnerability is addressed (in general). You literally described a company finding a problem, looking for a solution, then applying the solution. That’s not new info even for the computer/tech-illiterate: even a cave-man could do it. Sorry.
The concept of a secret 2 bit register isn’t all that weird.
From a CPU architecture design point of view, I can see some logic behind it.
Though, I would have made it reset to a known state on a thread switch.
But the idea of having a small register that doesn’t get packed up with the thread on a context switch could be practical.
Firstly it saves us the need to pack up another register, okay 2 bits isn’t much to pack up, but lets continue.
Secondly, if we don’t allow a context switch to happen in the middle of a microcode instruction, then we could use this register in our microcode instructions as a temporary place to keep some data without having to muddle about with registers that the end user is expected to actively use. This allows us to make more complex microcode instructions without fuzzing about with the overall code.
But I find it weird that there is a single 2 bit register though.
I wouldn’t be surprised if there is more of these secret registers in the core if they are there for the above reason. And I also wouldn’t be surprised if they more or less reset on a context switch, or maybe they don’t.
Though, leaving it in a non resetting state and also not packing it up on context switches is an odd combo that screams about potential security issues. Considering how unrealistic timing attacks can seem to the casual non security interested observer, and how serious timing attacks are in the industry, then how could one allow one’s non thread bound registers not reset when the data obviously is passed from one program to another…. I think the 2 bit one might just be a miss on Apple’s part.
(I should though clarify that I don’t actually know if Apple designed the registers with microcode in mind. But I think the idea itself sounds reasonable and it does solve some problems of making microcode.)
Then there is the new row hammer exploit.
Also interesting, though makes me wonder what can be done against it.
SRAM is an expensive solution.
Having some cache in the DRAM controller could make it harder to repeatedly hit a given set of rows around the victim.
Scrambling the rows themselves would also be interesting, this could fairly easily be implemented with a cross bar switch of sorts on the address lines for a given memory array. But this is more security through obscurity than actual security.
Though, I also wonder how realistic row hammer is as an exploit vector.
Considering how Specter for an example is a bit unpractical as an attack. Since it is slow and utilizes a lot of resources. It makes itself known, and slower specter attacks that are able to hide better can be prevented by just occasionally shuffling about the victim data itself. Though, gleaming out small bits of data over time is still an attack if sufficient data is gathered.
Perhaps I don’t exactly understand the reach of this menace, but isn’t the thing with this register exaggerating a little?
The same user vulnerable to this -any of us, I suppose- will be the same who, ignoring what is he doing, opens two “cooperative processes” which comunícate each other whatever info they want by using a file, a socket, a pipe, shared memory, etc.
As far as I know, it is not necessary to be ‘root’ for using all of this mechanisms. Perhaps not all the system will be compromised, buy *your* part will be.