Transcript
A (0:00)
Foreign and welcome to Risky Business. My name's Patrick Gray. We'll be chatting with Adam Boileau in just a moment about all of the week's cybersecurity news. And then we'll be hearing from this week's sponsor and it's Tony Delafuente who is the founder of Prowler. Prowler is I guess, like, what do you call it? It's an open source cloud security platform that you could do a bunch of cool stuff with and they have just added support for, for like M365 Entra, like sort of SAS scanning as well as infrastructure as code scanning as well. So you know, Prowler is just really becoming that one stop shop where you can get a view across all sorts of stuff, whether that's like aws, GCP and as you misconfigurations all the way through to Entra M365, you know, exposed OneDrive files, bad infrastructure as code code and yeah, all sorts of stuff. So Tony's joining us a little bit later on to walk through the latest feature releases for Prowler, which is of course free and open source. But Adam, let's get into the news before we do all of that. And yeah, there's a fair bit going on this week. The first thing we're going to talk about is memory integrity enforcement, which is a new, I guess, would you call it, feature of Apple devices. They've just published this huge blog post about how they're going to, you know, change their operating systems, iOS I'm guessing in particular to make them very, very resistant to memory corruption exploitation. And from as best I can tell, everybody says this stuff is really quite comprehensive, really well put together and it's going to get a lot harder to write exploits for Apple devices.
B (1:43)
Yeah, this is definitely some really good work by the security engineering team over at Apple. They kind of looked through a bunch of the exploit chains that they've seen being used in the wild and kind of worked up like given that we control the hardware stack and the compilers and memory allocators and all the components of that system, how do we build best in class exploit mitigation for memory corruption? And they've come up with, I guess it's an extension of an approach that the arm, the ARM CPU architecture people came up with, which kind of tags memory based on its purpose and then requires you to access memory using that kind of same tag value and that kind of means that buffer overflows. We are writing into a bit of memory that doesn't have the same tag or use after freeze where you're reading or writing to memory that has been changed since you originally got it. You have kind of tags that are out of back and then the system kind of builds on that primitive and across Apple's tool chain ends up being a pretty comprehensive memory corruption kind of set of mitigations. And part of it is changes to They've already been building secure memory allocators into the operating system, into the compilers for a while. So there's some changes to those. There is some support from, you know, kernel things and then also some support in hardware. So they Apple had a big product announcement, they released the iPhone 17 corresponding Apple Silicon chips. So there is some hardware support for this. Because one of the big problems with mitigations we've seen against things like specular execution and other, you know, memory misuse things is that the performance cost of the mitigations is unworkable too much. So through a combination of controlling the whole stack, they're able to kind of tune which bits need the really expensive mitigations. For example, they separate out allocations that are big enough to have kind of page level memory controls from ones that require inside page controls and they can come do a bunch of smart stuff. Net result of all of this is everybody in iOS is going to see, and presumably the rest of the Apple ecosystem will follow, will see some improvements to defense against memory corruption attacks, but in particular with the latest hardware you will get even more so pretty great work. And they've been working on this on a long, they've been working on this for a long time. According to the blog post, they say many, many years. And what's really interesting to see is that they've kind of closed that feedback loop between the people who are doing exploit dev and research and the people who are doing mitigation research. And then they can walk through the individual chains and say this particular chain is blocked by this mitigation at this step. And not every step of every exploit is going to be blocked, but all you've got to do is break one step in the chain and then also ideally break them in a way that renders the whole chain unusable. Because then, you know, friends of ours who write exploits will be having a bad day at the office and that's generally a good day for everybody else.
