Apple Silicon Exclusively Hit With World-First 'Augury' DMP Vulnerability (tomshardware.com) 67
An anonymous reader quotes a report from Tom's Hardware: A team of researchers with the University of Illinois Urbana-Champaign, Tel Aviv University, and the University of Washington have demonstrated a world-first Data Memory-Dependent Prefetcher (DMP) vulnerability, dubbed "Augury," that's exclusive to Apple Silicon. If exploited, the vulnerability could allow attackers to siphon off "at rest" data, meaning the data doesn't even need to be accessed by the processing cores to be exposed. Augury takes advantage of Apple Silicon's DMP feature. This prefetcher aims to improve system performance by being aware of the entire memory content, which allows it to improve system performance by pre-fetching data before it's needed. Usually, memory access is limited and compartmentalized in order to increase system security, but Apple's DMP prefetch can overshoot the set of memory pointers, allowing it to access and attempt a prefetch of unrelated memory addresses up to its prefetch depth.
If you feel your mind grasping at a certain familiarity with this, it's likely because the infamous Spectre/Meltdown vulnerabilities also try and speculate what data will be required by the system before it's even requested (hence the term speculative execution). But while side-channel vulnerabilities such as Spectre and Meltdown are only capable of leaking in-use data, Apple's DMP can potentially leak the entire memory content even if it's not being actively accessed. The nature of Apple's DMP also renders void some of the already-engineered fixes for speculative execution vulnerabilities -- those that rely on controlling what is visible to the processing cores. The researchers said that Apple is fully aware of their discoveries, but there are no plans for whether or not the company will deploy mitigations.
If you feel your mind grasping at a certain familiarity with this, it's likely because the infamous Spectre/Meltdown vulnerabilities also try and speculate what data will be required by the system before it's even requested (hence the term speculative execution). But while side-channel vulnerabilities such as Spectre and Meltdown are only capable of leaking in-use data, Apple's DMP can potentially leak the entire memory content even if it's not being actively accessed. The nature of Apple's DMP also renders void some of the already-engineered fixes for speculative execution vulnerabilities -- those that rely on controlling what is visible to the processing cores. The researchers said that Apple is fully aware of their discoveries, but there are no plans for whether or not the company will deploy mitigations.
Re: (Score:2)
Re: (Score:2)
It's actually funny, if you look at the number of remote code vulnerabilities on any CVE tracker, iOS and Safari have Android and Chrome beat by a landslide for remote code execution vulnerabilities. This is especially telling considering the vulnerability tally for Android includes literally every single vendor implementation, including cheap half-ass Chinese brands that you've likely never heard of, and you'll never see in any first world country. It's no wonder people in the elite spy business (like NSO)
It may not be possible to mitigate (Score:1, Insightful)
A lot of sources are saying it's impossible to mitigate this. It's a straight up flawed design (aka amateur-hour by the designers). It doesn't surprise me in the least considering my experience with their other hardware.
We shall see though. Often clever people figure out a way to do the impossible.
I really want Arm on the workstation and server to succeed. Hopefully a skilled company comes up with something affordable and powerful (and without stupid bugs).
Re:It may not be possible to mitigate (Score:4, Informative)
A lot of sources are saying it's impossible to mitigate this. It's a straight up flawed design (aka amateur-hour by the designers). It doesn't surprise me in the least considering my experience with their other hardware.
Reminds me of how before the IOMMU, any asshole could [theoretically] plug into your firewire with a dev board and read any memory anywhere on your PC. Or originally, your Macintosh.
Re: (Score:2)
Reminds me of how before the IOMMU, any asshole could [theoretically] plug into your firewire with a dev board and read any memory anywhere on your PC. Or originally, your Macintosh.
Entirely true, though back then no one ran disk encryption anyway, so if someone had physical access you were screwed either way.
Re: (Score:3)
"Entirely true, though back then no one ran disk encryption anyway, so if someone had physical access you were screwed either way."
There is, and always has been a BIG difference between someone being able to potentially get a malicious firewire device plugged into a computer and being able to take it apart and remove the hard drive.
Re: (Score:2)
Yep. You could hide a snooping device in a HDD case, plugged into the Fw, that was able to snoop on all memory in the system at near 400Mbps. That's a pretty massive security hole that was clearly not even imagined when Firewire was created, the lack of imagination being the similarity here.
Apple is frustrating because they do so much cool stuff, but so much of it is just grossly flawed because they apparently have serious Dunning-Krueger over there. But it's shiny!
Re: (Score:3)
"That's a pretty massive security hole that was clearly not even imagined when Firewire was created, the lack of imagination being the similarity here."
This is a hindsight observation from someone who does not know the history of Firewire development.
Apple did early development on Firewire as a processor communications interface. They certainly DID imagine this type of memory access application, it was what Firewire was for.
Apple, however, abandoned Firewire. When the DV video format was in development, S
Re: (Score:2)
So, no, any current processor vulnerabilities Apple is responsible today for do not resemble Firewire issues in any way, first and foremost because Apple did not develop Firewire, contrary to Apple fanboy lore.
Apple not only invented Firewire as we know it [johasteener.com] but also apparently Michael Johas Teener and David James are specifically responsible for the firewire-disk-as-DMA-controller functionality, according to the former of the two.
So yes, this current processor vulnerability where Apple engineers completely failed to consider the ramifications of creating access to the entirety of the memory space and not policing it is extremely similar to Firewire. And I would have never known exactly how similar if I hadn't gon
Re: (Score:2)
The DMA functionality of Firewire was not a "Sony faux pas", it was an Apple one. IOMMUs didn't exist yet at the platform level, and Apple didn't bother to make one for the Firewire controller.
Firewire DMA is literally what they envisioned Firewire being used for. And it was a great idea. It just needed security.
Thunderbolt without DMA is just USB.
Re: (Score:2)
There is, and always has been a BIG difference between someone being able to potentially get a malicious firewire device plugged into a computer and being able to take it apart and remove the hard drive.
Take apart? We're talking about the 1990s security here for comparison, launched in 1994. All someone needs is to stick a malicious boot floppy in your drive.
Re: (Score:3)
What makes the firewire DMA vulnerability a big deal is two things. One, it can read memory anywhere on the system. Two, it can be used secretly, and this use cannot reasonably be detected. This problem persisted well into the OSX days. I'm not sure which were the first Macintoshes which had an IOMMU, but it would have been well into the era of the Intel Macintosh. Characterizing this as a problem which only affected classic Macs with floppy drivers is frankly nonsense. It's not a Mac-only problem (any sys
Re: (Score:3)
Oh yeah I'm aware it was an awful vulnerability by the end. I just that meant that it was more that the world changed from under it than people being idiots. At the time it was made, it was pretty fanciful that someone would build the necessary, astoundingly complex hardware to read memory from the machine that's probably useless (single tasking OS for PCs) store it somewhere then somehow exfiltrate the stored data and device.
Characterizing this as a problem which only affected classic Macs with floppy dri
Re: (Score:3)
What's with the recent aggression? You seem to be really piling it on these days.
I apologize, both personal and global issues are ratcheting up lately and I'm a bit pissed off in general most of the time now.
I'm saying when it was designed classic macs and PCs had truly vast and much easier to access security holes.
That's certainly true, especially when running mainstream operating systems...
Re: (Score:2)
I apologize, both personal and global issues are ratcheting up lately and I'm a bit pissed off in general most of the time now.
No worries. I know the feeling. It's been a shit couple of years and looks like it's going to drag on a while yet :/
Take care of yourself.
That's certainly true, especially when running mainstream operating systems...
It's amazing really: and I remember going on the internet with Windows 95. Like using a sieve as a hazmat suit.
Re: (Score:2)
I remember going on the internet with Windows 95. Like using a sieve as a hazmat suit.
Luckily, I did very little of that. I got involved with non-mainstream operating systems and adopted them as a hobby very early on, so I've been in the position of only needing Windows for limited purposes for a long time. Thankfully, there has only rarely been web-related functionality not available on Linux (all DRM or ActiveX-related) for reasons which I suppose are fairly obvious given the history of web browser development. On the other hand, I also briefly ran WfW 3.11 at home just to see what that wa
Re: (Score:2)
I got into Linux with Redhat 5.2. I'd not heard of it before, but I saw a box set in a bookshop and was blown away by the idea that I could have unix at home. Best £50 (more like £120 in today's money!) I ever spent, certainly as an impulse purchase.
My machine also ran windows 95, gotta have C&C: red alert. Also I already had it.
I ended up with one disk (700M or so) for windows and a shiny new 6G disk for Linux. I got a CD-RW when they were half way affordable too, and ended up b
Re: (Score:2)
My first Linux was Slackware 2.0, so I go back pretty far. My first Linux machine was a 386DX25 with 8MB RAM and a Trident 1MB ISA VGA card. I've also owned a bunch of antique Unix[like] stuff like Apollo Domain, IBM RT/PC, and some others. For a while my primary system was a Sun 4/260. Literally at the same time one of them was still being used as a student toy machine at UCSC ('ucscb') although I think theirs had more RAM than mine (I had 24MB.) Mine only had to support me though, theirs would have dozens
Re: (Score:2)
First PC was a rather beefier 133 MHz P3 with 72(!!!) MB of RAM. That was something of an upgrade from my trusty BBC Master rocking 1MHz and 128K.
I've also owned a bunch of antique Unix[like] stuff like Apollo Domain
I've never used one of those, though I have seen them at a distance. Wasn't that something of an oddball? Quite advanced from what I heard but off the beaten track a bit.
Both of them are pretty hard on my old ass machine, an FX-8350 with 2x 950s.
I've got an old gen 1 Core i7 720 laptop (11 years
Re: (Score:2)
Apollo Domain systems were 68k ISA bus machines whose Unixlike OS gave birth to the UNC path. You could cd //hostname/path to other systems.
I do have a vaguely modern system but it's a budget laptop (HP Ryzen 3 that was $300 at wally world.)
My first PC was a used IBM 5150 with 64kB and a 30MB MFM disk (external) and an ISA card with an additional 384kB that was mostly intended to take an XT with 640kB up to 1MB. Instead it got me to 448kB :D
Re: (Score:2)
What makes the firewire DMA vulnerability a big deal is two things. One, it can read memory anywhere on the system. Two, it can be used secretly, and this use cannot reasonably be detected. This problem persisted well into the OSX days. I'm not sure which were the first Macintoshes which had an IOMMU, but it would have been well into the era of the Intel Macintosh.
Nope. Every PowerMac G5 had an IOMMU.
Re: (Score:2)
However, Apple didn't bother unmapping RAM (when the computer wasn't unlocked) until OS X 10.6.8.
Re: (Score:2)
Yup. G5 was the first Mac to have a DART. However, Apple didn't bother unmapping RAM (when the computer wasn't unlocked) until OS X 10.6.8.
That doesn't make a lot of sense. I've looked at the kernel code in question many times. Unless a driver is doing something very unusual, drivers typically called prepare() on an IOMemoryDescriptor right before performing an operation, which creates the mapping in the DART, then called complete() on the descriptor as soon as the operation was complete, which tears down the mapping. Immediately.
So with the exception of memory pages that were actively involved in I/O, you shouldn't have been able to get ac
Re: (Score:2)
What you claim makes sense, however, it isn't the case. [frameloss.org]
Re: (Score:2)
"All someone needs is to stick a malicious boot floppy in your drive."
Yeah, I'd totally let random coworkers into my office insert a floppy disk and reboot my PC from it while we had a meeting. That NEVER happened.
A coworker or friend or whatever carrying a firewire camera or hard drive they wanted to show me something from, or to give me copies of large files. Yeah that actually happened.
Re: (Score:2)
We didn't have autoplay on floppys. Autoplay was a CD thing, and CD thing for Windows mainly (can't remember what Macs did back then).
Re: (Score:2)
We didn't have autoplay on floppys.
We had auto boot from floppy.
Re: (Score:2)
We still have that. The problem with rebooting is that it isn't transparent and quick.
Re: (Score:2)
Plus the "Auto" makes absolutely no difference if you already have physical access, which you do, if you can insert a floppy and trigger a reboot.
Re: (Score:2)
What source says it's "impossible to mitigate this"? Do you have even one?
Because the notion is preposterous. Not only is this largely a theoretical attack (I'm being generous by not calling it a fully theoretical attack), with extremely little real world consequences, mitigations are *trivial* if it were something real.
"I really want Arm on the workstation and server to succeed."
You seem to know literally nothing about security or chip design, and decided to post some tosser, laugahble anti-Apple screed. M
Re: (Score:2)
"You do realize they haven't disclosed the real vulnerabilities yet, right? This is just a taste of what's coming."
Pure speculation. I think there are plenty of sources that say tomato sauce was a gift of the aliens from Alpha Centuri. See, anyone can do it.
Re: (Score:1)
"No bias there at all."
Because I have an M1 Mac I have a "bias"? Yeah, not really. I'm typing this on an Intel box. I have servers on AMD, Graviton 2, among many others. That's a modern life.
"Sources are people in the security industry in which I work."
ROFL. Yeah, no you don't. You are claiming ridiculous things.
These sorts of "you know it *could* hypothetically be exploited" (in a profoundly narrow sense) security papers come up by the dozens per month. The overwhelming majority have no real impact whatsoe
Re: (Score:2)
"Not only is this largely a theoretical attack (I'm being generous by not calling it a fully theoretical attack), with extremely little real world consequences, mitigations are *trivial* if it were something real."
What is YOUR source for this. Do you even have one?
"You seem to know literally nothing about security or chip design, and decided to post some tosser, laugahble anti-Apple screed. Me, I'll keep using my M1 Mac, and have been using ARM on the server for half a decade now. Hurrr."
Ah, some classic p
Re: (Score:1)
*What is YOUR source for this. Do you even have one?*
THE PAPER THAT WAS SUBMITTED. They are very open about the *incredibly* narrow known threat model (basically ASLR pointer obscuring *in the same process*), albeit -- as all papers do -- opining that maybe there is something worse that could be done. These sorts of security papers come out by the dozen per year, and generally no, there isn't any further risk, and the latent risk is negligible to irrelevant.
To be clear, when security researchers are pitchin
Re: (Score:2)
I have 2. An M1 Air, and an M1 Max MBP.
I'm well educated in processor logic design (I built my own processor out of TTL decades ago, and I keep up with the tech.)
There is nothing in the paper that indicates this is theoretical. If you can trigger the speculative prefetch, you can use it to leak data, period. End of discussion.
The only way this could be mitigated would be by turning off such functionality.
I suspect Apple will not do this for 2 reasons.
1) They prob
Re: (Score:1)
ROFL. Classic Slashdot. Good god.
Re: (Score:2)
Re: (Score:2)
On one hand that's clear hyperbole, amateurs couldn't even get to the point of fucking up this badly. On the other hand, looking for this kind of issue ought to be job #2, right after coming up with the idea for the feature. Anywhere information can be leaked has to be examined carefully. How carefully? Apparently, more carefully than this.
This is why we can't have nice things (Score:2)
As we rely more and more on innovative ways to get more performance out of processors this is going to happen. I doubt that this can be addressed by Spectre/Meltdown fixes either but we'll see. Attack vectors are multiplying every day and people trying to exploit them for fun and profit. Unfortunately for the rest of us getting the latest hardware and the buzz around it wears quite quickly when you realize that the old system you traded in was more secure than the new hotness you just bought.
I just upgraded
Re: This is why we can't have nice things (Score:2)
I "upgraded" to the same phone last week, from a Note 20 Ultra. Lost MST support, and the microSD slot. Probably other things too. Never mind security. I wish I could have kept the old phone, nut it was corroded from too much hot tub use. Not as waterproof as my Note 8 and Note 4, unfortunately. I hope the S22 Ultra proves better. At least I didn't have to pay for the downgrade. Between the free cell phone insurance from Wells Fargo, the value of the old device on ebay that I shipped earlier today, it was c
overblown (Score:4, Informative)
As usual, the press has made a mountain out of a molehill.
The summary of the paper basically says:
* you can figure out where stuff is, sort of, in spite of ASLR.
* you can read past the end of a buffer
If this paper is written to the standards of CS, it's no surprise that nobody can' understand WTF they're talking about. They spend a lot of time building a model, then they talk about how to determine if the model works and how to detect the various model features, then they talk about how they tried to do that. Then they talk about theoretical attacks, etc. Then they do some actual work.
But really, it seems like the two above are it. And for #2 it's unclear if those memory accesses can happen to memory outside your sandbox or not because their writing sucks.
I mean, they build this whole thing about DMPs without actually saying whether they exist or not. Then they talk about how to test for the various features of these theoretical things.
I mean, it's a hot article because it's all M1! SECURITY VULNERABILITIES LIKE SPECTRE!
But fuck, there's not a lot there.
Reminds me of the discovery or ROP (Score:5, Insightful)
From my understanding after skimming the paper, they've shown a new category of exploit, and haven't yet built useful, practical examples. This looks like it will provide a new type of arbitrary read primitive.
On one hand, there's no need to be worried that your M1 Mac being hacked with this this weekend. It's not a "you need to patch right now" like the nine critical vulnerabilities in Windows last patch Tuesday.
On the other hand, it's an entirely new TYPE of vulnerability. That' could easily be a big deal. For binary exploitation you basically use two things - an arbitrary read primitive and an arbitrary write primitive. Wrap those up in and me functions and you've got yourself a little programming language for whatever shellcode you want to use. If this provides a read primitive, that's really significant.
It remind me of the ho-hum reaction on Slashdot when the discovery of ROP (return oriented programming) was announced. "Eh it only works of the program already contains vulnerable gadgets; it's no big deal", Slashdotters said. Of course now probably most binary exploits leverage ROP or its descendants. Every program contains the gadgets you need to read and to write memory locations, and those are the only two things you need to need to do to have complete control of the machine.
With a top speed of around 5 MPH, the same as walking speed, the Benz Parent Motor Car model 1 wasn't a particularly useful. Thing in the late 1870s. It did, however, demonstrate that cars are possible and that turned out to be important. The Wright brothers first controlled plane flight was 120 feet - a completely pointless thing to do. That's kinda how I see this. (Though obviously a new type of hack is significantly less important than a new type of popular transportation.)
Re: (Score:2)
From my understanding after skimming the paper, they've shown a new category of exploit, and haven't yet built useful, practical examples. This looks like it will provide a new type of arbitrary read primitive.
It's similar to meltdown, in that it's highly specific to the prefetch hardware.
It was an obvious target, but nobody knew it was there.
So yes, it provides a meltdown style read primitive, via intelligent prefetching. DMPs are going to become more common, because they're the most obvious performance improvement that doesn't cost more power, but there'll never be a generic form. It'll be specific to the behavior of the specific DMP.
However, we may never see another one of these, because the mistake that w
Re: (Score:2)
However, we may never see another one of these, because the mistake that was made, like Meltdown, isn't likely one that's going to be made again.
Except Intel kept making exactly the same mistake for multiple generations, long after everyone else had gone beyond mitigations to fix it... Let's see if Apple actually fixes this successfully.
Re: (Score:2)
Really, it was a decision to mitigate it in microcode at the cost of performance because their road map relied on very very very little work actually being done to new Skylake re-releases.
Re:Reminds me of the discovery of ROP (Score:2)
> because the mistake that was made, like Meltdown, isn't likely one that's going to be made again. The DMP will prefetch from *anywhere* without regard for the page tables.
Page tables are a construct within some operating systems. The memory hardware is never going to consult the operating system before it performs hardware prefetch.
Re: (Score:2)
Page tables are not a construct within operating systems... Page tables are manipulated by operating systems.
They're how the MMU handles memory indirection.
How exactly do you think virtual memory maps work?
Re: (Score:2)
Let's pretend I didn't say that. :)
Missed opportunity (Score:2)
Re: (Score:2)
Why on earth call it "Augury" when every other exploit so far have gotten fancy names. This should obviously been called the "you're holding it wrong" exploit, or perhaps the "brave" exploit! Completely missed opportunity here.
Only to those mentally or physically 12 years old or younger.
Re: (Score:2)
Only to those mentally or physically 12 years old or younger.
Coincidentally, this is the same group that thinks that Apple stuff is secure.
Re: (Score:2)
Only to those mentally or physically 12 years old or younger.
Coincidentally, this is the same group that thinks that Apple stuff is secure.
Gimme a break!
This is a theory about a theoretical vulnerability. Nothing to see here; move along.
Re: (Score:2)
This is business as usual for Apple. They generally fail at security. That doesn't set them apart from the other big PC OS vendor, but it is the opposite of what most Apple fans imagine.
Re: (Score:1)
Re: (Score:2)
Yeah, my iMac Pro came with the Firewall off and in Mail "load remote content in messages" box checked as the installed defaults. I caught these but wonder what I missed, I've seen this with other new macs as well.
So, the question is: How many Support issues and User Frustration are caused by Windows overly-aggressive Firewall settings?
Same thing with the "Load Remote Content"?
So, the question becomes "Where do you draw that line between Usability and Security?"; because they are almost never the same. Keeping in mind that Apple focuses on the average home application; where there is often no one available to provide troubleshooting and advanced support (like troubleshooting Firewall Rules). And considering Apple off
Re: (Score:2)
I think people are mocking the conception that "Apple is more secure", when historically this has only been the case due to lack of adoption, since Apple is very specific about the security they throw to the wind for the sake of experience.
But hey, if your cultists believe a thing that's to your benefit- you're damn well not going to correct them.
Full disclosure: Mac user.
Re: (Score:2)
I don't think anyone is denying that there is a real-world tradeoff.
I think people are mocking the conception that "Apple is more secure", when historically this has only been the case due to lack of adoption, since Apple is very specific about the security they throw to the wind for the sake of experience.
But hey, if your cultists believe a thing that's to your benefit- you're damn well not going to correct them.
Full disclosure: Mac user.
So, instead of derisive snorting, just exactly would you do differently as far as Mac (let's just restrict it to macOS for purposes of today's Debate ;-) ) Default Security Policies is concerned? Pf is a capable Firewall, and ipfw is still around (or downloadable); so the Tools are there. So it largely comes down to Defaults.
I've had to deal with the Windows Firewall tools in several versions of Windows Server and Desktop OSes as part of my work; and I'm here to tell you that there is no way that Suzy or To
Re: (Score:2)
So, instead of derisive snorting, just exactly would you do differently as far as Mac (let's just restrict it to macOS for purposes of today's Debate ;-) ) Default Security Policies is concerned? Pf is a capable Firewall, and ipfw is still around (or downloadable); so the Tools are there. So it largely comes down to Defaults.
Hah. pf (on the Mac at least; I know it differs significantly from the BSD implementation) is a goddamn nightmare to administrate.
They added anchors to try to make it more manageable via the frameworks (HyperKit is the big one that's constantly messing up my firewall right now)
But ultimately, it's a fucking pain in the ass. Like bad. Really bad. I get why nobody firewalls their Mac.
I've had to deal with the Windows Firewall tools in several versions of Windows Server and Desktop OSes as part of my work; and I'm here to tell you that there is no way that Suzy or Tommy Homemaker has any hope whatsoever winning a battle with that crap!
Ya, the Windows Firewall is the worst fucking thing ever invented by anyone. It takes the thing that sucks so bad about Mac's
Re: (Score:2)