Episode 286: Thijs Alkemade on the vulnerability from Black Hat

Meter is the easiest way for businesses to get internet, networking, and WiFi. Our full-stack approach combines hardware, software, and operations so that any company can seamlessly run on a reliable and modern network.

• Streamlined installation: We take on the complexities to make designing and deployments easy, fast, and stress-free. We manage the entire installation process, and provide ongoing maintenance and support.
• Network hardware, security & management: We design and build our own controllers, switches, and wireless access points. After the network is deployed, review your speed, usage, and security in one unified dashboard. No need to hire vendors in every location or have IT teams fiddle with manual configurations — everything is automated with our software.
• Simple pricing: Pay one monthly rate with no up-front costs for installation, configuration, or hardware.

---

James Smith:
Today’s episode is brought to you by our friends at Kandji. On Monday, October 3rd at 10:00 AM Pacific or 1:00 PM Eastern, join Kandji for their biggest announcement of the year. Find out how the Kandji platform is evolving to bring IT and InfoSec together to keep every Apple user secure and productive. To sign up for the event, visit kandji.io/launch. That’s K-A-N-D-J-I.io/launch. Thanks again to our friends at Kandji for sponsoring this episode of the Mac Admins Podcast.

Tom Bridge:
Hello, and welcome to the Mac Admins Podcast. I’m your host, Tom Bridge. And it’s great to see you, Charles. How are you today?

Charles Edge:
I am very good. It’s that perfect temperature in Minnesota where it’s chilly, but not cold. No snow yet, bright sun. So gorgeous day. How are you, Tom?

Tom Bridge:
Fall arrived in D.C. and kicked summer to the curb in a right quick hurry, and it’s beautiful outside. We were out yesterday evening after Charlie’s birthday party, and it was like 60, so I guess that’s the equivalent of about 18 celsius, give or take. A little less than that, 15, if memory serves. But either way, it was perfect outdoors, it was great. We’re coming up on fire pit season, which is my favorite season. Build the fire out there, have a glass of something nice and relax outside. So we’re hoping that this continues and we get some solid outdoor weather as we go towards the wintertime. But for now, fall is here.

Charles Edge:
Nice.

Tom Bridge:
And we have an incredible guest this week, Thijis Alkemade from Computest. He’s a security researcher. It’s a great pleasure to have you on the podcast, Thijis. Thank you so much for joining us.

Thijs Alkemade:
Thank you for inviting me.

Tom Bridge:
One of our favorite things to do about interviewing security researchers is those that can talk about what they do at places like DEF CON and Black Hat. They’re the good guys, right? They exploit vulnerabilities and report their findings to vendors in such a way so that humanity can stay safer on our devices. If it weren’t for researchers like this, the vulnerabilities would likely be uncovered and sold on the black market or used by nation states. So a huge thanks to Thijis for his hard work and his talk at DEF CON and Black Hat on process injection for macOS apps. So, Thijis, welcome to the podcast. When guests join us for the very first time, we love to get a little bit of an origin story about how you got started. Do you mind telling us what you do at Computest and how you came to be doing that?

Thijs Alkemade:
Sure. Got to start a little bit earlier. So before I joined Computest, when I was still a student, I used to work on some open source software a little bit. So I worked on the IM client Adium. Some listeners probably still remember that.

Tom Bridge:
Love that. I was going to say, I think I still have it installed on some of my Macs here, even if the services they talk to are long since gone.

Thijs Alkemade:
Many, if the services don’t work anymore, not many people still work on it. I used to work on that and then sometimes you need to work with libraries or you need to communicate with servers. So I looked at a lot of code that other people had written and sometimes I would spot a vulnerability and I would report that, of course, in a responsible way. And then it would get fixed and there would be an announcement of that and it would get a CV number. And I noticed that I found vulnerabilities much more fun than actually developing the application. I started wondering, can I turn code auditing into a job? So how can I do that?

