 I need more of that, a flask later. All right, folks, thank you for attending. This is Getting a Migraine. I'm Jonathan, or JBO for short. This is Mike or Michael, however you wanna call him. And Anurag was unable to come to DEF CON, but still he took an extremely important part in this research. We're all Microsoft researchers, which is kind of weird because like Microsoft usually do Windows stuff and not Apple stuff. However, we work for Microsoft Defender. And the reason why it's called Microsoft Defender not Windows Defenders because it runs on platforms that are not Windows. And we do Mac, Android, iOS, Linux, those kind of stuff. So this is kind of like a motivation that we have. This is not a Defender talk, but I mean just shows you where we're coming from. The outline for today is talking about some of the Mac OS mechanism, specifically SIP and entitlements. We're going to talk about how we found a vulnerability by mistake, kinda. How we automated our exploit by means of reverse engineering. We'll have a demo. We'll talk about the implications of what we've done. We'll talk about Apple's fix and basically fix this, I would say. And then we'll have some conclusions. So let's get to it. Some background. SIP or rootless is a mechanism in Mac OS if you're just unfamiliar with Mac OS completely. It's a mechanism that limits the capabilities of the super user of root. If you're coming from a traditional POSIX world, root can do anything and that's not true anymore. In Mac OS, even if you're running as root, you can't do a bunch of stuff, including in user land, which is kind of foreign to a lot of folks. What it does is to leverage something called the Apple Sandbox in order to protect the entire platform. By default, you can't turn it off without going into Recovery OS. I won't talk about Recovery OS too much today, but generally what it means is that you have to click, like to hit a bunch of keys and then reboot. Like you have to have physical machine, you have to solve the hellraiser puzzle and stuff like that. So you're not supposed to turn it off at all and several organizations, including Microsoft, like in our own internal network, actually monitor and make sure that SIP is always on as a defense in depth mechanism. And we'd like to think of it just mentally, that's not accurately accurate at all from a technical perspective, that it's kind of like AC Linux on Linux or protected processes on Windows in the fact that you're admin, but you don't own the machine anymore to some extent. And SIP limits certain actions of their root user and all users really to, as the name suggests, to protect the integrity of the system. So that means there are certain files you can't override, there are kernel operations you can't do and so on. And we'll be talking about that more thoroughly in the next couple of slides. SIP itself internally is controlled by NVRAM variables. There's actually more than one, but we're going to talk about CSR Active Config on Intel platform. And in the Apple silicone that runs on ARM, they have a thing called LP-SIP-0 that is read from the booted device tree. And interestingly enough, because Mac OS, like X and U specifically, the kernel is kind of like half open source or like 90% open source, you can find all the flags in the source code under csr.h and I name here just a few. It's not a complete list at all, but you can again kind of imagine what SIP does. So for instance, it won't let you load unrestricted, you know, just any kernel extensions which are really drivers. You can't write to certain file system locations which we'll be talking about today. You can't get task ports for a given PID. A task port is basically like open process in Windows or P-Trace in Linux. You can't really debug processes for what it's worth. You can't do kernel debugging. You can't do retrace. You can't write NVRAM variables for obvious reasons. If you could, you can just change like SIP altogether. And there are other flags here as well, but the issue that I want to talk about is the fact that it has a certain domino effect. What I mean by that is that if you have, let's say an NVRAM variable override, a way to bypass the NVRAM variable right protection by SIP, you can bypass SIP. Obviously, you can just overwrite like the bit flag in CSR active config. And similarly, if you can load an untrusted kernel extension, you can just write a rootkit, but also bypass SIP. And in fact, any part of SIP you can bypass actually like topples the entire domino of SIP. So that's important to note. Generally, if you're able to bypass one mitigation, you're able to bypass all of them in theory and also not in theory. A bit about SIP and file system restrictions. If you're a developer or malware author or whatever it is, that's probably the first thing that you'd notice when you come across SIP is the fact that you can't really write to certain paths in the system because SIP actually prevents you from doing that. Again, even if you're running as root. So SIP really prevents you from modifying any files that either have a specific extended attribute called com-apple-rootless or are configured in some file system library like sandbox.rootless.conf. And that's like a naughty list, I guess, for files that basically a set of files that can't be overwritten. But there are also allow lists for these restrictions that override like the rootless.conf and they're out of scope for this talk, but they're well documented. Obviously, the rootless.conf file is SIP protected by itself. Otherwise, again, you'd be able to change it and then do a bunch of stuff. And also you can't really add or delete the com-apple-rootless extended attribute for the same reason, right? If you could add that extended attribute you can create like an undelatable malware, for instance. If you could remove that, you could bypass SIP because you could modify files that are protected by SIP. So just keep that in mind. And generally, like Apple has released a modification to the LS command. If you do ls-lo, that's a capital O, an actual O, not a zero, then all the files that say restricted are basically files or directories or simlinks or whatever they are that basically can't be modified. So that's an example of a restricted file, for instance. So that's obvious, right? I mean, we have SIP. We basically have a different kind of layer in the system, if you will. And how does the thing work and how do we enforce things in macOS? Some background about entitlements, really. In the macOS ecosystem, processes are signed, right? And they're granted something called entitlements which are basically capabilities. So because entitlements are part of the signature of the process, you can't forge them easily at least unless you have like a gazillion PS4s and you connect them and I don't know, find the collision or something. And you can think of entitlements of a way to make a process stronger, right? Again, in terms of capabilities. And the interesting part is that Apple has private entitlements that they will only grant to their own processes. And because they sign everything, they won't sign your processes with those entitlements. These are known as private entitlements. And that essentially creates like a barrier or a capability-based security layer, if you will, because if you're able to only run, to only get certain capabilities or entitlements, but not the other type of entitlements, and Apple are the only ones who can have that entitlements and the entitlements are being translated into capabilities by the OS, it basically means that Apple has the keys to the kingdom. They control your box. You don't control your box as much anymore because you can't get those capabilities. You can't get those entitlements. And that's something very interesting, especially for us, again, Microsoft Defender, because we don't have those capabilities either, right? And you can think about the implications which we will be talking about later. For instance, because we can't, we can't let's say modify the com-apple rootless extender attribute, if there is a file that is naughty and have that extender attributes, we're kind of screwed because we can't really delete that file. That's just an example. And there are two very interesting entitlements for SIP file system restrictions. There are actually more, like SIP is very rich, as you can see, but there are the two very interesting entitlements that I wanna talk about today, which are com-apple rootless install, and that basically bypasses all the SIP file system checks. So if you have a process that has that entitlement, which is a private entitlement, it can basically bypass all SIP file system checks, which is really powerful. And then you have something even greater, which is called com-apple rootless install heritable, which inherits to all child processes the com-apple rootless install, which means that all of the child processes are going to be able to bypass SIP file system enforcements on their own. Now, if you think about the motivation why do these things even exist? Like why punching a hole through that security layer? Then you have to think about the name com-apple rootless install. These things are used for installations and updates. For instance, when Apple wants to do an OS update, they basically have to write to certain files, then those files might be protected, and that's the way they do it. They have, let's say, an updater, that updater has those capabilities, and then it's able to do whatever overwrite arbitrary files and so on. So that's the motivation that Apple has to even having those entitlements, if that makes sense. So this was all just background. Now, while performing routine malware hunting, we started noticing a process named drop-SIP. And the name itself is suggestive, as you can think. And that seems to be prevalent on many devices. And we were like, oh, cool, we found some malware and probably some zero-day in the wild. We were very excited. And a closer inspection revealed it's an Apple sign binary that runs under the system migration private framework directory, and actually drops capabilities that bypass SIP file system checks with an API called CSOps. That's a private API that I will be discussing next slide. And mentally, we think that it should have been called drop-SIP, but I mean, that's what it is. And it's not malware. That's the entire file, actually, so reversing it is not even like a thing. As you can see here, basically what it does, that's the main function for all means and purposes. What it does is really call CSOps with 12. 12 is CSOps clear installer, which I took the liberty of pasting like the screenshot from the X and U source code, which basically removes, as you can see, this is a not, the tilde is a not flag binary not flag that removes the CS installer and other stuff as well. CS installer is the com Apple rootless install and CS exec inherit SIP is the rootless install heritable entitlement, by the way. So basically what it does is to remove the installation capabilities or SIP bypassing capabilities of a process. And if it's successful in doing so, it will basically run exec VE on the command line and arguments that it got. And that's basically some mean that they have to run a file without having those SIP bypassing capabilities. So that's just a motivation. And we were kind of convinced that drop SIP is legitimate. It's not malware, it's owned by Apple. And basically what it does is to drop those SIP bypassing capabilities. So this is kind of where our journey begin. We noticed that the drop SIP process is a child process of system migration D, which is a demon, that's why it has a D in the end of its name. And it has the com-apple-rootless install heritable entitlement, which if you remember from three slides ago, basically inherits SIP bypassing capabilities to all its child processes. And that explains why drop SIP assumed that it has SIP bypassing capabilities to begin with. I hope that makes sense. And after concluding that drop SIP is legitimate, we basically decided to take a closer look at what other child processes system migration D has. Because it's a very powerful process. It's able to give all its child processes SIP bypassing capabilities just for fun. It depends on your definition of fun. And then this is a screenshot just showing the entitlements of this system migration D process. You can use code sign, that's the binary that Apple gives you to basically look at the signature. And that includes the entitlements. And as you can see, the set of entitlements, there are three entitlements that start with com-apple-rootless, and the second one is com-apple-rootless install heritable. I won't talk about the other two, but they're really interesting if you're into that kind of stuff. Now, this is again, not a talk about Microsoft and EDR and everything, but any EDR that it's worth, it's sold, you can basically ask questions. Like, hey, in my organization, give me all the processes that have so and so, right? All the processes that have command line blah and so on. So what we started doing is that, okay, we're Microsoft, we have an EDR, we have tons of data, even from macOS. And then we were like, okay, let's start hunting with EDR data. And that's really good, because you have a lot of different environments, a lot of different customers and whatnot. And also internally in Microsoft, we do have folks that run macOS as well, and they also report all the command lines and whatnot internally, right? So we were like, okay, give us a dear EDR, please give us all the child processes of system migration D. And we immediately noticed two interesting child processes, which are Bash and Pearl, right? These are just command lines. Again, these are child processes of system migration D, so they're very powerful in terms of see bypassing capabilities. Why are those child processes interesting? Well, Bash and Pearl are interesting because they're interpreters. And interpreters are affected by many things, especially environment variable poisonings. Now, in macOS, I won't talk too much about the security mechanisms in macOS, but injection in macOS is a real drag. It's not like Windows or Linux when you can just run open process or Ptrace. And especially Bash and Pearl are still baked into macOS and therefore Apple signed and actually are protected by SIP. So you can't get a task port to those processes and you can't inject into them. And that's why we needed a different method of injecting to those processes. And because they're interpreters, they're more convenient than others. Now, remember, these are processes that are child processes of system migration D, so they always does not enforce SIP file system policy checks on them, which is really helpful. And then I wanna talk about environment variables. So we found two noteworthy environment variables. These are just man pages of Bash and Pearl. For Bash, you have environment variable bash underscore env. And apparently, if you have that environment variable, you can just like write arbitrary commands there and like Bash will just run them, which is good and bad. For Pearl, it's not really complicated, but you have Pearl five opt for options and you can also make Pearl five opt by modifying it. You can make it run arbitrary Pearl commands, which is really great and bad at the same time. Now, this is like I'm doing a side track here. This is a general rent about environment variables. Shell shock happened in 2014. If you guys remember how bad it was, basically it was like a vulnerability in Bash that was related to the parsing of environment variables and how they're eventually executing. But it's like we haven't learned a lot about the dangers of environment variables. And it just took like the last couple of years, even this year, like in different platforms really, they're not all Mac OS. Like if you look at it like the first one from 2023 is in Linux, right? In the pseudo binary, in the suite binary, no less, which took years to really make secure and apparently not enough. And you have other cases here as well, including Linux, including Mac OS, and other things as well. And that doesn't even start scratching the surface because you have other issues that do not normally get CVEs, like UAC bypasses on Windows and you can override like the wind there directory or cloud credentials that are in environment variables and API keys like literally everywhere. So environment variables are very dangerous and should be taken care of. And this is where I turn over to Mike to talk about our exploitation strategy. That man with a flask is a goddamn hero. This is a fantastic tradition. I just wanted to say that. So thank you for that. Yeah, so like J.B.O. was talking about, the environment variables were the main thing that we went after environment variable poisoning. So we went about trying to validate this as a vulnerability that can be exploited by setting Bashi and V and Perl 5 opt. And from there we put the payload in the appropriate folder and it was just simply a matter of getting system migration D to run one of these two interpreters, which is a lot easier said than done. It felt like every single combination I tried didn't result in Bash or Perl being run at the end, which was frustrating, but eventually was able to find the right combination of just creating like a single dummy user and from there was able to get Perl to run. And that was like 4 a.m. I was talking to New Rug who's in India and he came up with Perl 5 opt exploit. And yeah, when I finally got to execute and validate that we got SIP bypass, it was an amazing feeling. And I was also like quite sleep deprived. So yeah, while we did prove that this is something that can be exploited, it wasn't perfect because we required like a physical USB drive to be attached to the device. Migration as you may or may not know will log off all users. Requires manual clicking through all the windows. And then of course it reboots at the end. So that's not ideal for a remote attacker. So this was a demo that we sent to Apple. I'm gonna spare you while I'm not gonna make you watch a 15 minute migration demo of me namoring on about the migration process, but I just wanna show a snapshot here where at the end we're writing over the Apple Kex exclude file. So if you don't know, Apple kicked everyone out of the kernel, but there were certain kernel modules that Apple still allowed to be loaded and executed. And all that's kept in a sit protected file called Apple Kex exclude list. So in the demo, I overwrote that file with just the word migraine as like a proof of concept to show that we can control these sit protected areas. Okay, so like I said, the initial demo and everything was pretty ugly. So the main challenges here were to obviously get rid of all log off, get rid of reboot. We wanted to automate clicking. So there's no user interaction needed. Obviously we don't wanna have a USB of physical access for this exploit to run. So we began reversing and trying to figure out how we can make that happen. So there's a top down approach and a bottom up top down was a very disgusting approach where we tried patching the system binaries themselves to get the behavior we want. Obviously naturally I took the disgusting approach top down bottom up was the more cleaner approach where we took the private framework that the migration Damon uses. And we tried to bend it to our will and call the functionality we need within that private framework directly with our own binary. Spoiler, neither of these approaches worked and we'll get into why that is. Okay, so migration like with most things in Mac is not a simple system, it's complex and it's multiple different processes that communicate through XPC and IPC to make this happen. We were trying to find some kind of documentation on migration and how it all works and of course Apple being Apple didn't offer us any of that documentation and we couldn't find anyone who's went out doing this and reversing it. So as far as we could tell we're the first ones to do it. So let's get into the high level of migration. So these blue squares, these are the key processes involved with migration. You can kind of think of like migration as like a chain and each link in the chain calls into the next and the previous link validates that the previous caller has the appropriate private entitlement. So an example being migration assistant will call into MBCS administration but then MBCS administration before it goes any further will validate that it has com.apple.private.MBCS administration entitlement and system administration calls in the setup assistant and setup assistant calls into the Damon all of which validate the previous caller. Okay, so migration assistant, this is the first link in the proverbial chain and this is what you all are used to using if you've ever done migration. It's essentially the setup wizard for migration where you can port a PC or Mac devices you can do it over hardware you can do it over network, all different options. So with the top down approach I wanted to patch this out because the most annoying thing we had to deal with was the log out issue. So if you're interested the function that migration assistant uses is something called SACLO start log out with options. Patching that out unfortunately didn't work for multiple reasons and I'll show you why. Oh yeah, so this was a little funny thing that JBO noticed. So when you go from PC to a Mac book Apple was kind enough to represent the PC as having a blue screen of death. So well played Apple, good job. Okay, so the next link. Migration assistant will then talk with MBCS administration and like I mentioned it'll make sure the XPC caller has the appropriate entitlement the MBCS administration entitlement. I obviously tried calling MBCS administration directly thinking oh we can get around the log out by just making our own binary and at the bottom here as you can see this is the console output of it telling me to fuck off. So you might be wondering how does migration work? Like how is a user able to interact with a GUI even though all the users are logged out and the answer to that is there's a hidden user called MBCS setup user. MBCS administration will essentially use this user for the entire process so you're not actually running as your user you're running as this hidden user. There's no password so we tried logging into it and thought we could get away with doing some fun trickery but those darn entitlements got us again. Okay so setup assistant. So the MBCS administration process will eventually call into setup assistant. Setup assistant is like a generic utility used by a lot of different things in the system. Some examples would be like system upgrade or accessibility wizard or of course migration and a whole lot of other things. And MBCS administration essentially will talk to setup assistant and it'll put it into the context of migration and eventually it'll transfer migration assistant into setup assistant context. So that's basically what's being called after a certain point instead of migration assistant. Of course when it does that it's validating that the entitlement is approved before it continues to do that. And then from there setup assistant will talk with the main HANCHO which is migration assistant or Damon, the migration Damon. And it does this with XBC and of course the system migration D will validate that the caller has the right entitlement. In this case it would be private.systemigration.damonclient. By the way setup assistant is like filled with entitlement so if you're looking for an interesting target I recommend going setup assistant and if not setup assistant in their folder there's other like just utility binaries that are ridiculously entitled. So just some homework to do. All right system migration D. So this was the bottom approach that bottom up approach that a new ROG took. When starting to reverse a system binary we recommend you start with the XPC handlers for like privilege escalation or MAC services. You can usually find those by opening up the associated P list shown here. And this is the migration Damon P list and there are six MAC services that we began looking at. So as we were looking at the migration Damon it was apparent that this private framework was being utilized pretty much everywhere and two key components for this were the object the migration object that uses along with the start listener for connections function which is how it handles like a callback for valid XPC requests. Okay so when it does receive a valid migration request system migration D will create a file in the location library slash system migration slash queue and in there is all the associated metadata for the migration request itself and it stores them at that location. So we thought okay well we'll just create a file there and we can bypass log out by just putting a migration valid migration file there. Of course it's SIP protected so we couldn't do that only system migration D can modify create or delete files at that location. So anyone who has done migration can tell you that there is at least one reboot not multiple reboots and the way the system can keep track of what the current migration request is is it takes the one of the specified files and it renames it to in-dash flight at the same location that's SIP protected. All right so why did our approaches fail? Well like I mentioned several times the intelligence for the big thing so anytime we tried talking directly with MB system administration or the Damon itself we couldn't get very far because they validate that the caller has the appropriate private entitlement. Also on newer Apple silicon devices while there are workarounds for this if you try to like patch a system binary the kernel will prevent it from running which is the code for that shown right here. So yeah we basically couldn't directly access system migration D and yeah. So even though we were dejected and our two approaches failed we started thinking maybe there's a way that we can cut out migration assistant and just talk with setup assistant directly and we had an in-house tool that we created that will log all events in the system even through multiple reboots and store them as like a buffer of files if you will and we noticed that when setup assistant was executed it passed a flag called dash minibuddy yes. So we thought well maybe there's other flags that we can pass setup assistant directly to create the migration behavior so we can prevent the log out to begin with. So as we looked into the reversing the setup assistant we did realize there were other parameters being used and we'll show that right here. So this is the main handler for minibuddy yes. So if you call setup assistant directly it's basically just a generic accessibility wizard that comes up and while none of these parameters gave us migration it was really encouraging though because some of them would have like completely different behaviors and different windows so we figured okay there might be something to this passing setup assistant parameter to get this to run migration. So while the main function didn't have what we wanted we looked further and we found a function called use debug parameters and in there is a parameter it handles called dash mbdbug and when we use that we were super excited to see that the old familiar migration windows were up and yeah we were excited because that means no log out needed. If you bypass migration assistant you bypass logging out. So yeah while it was great to see migration it still was a bit of a problem with automating because there were so many frivolous windows and extra things that made it difficult to use AppleScript to click through. So we found that if you use mbdbug in conjunction with ResumeBuddy yes it has a very lean migration process that we were able to pretty trivially automate with AppleScript and for people who don't know AppleScript can click through various windows as if a user's clicking it, kind of like auto it for windows and we were able to use that to automate going through the process without any user interaction. Okay so we got around the physical USB device by creating a small one gigabyte time machine backup on the set like a partition on the hard drive. You might be thinking one gigabyte doesn't sound small but anyone who's done time machine can tell you one gigabyte is really small for a time machine and from there it's the same steps we talked about where we're poising the environment variable setting the payload and we just run AppleScript and AppleScript will then run setup assistant with the appropriate parameters. All right so this is a demo we wanna show you guys so this is all real time. I just showed like the first five lines of the Apple kex exclude file and we're gonna run it and then at the end you'll see that the Apple kex exclude PLIS file which is SIP protected will be overwritten with the word migraine. All right so I'm just showing this as restricted which means it's SIP protected and we're calling OSA script which is AppleScript and from here it's calling setup assistant. This is the time machine backup we talked about the one gigabyte time machine backup and yeah it's going to find the right window and click through everything automatically. Kinda hard to tell but it basically deselected everything except for the dummy user I created and from here my exploit's gonna run it and then we kill the migration damon before it can reboot and as you can see migraine is now overwritten the Apple kex exclude and it is SIP protected. All right so you might be asking well who cares? Well SIP is like most security mitigations it's a double-edged sword and it's really great for protecting users from themselves and in deleting files they shouldn't delete to cause unrecoverable system states. It's also great for preventing kernel access or root kits but the problem is once an attacker gets past that layer they can do things that are extremely difficult to handle if you're like an AV product or an endpoint product. Some of these examples would be like you can create undelatable malware and folders that even if you have every entitlement that you need as a third party vendor you can't delete it. Obviously you can also get kernel extension execution like I talked about which is essentially is gonna be a root kit in this scenario and it can even bypass other security layers in macOS an example being like TCC so that means an attacker could listen on your microphone or watch your camera and you aren't notified and you have no idea. All right so I'm gonna hand this back over to JBO to talk about their fix and our attempts to forward it. All right thanks Mike. So we disclosed that bug to Apple back in May 2023 and you know there was a bit of like back and forth because it's not a very trivial exploit but eventually they kind of were able to reproduce it and they fixed it in their beta and we were asked to assess their fix, their beta version. So we were like okay let's like run the beta version and see what's up. And the first thing that we noticed was something that I like to call a brutal fix which I think that no other company in the world can do really which is basically saying something like oh no more global event variables and that's pretty amazing because they kill an entire like bug class just by doing that and as you can see here I basically try to use launch CTL set nv which is the proper way of setting an environment variable in launch D and basically telling me like we couldn't set the environment variable. Yeah and it's not permitted because of SIP. So now you know with all the things that SIP enforces it also now enforces the fact that we can't really touch environment variables which kind of like sucks and rocks at the same time. Note that this kind of enforcement happens at launch D it doesn't happen at launch CTL for obvious reasons otherwise anyone would be able to bypass it. So that's fix number one and then we were like okay we don't really need to affect all of the environment variables in the system we just need to affect system migration D which is like one process in the system. Yes it is a demon so it's a child process of launch D that's why setting the environment variables to launch D works to begin with but then can we do something else and launch demons in Mac OS are described as you could see earlier by a Pillis file that's the thing that Mike showed with all the different Mac services and those Pillis files kind of like have a way to define environment variables as well. Now the Pillis file for system migration D sits in the directory that is also SIP protected so you see how that won't work but we were like okay let's define a new launch demon and you know we don't have to put it in the Pillis file in a SIP protected directory and basically run the thing and it supports environment variables so that's good and I don't want to talk too much about it but basically there is a technology called launch constraints which makes sure that things that are supposed to run by Apple are only run by Apple in this case why it enforced us is that the Mac services that you guys saw those six Mac services are actually owned by a file that was launched from the SIP protected directory so launch constraints make sure that we can't hijack any system launch demons definitions ever which is another cool thing and pretty new in Mac OS that technology. In here you can see our attempts basically that's the Pillis file that we created this is a copy paste from the system the original system migration D the only difference is that I had to name it a bit different so now it's named com.jbo.apple and shouldn't really affect anything and the other part is this part where I basically try to set the environment variables specifically part of five opt now again this works but doesn't work really because the system migration D basically gets killed by the OS because of that thing so no dice and then the third attempt that we had really is that we were like okay can we do something that doesn't have environment variables because we noticed again those are Perl scripts and Perl scripts sometimes have dependencies can we find a strong dependency in the Perl scripts and as you can see in the right part whoops as you can see in the right part you have used strict and then use file base name those are basically imports just like imports in I don't know in Python or whatever and the file base name file is really translated to a directory in the file system and base name is going to be looked after basename.pm specifically which is the Perl module and Perl has dependencies and the lookup order and the lookup order you can print it with the at INC Perl variable as you can see here and this is the search order the interesting part is that the legitimate of base file base name sorry lives under system library Perl 5.30 which is C protected it's under slash system but then the first two directories at least are not C protected so we were like okay let's create slash library Perl 5.30 file base name.pm with arbitrary contents and trigger Perl without poising any environment variables and have it basically run our arbitrary commands which works and doesn't work it works but we were able to infect Perl but not for C bypassing purposes the reason for that is because Apple also had a tactical fix if you remember that drop SIP binary that we started the talk with well what Apple is now doing is basically dropping C bypassing capabilities before launching those scripts which is kind of like a tactical fix but it works because you can't do anything even if you affect Perl it doesn't have the C bypassing capabilities anymore so you can't use that for bypassing SIP it's a cool way to persist in then Perl intensive environment but not good for this exploit at least so that's the end really the vulnerabilities was assigned with CV 2023 32369 Apple has really made an amazing impression on us those are solid fixes and you know besides the tactical fix which is good like the other two fixes the launch constraints and the fact that there are no more environment variables is really interesting because these are solid fixes in terms that they kill entire bug classes they don't just kill our exploit they kill future exploit and as I hope you were able to see there are tons of exploits that rely on environment poisoning and stuff like that besides that Apple has granted a really nice bounty money which we donated to charity if you don't know that by the way and you get bounty from one of these big companies you can ask them to donate to charity and they will usually double that amount so donate to charity if you I mean if you're into that and we wish to thank Apple for everything here and it is our point of view that with Apple moving everything to user land and creating separate security layers as you could have seen with all the entitlements and stuff like that and they're basically killing kernel extensions and whatnot so you know there are like the peasants and Apple and in the OS at least and because they have the keys to the kingdom we believe that similar bypasses will basically shake the macOS ecosystem because again in this case we were lucky that we are the ones who found it but if you know there is some malware author that finds something like that they can create undilatable malware and stuff like that and no one will be able to do anything besides Apple which might be too late so I think that's pretty much it well thank you so much