Thijs Alkemade:
Then at some point I heard about Computest and the work they do in the Netherlands as a security testing company. I thought that’s pretty close to what I want to do. So yeah, that’s where I started pen testing. At the point, it was mostly websites. This is about six years ago now. And then at some point after I found some things outside of a customer project, I was allowed to spend half the time of my work on research. So not working for customers, but trying to find vulnerabilities in commonly used software to make the world safer, to help defend everybody.

Thijs Alkemade:
But that didn’t really work very well in practice because if you spend only 50% of your time, there’s no deadline. So customer projects do have deadlines and they’re always in a hurry to release their new website. It wasn’t really working out that well. So then about two years ago, my colleague Daan Keuper said, “I want to start a full-time research team, which is separate from the pen testing division.” So yeah, we get approval to do that. And since then, we’ve been doing research into many commonly used systems. We’ve done some interesting projects like we did the Pwn2Own hacking competition last year where we found a vulnerability in Zoom. Earlier this year we found some vulnerabilities in the industrial control systems.

Thijs Alkemade:
And macOS has been something that I just know a lot about. So it’s always been a bit of a background project for me. When I don’t have anything else to do, I might notice some process running on my Mac, I might note some weird files. I may have a new application installed and I just look around a bit at that. So it’s basically the background stuff of my research. So yeah, something to fall back on when I don’t have a project that I want to be working on. So that’s also what this vulnerability that I talked about at DEFCON and Black Hat, how I found that one.

Charles Edge:
That’s a pretty rad trajectory. Patrick Wardle was on a few times and he had a lot to say about dial-ups, which now by default, the little checkbox in Xcode when you go to compile dial-ups are off. I don’t know how much he had to do with that or how much that was just the natural trajectory of things. But do you mind explaining what process injection is and how that’s different?

Thijs Alkemade:
So process injection, to describe it, I always give this example of suppose you have one application and it has access to your webcam, like Zoom or Teams or something like that, and then you have another application, a malicious malware application on your Mac, and then that malicious application wants to use your webcam, but it cannot just ask for that because then the user is going to be suspicious because they’re not trying to use their webcam at that moment. So what that malicious application might try to do is somehow influence an application that does have that permission to run other codes than what’s normally in that application. There are various techniques for doing that. So one of those is the dial-up replacement. So taking existing application, replacing one library and then launching it. Previous versions, then you could just inject into that application.

Thijs Alkemade:
But basically the system still sees it as one application. So one application that has some powerful permissions, but the code that it is actually running was specified by another application, something that could be malicious, could be malware. And something like… So the dial-ups, that’s now fixed with what’s known as the hardened runtime, unless you opt out of that. So, that’s no longer possible except in specific cases where you don’t enable those features.

Thijs Alkemade:
But that’s a vulnerability in a specific application. And an interesting thing about the vulnerability that I found is that it is applicable to all applications that basically use AppKits or the native macOS UI and any application that does that was vulnerable to this because it was actually in that framework. So this means that there’s a lot of applications that you could attack with this vulnerability. And during the talk, I went over three of them to demonstrate what the impact could be. So in the first one, I escaped the sandbox. There’s a Mac Application Sandbox, which not many applications have it, not many third-party applications, but it’s possible. Then I elevated privileges to roots. And then finally I bypassed system integrity protection. So this is the file system protections of that. So I could write to files of the system, replace certain things that should not be possible.

Charles Edge:
And that was CVE-2021-3873, correct?

Thijs Alkemade:
Yes, that’s correct.

Charles Edge:
And I guess what exactly does it do? You mentioned three of the example use cases, but how are you getting to that point?

Thijs Alkemade:
So the vulnerability is in the feature that’s known as, it’s called persistent UI internally or window restoration in some other parts. The most noticeable part for users is when you shut down your Mac, you get this window where you want to reopen your windows the next time you log in. So basically that’s a feature and it’s built into AppKit where anytime an application closes, it can just save some of its state back to the disc, and then when it reopens, it can automatically read that state again and restore its windows.

Tom Bridge:
The great example here is BBEdit, right? The text editor, BBEdit, it’s great. You don’t have to worry so much about saving every document every time you quit the application, know it just saves state, drops that state off in the library, containers, bundles folder, and then when it relaunches, it opens right back up again.

Thijs Alkemade:
That’s a very convenient feature. Even if you don’t save your document anywhere on this, then it’s still there if you reboot your Mac. When it works well, it’s a very nice feature. But as it turned out, the way that that file format was stored on disc for saving those objects, it was using a serialization format, which was not using secure coding. Serialization vulnerabilities, they can be filed in many programming languages. The basic idea about it is that you take some data, or if you can turn an object into data that you can then store or send over the network and then when you receive some data back, then you can deserialize it and you get an object back.

Thijs Alkemade:
But the issue with many of those in many programming languages is that the object is created first and then you check if it is actually the correct object that you expect. So, if you combine in weird ways objects of different classes that are not expected at all, that you might be able to get something that’s printing arbitrary code, for example, or deleting local files or something like that. Now this is common in very many programming languages. So Java, C#, it’s very well known. But in Objective-C, this was also an issue, but Apple realized that pretty early on, I think about 10 years ago in, I want to say line, but I’m not sure, Apple introduced secure coding.

Thijs Alkemade:
So they made a secure version of their own serialization format. And with that, these vulnerabilities are no longer possible. And everywhere where Apple uses this to move data from one process to another, they use to secure a version. Basically they had 10 years to implement this. Anywhere I’ve looked at before, they used a secure a version except for this window restorations or this persistent UI part. There, they use these insecure serialized objects. So whenever a state of an application that saved was reopened again, you could replace some of its objects with objects of completely different classes and they would create it within that process. And then that could lead to taking over that process and giving process injection.

Charles Edge:
It must be hard to be a developer with this many lines of code where you’re looking at, in some of these cases, like the persistence framework, some of that goes back almost to the next era. It’s just that old, some of the philosophies for doing some of this stuff. So every time they have an update, they’re like, “Well, I left this other thing over here, millions of lines of code away and the next thing I know I’ve got a CVE. Damn.”

Thijs Alkemade:
Yeah. And when this was written, there was no vulnerability here, because applications didn’t really have these different permissions and process injection wasn’t an issue yet. So back in the day, this was just, yeah, the code was fine, but they didn’t really rethink it when they introduced all of these permissions.

Charles Edge:
They still allowed different ways to invoke bash scripts that would allow privilege escalation up until like Mountain Lion, I think. So to kind of hammer home what you’re saying, some of this stuff just evolved and you build a protection over in one area and you’re like, “Oh, I thought that would’ve protected against this other thing, but that hasn’t been updated yet.” So technical that you don’t know about is kind of the worst technical, isn’t it?

Thijs Alkemade:
Yeah.

James Smith:
This week’s episode of the Mac Admins Podcast is brought to you by Black Glove. Black Glove is about to be your new favorite IT partner. They provide ongoing expert support and rapid deployment services for your current, new, or refreshed Apple fleets. But what they’re really providing is complete peace of mind that your technology is safe, secure, and operating at its full potential. So no more quick and expensive calls to the Geek Squad or Apple Support. Black Glove’s strategies and fixes are from the hands and minds of former Apple engineers. So not only is the expertise of this team unmatched, but their services are affordable and easy to get started too.

James Smith:
Fortune 500 companies and small budding businesses alike are working with Black Glove to ensure their Apple technology is doing exactly what they need it to. Whether it’s helping manage your remote teams’ devices, transitioning your device management system, onboarding new employees or casing, tagging and tracking your devices, Black Glove can handle it all. They’re also just really great people to work with. In fact, mention this podcast when you reach out to them and the Black Glove team will sponsor the next generation of Mac Admins through our Mac Admins Foundation. You can learn more and get started at blackglove.com. That’s B-L-A-C-K-G-L-O-V-E.com. And while you’re at it, ask them why they’re called Black Glove. It’s a clever nod to how white glove services just don’t cut it for IT.

Charles Edge:
So does it work on hardened runtimes? Because that was one thing I was like, well, what if I check that box in my app? Does that prevent this or…

Thijs Alkemade:
So yes, it works on applications with a hardened runtime. I can create new objects. The actual chain that I had to go through is quite complicated, but using a couple of different steps, I was eventually able to evaluate AppleScript within another process. And at that point you can just, for example, if it’s something related to files, then you can already do that. So if you compromise your EMO or mail.app, then you can already read all of the emails, even though that’s normally protected.

Thijs Alkemade:
But for one of the three attacks that I wanted to do, I needed to do more. So in that case, I had to go a couple of steps further until I was actually able to execute Python within another process. So the application is running, but it’s actually, there’s now a Python runtime loaded into it. And at that point, none of the protections of the hardened runtime did anything anymore. So normally the hardened runtime doesn’t allow you to load libraries by another developer or-

Charles Edge:
Or shell anything out. Yeah.

Thijs Alkemade:
Protections against JITs and stuff like that. But loading Python, that was just fine. And then at that point, I had full control of that process.

Charles Edge:
Yeah. That is another checkbox, like in Xcode when you compile the ability to run just-in-time compile binaries, I guess.

Thijs Alkemade:
Yeah. And there’s something about inside memory, but that also doesn’t affect Python code.

Charles Edge:
Yeah. Wow. That’s wild. Congratulations.

Thijs Alkemade:
Thank you.

Tom Bridge:
Yeah. I was going to say, when you realized that that was entirely possible straight out of the operating system, what was your mental process as you were going through this? What went through your head?

Thijs Alkemade:
So the actual exploit chain sort of parts of it I had already used for another vulnerability that’s not yet fixed. Apple still needs to fix that. I’m hoping it’s going to be fixed in Ventura, but I’m not sure yet. But at the time I was writing that exploit, it was like, I can do a lot of things already, but not quite yet the things that I want to do. But I had to do some really weird stuff, combining objects in very weird ways, loading new frameworks, and then another framework. So it really felt like building some Rube Goldberg machine of different parts of the fire system to get it to work. So in this case, building this exploit was just, yeah, it is quite a mess to look at, but I am very proud that it eventually worked.

Charles Edge:
And it was a pretty crafty exploit. I mean, in a SIP world, do you think that it’s getting harder and harder to find these types of vulnerabilities or just with the sheer amount of code, do you think it will always just be looking for the next unsecured little bit of code that hasn’t been touched since, let’s say, Mountain Lion?

Thijs Alkemade:
I think we are getting better and better, but there’s still many parts of the system that just were written before SIP, before all of those DCC permissions, before all of that stuff. So I think it’s going to be a while before that stuff, really all of those issues are hammered out.

Tom Bridge:
So how did Apple fix this problem? I mean, also, how long between disclosure and actual fix, if you can share that?

Thijs Alkemade:
I reported this in December 2020, I think, and it was fixed at the release of macOS Monterey, so that was October last year. So that’s about 10 months, which is pretty fast for Apple for fixing vulnerabilities in my experience. And the way they fixed it is that… So there’s a bit of an issue that third-party applications may try to store their own objects in that serialized state. So if you have a third-party application like BBEdit, for example, that they may have their own document clause that they want to store in that state. And if that object doesn’t support that secure version of the serialization format, then the vulnerability will still be present.

Thijs Alkemade:
So the way that that’s now fixed is that in all of Apple’s own applications, they just enforced that secure version. But in third-party applications, there’s now a method that you can implement, application delegate, I think something like SupportsSecureRestorableState. If the application returns true, then it’s a new application, a modern application, and then the secure version will be enforced. If that method doesn’t exist or returns no, then the insecure version will be used and then process injection will still be vulnerable in that application with just that specific application. It’s also part of the EXCO template. So if you start a new project, then you will see that this method is actually there. But yeah, so hopefully developers will adopt it at some point.

Charles Edge:
Yeah, I mean I always felt like the ability to have something restored at the end or when a application was terminated was enabled by default because I never put it in there and yet things were restored.

Thijs Alkemade:
Yeah. The framework does a lot for you already, if you don’t do anything else yourself. But if you were good documents-based applications, I think you may run into cases where you do need to implement something yourself. I’ve looked very deeply into that.

Tom Bridge:
What’s it like to work with Apple in processes like this during the disclosure time?

Thijs Alkemade:
You send them an email, and then you don’t hear anything back from them until they are about to release a fix. And then they say, “Well, how do you want to be credited?” And then they release the fix. They don’t say anything about how they fixed it. They don’t say anything about whether they agree with your assessment of the impact, nothing like that. And then many months later they may tell you about a bounty that they assign to it. So it’s really difficult to get any actual response from Apple about these issues in my experience.

Tom Bridge:
I’m fairly sure that every Mac Admin just is nodding in, we’re calling it nodding in feedback assistant. The process of talking with Apple can be a challenge. I certainly am a little sad to hear that for security, it’s not any better.

Thijs Alkemade:
No. Sometimes I try to reproduce the issue on a beta just because I think they might have fixed it, not because they say they’re going to fix it. So sometimes I tell them, “Hey, I noticed that you made these changes in this beta, but they don’t fully address the issue here. You may want to do this and this and this as well,” something like that. And then sometimes you may get some response to that where they respond to what you said, but it’s always very minimal.

Charles Edge:
And is that response from a generic account like securityresponse@apple.com or something like that, or is it from individual developers?

Thijs Alkemade:
It’s productsecurity@apple.com and they’re all signed with a first name that I suppose is probably fake.

Charles Edge:
Yeah, I’ve heard that sometimes. But then you meet someone like Quinn “The Eskimo”, and you’re like, oh wait, you’re real and that’s not a generic.

Tom Bridge:
Yeah. Shout out to Quinn. Quinn is awesome. A question for you though. Is working with Apple any different than working with other vendors? Does Apple approach this in their own unique way or are other vendors just as tight-lipped during the disclosure process?

Thijs Alkemade:
In my experience, but I haven’t reported that many vulnerabilities, but I’ve reported some to Microsoft, some to Adobe, some to Google. They are much more responsive and there’s much interaction between you and some actual developer working on it. I’ve reported something to Google a couple of times. Then usually within a day or two you have a response from somebody who actually knows about that stuff, giving you some actual content of a response. So not just a boiler plate auto reply. But Apple, there’s usually no response at all, which is a bit sad because you end up with issues that get fixed only partially or where we completely forget about the issue, which is quite a shame because it could have been fixed completely. But then because they didn’t communicate, we didn’t know that there was anything that we should check, so we didn’t check. And then, yeah, it becomes a mess.

Tom Bridge:
Yeah. How do you see Apple’s Security Bounty program overall? Is it pretty industry normal? Is it a little bit different than that?

Thijs Alkemade:
I think Apple is, if you compare to Google, then, for example, if you compare iOS to Android, then there is quite a bit of similarity in what they will reward. But Apple is a lot less transparent in how they decide on what to reward. So if you report a vulnerability to Google, then you can assume they will investigate the full impact of what you have reported and then pay you based on that, and they are pretty transparent in how they will pay something.

Thijs Alkemade:
For Apple, first of all, they will only pay you based on the impact that you have actually demonstrated. If you just say, “Well, there’s a vulnerability here,” then they’re not very likely to investigate the full impact themselves. You have to show it to them instead of them checking what the impact will be. So in that sense, I feel they’re a bit unfair about deciding on the bounties. But yeah, if you compare it to many other companies, then even just the fact that they pay out bounties is great compared to many other companies which don’t do that.

Tom Bridge:
Got it.

James Smith:
Deploying, managing and protecting Apple devices at work shouldn’t be difficult to require several solutions. Mosyle is the only Apple Unified Platform for Business. By combining enhanced device management, endpoint security, internet privacy and security, single sign-on and enhanced apps management into a single Apple-only platform, businesses can now easily and automatically deploy, manage and protect their Apple devices with one solution and at an affordable price. With a solution for every business size and the best support in the market, request your free account today and see firsthand why Mosyle is more than an Apple MDM. Mosyle is everything you need to work with Apple. To learn more, visit business.mosyle.com. That’s business.M-O-S-Y-L-E.com.

Charles Edge:
So getting back into the more technical nature, I guess, what is a downgrade attack?

Thijs Alkemade:
A downgrade attack is, for example, where suppose you have an application that is now currently secure against process injections, so all of those hardened runtimes enabled, no exceptions to that. But they had a previous version a couple of releases ago before the hardened runtime even existed maybe, and that didn’t enable that. So what you can do is, if you still have that application and you have malware installed in that machine, you can download that older version, replace one of the libraries, launch that older version, and then you still have all of the permissions that the new version of the application has. Because the way the system keeps track of these permissions is through knowing what company signed that application and the bundle identifier. So because they don’t look at the version, you can just downgrade to an older version and you still have webcam permission or something like that. And that’s-

Charles Edge:
So com.companyname.appname has permission to, as an example, camera as opposed to a hash of the specific version where you checked the box or clicked the button to enable that sandbox permission, I guess for lack of a better-

Thijs Alkemade:
Yeah. And it also needs to be signed by an Apple developer certificate for the same team. But as long as that’s the case, it will have that permission that you gave to it.

Charles Edge:
That’s a really interesting way of circumventing some of this because if you have root access, you can just rename the existing app, plop an older version of the app down, and then try to, for example, use a shared library that you know is susceptible to attack. Is there any way to prevent these?

Thijs Alkemade:
It’s pretty tricky because it’s pretty hard for Apple to compare version numbers of every application that the user might be running, because many of them don’t really have a very logical system in their version numbers.

Charles Edge:
Yeah. The lack of solely sequential version numbers has always been a thing going back… I mean, for Mac Admins, just to package software and keep software up to date, it’s been a constant thing for at least 10 years. Interesting. So this exploit specifically going back to your CVE was initially fixed in 1201 and you were using AppKit, but there are dozens of extensions outside of AppKit to use. I mean, whether you want to talk to a watch or instruments in a car or what have you, what do you think the future of trying process injection or even data flow injection, because the way that these serialized objects kind of move is often up to the developer? Like, if I need to communicate with a watch using cryptographic responses, then I have to use iCloud Keychain. There’s all these weird little buckets in there. I guess, what do you think the future of trying these various forms of process injection will be?

Thijs Alkemade:
Many applications on macOS that need to communicate with other services or also on iPhones use XPC. And there’s a XPC connection clause, and then you’re basically just calling methods on a object in your own process, but they’re actually forwarded to another process. And that serialization of those objects, all of that uses secure coding everywhere. There’s no deserialization vulnerabilities there. Well, there’s no insecure serialization format there. Sometimes you may find a vulnerability there. So there’s this writeup from Google Project Zero about a vulnerability a while ago where they basically allowed any object to be sent over the connection, and then they extended that to basically getting code execution. But those are very rare vulnerabilities. So I think the framework was pretty well designed to avoid this type of vulnerability. I think it’s not that it’s impossible to find, but I think it’s much less likely to run into issues like this when you’re using that framework correctly.

Charles Edge:
Yeah. That makes perfect sense.

Thijs Alkemade:
So unless you have your own way of serializing objects, then you might run into something like that, but I think that’s quite unlikely. If you just use the frameworks that you have, you won’t get an issue like this very easily.

Charles Edge:
And with this being kind of a little bit of a cat and mouse game where new things pop up here and there, is there a more holistic fix architecturally, or are we just a little too far down that road to rethink that?

Thijs Alkemade:
So one thing Apple could do is to enforce the Mac Application Sandbox for every application, and then vulnerabilities like this will be a lot harder to exploit. So there will be much less ways for two different applications to interact with each other. But I also know that that’s not something they’re going to enforce anytime soon, because there’s so many applications that need to do stuff that the sandbox will not allow you to do. So I think, yeah, it’s not likely that they will enforce something like this, and that means that there’s many ways that two different applications can interact. So they might be trying to use the same files, they might expose services to another application. There might be certain resources within the applications that can be modified. So without something like enforcing complete sandboxing, I don’t really see a general fix for this type of vulnerability.

Charles Edge:
I don’t know if the complete sandboxing is so far-fetched, but I guess the future is always unclear, unless you’re Yoda.

Tom Bridge:
I always feel like we always hear tell that it’s possible to completely sandbox everything off. But then I start thinking about how much time I spend getting apps to interact and doing things through individual conduits between applications. And that’s where I start to really struggle with a purely sandboxed environment.

Charles Edge:
Well, you have your URL schemes, you have XPC, I mean, there are so many ways, but every time I see something show up in defaults, I’m like, “Whoa, wait, what just happened?” There’s so many old places to do it too. I do feel like, if you look at the number of apps on the app store, every now and then there’s a big dip, and that’s when Apple enforces some new thing. It’s okay sometimes to lose a few million apps on an app store because if there’s financial motivation to remediate any issues that Apple may have created by removing certain capabilities, then it’ll happen.

Thijs Alkemade:
But at least on macOS, you see so many applications that used to be in the App Store that just give up on being in the App Store and just go back to their own distribution because they cannot work with the sandbox. So I don’t really think there’s a lot of motivation for people to make their applications work well within the sandbox, which also means that the sandbox isn’t… Apple isn’t giving developers the methods that they need to make their own applications work within the sandbox. So the really powerful applications like Photoshop probably has many ways that it needs to communicate with other tools. It probably doesn’t work at all if you put it in the sandbox. But Apple’s probably also not working on making that work within the sandbox very hard because they cannot enforce that yet. That’s what I think, at least.

Charles Edge:
Yeah, you see new libraries, new frameworks show up all the time, but the ability to guess what every single developer’s going to try to think of to do next on your operating system is pretty substantial, especially when not everything is just a database that you’re putting some stuff into and taking some stuff out of, like business automation software. Especially in our fields, whether it’s information security, identity services, you’re doing sometimes pretty bizarre things to make certain components react the way you need them to react, rather than anything that the developer could have thought of. Yeah, I don’t envy developer relations over there. In fact, I would gladly send them lots of crates of wine to say thank you for everything over the years, but I’m pretty sure they wouldn’t allow that.

James Smith:
Here at the Mac Admins Podcast, we want to say a special thank you to all of our Patreon backers. The following people are to be recognized for their incredible generosity. Stu Baka, thank you. Adam Selby, thank you. Nate Walk, thank you. Michael Tsai, thank you. Rick Goody, thank you. Mike Boylan, you know it, thank you. Melvin Vives, thank you. Bill Stites, thank you. Anoush d’Orville, thank you. Jeffrey Compton, M.Marsh, Stu McDonald, Hamlin Krewson, Adam Burg, thank you. A.J. Potrebka, thank you. James Stracey, Tim Perfitt of Twocanoes, thank you. Nate Cinal, Will O’Neal, Seb Nash, the folks at Command Control Power, Stephen Weinstein, Chad Swarthout, Daniel MacLaughlin, Justin Holt, Bill Smith, and Weldon Dodd, thank you all so much. And remember that you can back us if you just head down out to patreon.com/macadmpodcast. Thanks everybody.

Charles Edge:
So, Tom, we have a bonus question today, right?

Tom Bridge:
We do have a bonus question here today, and I think it’s a fun one. And Charles, when I read this one, I was like, “Oh shoot.” Because there’s probably a couple of them that I think I’m going to have to list. So the question is, what app could you not stop using if there was a vulnerability?

Thijs Alkemade:
For work reasons, there’s probably a few applications that I need to use, but many of them have alternatives.

Tom Bridge:
Sure.

Charles Edge:
I can say for me, Slack. Well, actually a couple weeks ago I might have said Slack. Today, I’m maybe not going to say Slack and pouring one out for the poor InfoSec teams working on that one. But, you know-

Tom Bridge:
You want to share what you’re referring to here, Charles, because I feel like… Oh dear.

Charles Edge:
But I would say, living in Minnesota, the weather app in the middle of the winter would be a big one for me.

Tom Bridge:
Yeah, I was going to say CARROT Weather in the wintertime, that’s what I use for my snowfall forecasts. That’s what I use for my storm forecasts here in D.C. It’s a really solid thing. I would say, and it kills me to admit this, but my name is Tom and I’m addicted to Twitter and it has been five minutes since I checked Tweetbot last. And I feel like if Tweetbot were to give up all of my DMs, I might still even use it. That is the answer I’m going to stick with today. I feel like I will not be proud of that. But yeah, I was going to say, that’s my answer and I’m sticking to it.

Charles Edge:
I am very, very, very privileged that my grandfather once said, “Don’t put anything in writing that you don’t want your grandmother to read.”

Tom Bridge:
Amen. Amen.

Charles Edge:
So, if all of my Twitter DMs were leaked, a few might be a little bit unfortunate, but I’d be like, “Sure, that happened.”

Tom Bridge:
Yeah, I mean, I was going to say, it’s not like you would see anything there that would horrify or shock you. It’s just conversations between that were meant for those two people and that’s all. Or you might see my local beer-making plans or beer-having plans, which are often handled in Twitter DMs.

Charles Edge:
Now I would be horrified if anyone saw a rough draft version of any of my books before an editor got ahold of them. That would be horrible.

Tom Bridge:
I was going to say, my talks for all of my conferences while they’re in draft state would certainly be a shame for anybody to see. People might change how they felt about me.

Charles Edge:
Or any of these episodes before James makes everything better.

Tom Bridge:
Amen. Well, Thijss, thank you so much for joining us this week. It was a great pleasure to talk with you. We have linked in the show notes today, the PDF from Black Hat from your talk as well as the CVEs involved, and a few articles there from Charles and other folks. If folks want to find more of your work online, where should they go look?

Thijs Alkemade:
We have a writeup of this vulnerability on our website, which is sector7.computest.nl. You’d scroll back a little bit, because it’s a little bit older now. But yeah, it’s a pretty extensive writeup, though it doesn’t really cover everything yet. There’s some parts in the talk as well that they’re not yet in the writeup. But as I said, there’s still some parts that need to be fixed in Ventura, so that’s going to be later. You can find me on Twitter. Not going to try to pronounce that name, but just search for me and you’ll find me there.

Tom Bridge:
We’ll make sure that that ends up in the show notes as well, because, yes, I found your Twitter handle and I was like, yep, not going to be able to say that one. That one’s a little weird. I don’t know where the emphasis goes. But yeah.

Tom Bridge:
Thanks so much to our amazing sponsors this week. That is Kandji, our friends at Black Glove, and our friends at Mosyle Business. Of course, our wonderful transcription sponsor, which is Meter, which will let you read this episode as well as listen to it. And we thank them all for their assistance. Last but not least, we could not do this without all of our wonderful Patreon backers. So thank you so much to them as well. And with that, I will say thanks everybody. We’ll see you next time.

Charles Edge:
See you next time. Bye.

James Smith:
The Mac Admins Podcast is a production of Mac Admins Podcast, LLC. Our producer is Tom Bridge. Our sound editor and mixing engineer is James Smith. Our theme music was produced by Adam Kudiga, the first time he opened Garage Band. Sponsorship for the Mac Admins Podcast is provided by the macadmins.org Slack, where you can join thousands of Mac Admins in a free Slack instance. Visit macadmins.org. And also by Technolutionary, LLC, technically we can help. For more information about this podcast and other broadcasts like it, please visit podcast.macadmins.org. Since we’ve converted this podcast to APFS, the funny metadata joke is at the end.