Welcome to our deep dive. Today. We're going to be looking at something that's both fascinating and a little bit unnerving, the security of Apple's operating systems.
And to guide us through this intricate landscape, we've got Jonathan Levin's book OS Internal's Volume three, Security and Insecurity. This book is like a masterclass in how Apple builds those defenses, and equally important, how those defenses have been tested, challenged, and sometimes even broken.
It's like getting a backstage pass to the world of digital security, a peak behind the curtain to see how the wizards at Apple try to keep our Max and iPhones safe exactly.
And what Levin does so brilliantly is he takes us through both sides of the story, the security and the insecurity. It's not just about how things are supposed to work, it's about how they can be made to work differently, sometimes with unintended consequences.
Okay, so let's start unpacking all of this. Where do you think we should begin. What's the foundation of all of the security stuff.
Well, like any good fortress, it all starts with authentication. How your device knows it's really you trying to get.
In right, So beyond the usual username and password. What's going on behind the scenes.
You'd think it's just a simple check but Apple actually uses a multi layered approach that goes beyond those traditional methods. Think of it like a series of checkpoints, each with its own set of guards and protocols.
Okay, I'm intrigued. Walk me through these checkpoints.
So you have the familiar login screen, But behind that, there's a process called open direct read, which uses a Skellite database to manage user configurations.
And data hold on scale. That's a pretty standard database format, isn't it the kind that anyone with a little know how can access.
That's the interesting part. This database isn't locked away in some impenetrable vault. With the right tools and knowledge, you can actually pick inside and see what's going on. You can even manipulate certain user properties.
Wait, are you saying that just by accessing this database, someone could potentially tinker with user accounts.
Potentially. Yes, It's important to note that there are likely other security measures in place to prevent unauthorized modifications, but the fact that this database is relatively accessible highlights a key concept in security. It's all about layers.
Like an Onion feel back one layer and there's another one underneath exactly.
No single mechanism is fool proof. Security relies on a combination of interlocking defenses, each providing a different level of protection.
Okay, so we've got this squarelight database managing user info. What else is involved in this multi layered authentication system.
Well, in addition to those traditional mechanisms, Apple also introduce something called the Local Authentication Framework.
What's the purpose of that? Is it like a more advanced form of authentication.
You could say that it's designed to provide a standardized and secure way for developers to build authentication features into their apps. I think touch, id, face, ID, those kinds of things.
Ah, So it's about streamlining the process for both developers and users while also making it more secure.
Right, and it aims to create a more concert experience across all Apple devices. So whether you're using your iPhone, your iPad, or your Mac, the authentication process feels familiar and reliable.
That makes sense. So we've got this multi layered system in place to verify our identity. What happens once we're in How does the system keep track of what we're doing, especially from a security standpoint?
That's where auditing comes in. Think of it as a digital trail of breadcrumbs that records security related events on your Mac.
So every time something important happens, like accessing a protected file or changing a system setting, it gets logged.
Exactly. It's like having a security camera that's always watching, but instead of video footage, it records a log of actions and events. This information can be invaluable for forensic analysis if there's ever a security breach.
That makes sense, like being able to retrace your steps if something goes wrong. But how does the system decide what to audit in the first place. It can't possibly log everything we do, right.
That's where another key player enters the scene. KATHUUF, Apple's kernel level authorization system KAUF.
Never heard of it. What's its role in all of this?
KUF is one of those behind the scenes mechanisms that most users never interact with directly, but it plays a crucial role in deciding which actions are allowed and which ones aren't. Think of it like a security checkpoint within the core of the operating system.
So it's like a bouncer at a club deciding who gets in and who stays out.
That's a good analogy. But instead of looking at IDs, CAUTH uses something called scopes to define areas of interest for authorization scopes.
Okay, now you're losing me. What exactly is a scope in this context?
Imagine you have different security zones within a building. Some areas are open to everyone, while others require special clearance to enter. Scopes in CAUTH work in a similar way. They define different categories of actions or resources that require authorization.
So different scopes for different levels of sensitivity. Can you give me a concrete example?
Absolutely? One example is the coth scope of generic scope, which covers a wide range of actions. Then you have more specific scopes like cost co process, which focuses specifically on actions related to processes like launching a new app or terminating an existing one.
Interesting. So each scope is like a specific security domain with its own set of rules and permissions.
Precisely, and here's where it gets really clever. Whenever an action falls under a particular scope, coth triggers a corresponding callback function.
A callback function, what does that do?
Think of it like an alarm that goes off when something specific happens. In this case, the alarm triggers a piece of code that checks whether the action is allowed based on predefined rules and policies.
So it's like having a security guard stationed at each checkpoint who checks your credentials before letting.
You through, exactly, And it's all happening at the kernel level, which is the heart of the operating system. This means that COTH has a very low level and fundamental role in enforcing security.
So code is like the gatekeeper, checking credentials and making decisions. But where do those credentials come from in the first place? Are we still talking about user names and passwords?
Actually, this is where things get even more interesting. COTH uses its own system of credentials that are distinct from traditional POSXX credentials, which are the ones associated with usernames and passwords.
Wait, different credentials. Why would they do that? Isn't that making things unnecessarily complicated?
It might seem that way at first, but there's a good reason for this separation. It ties into Apple's Mandatory Access Control MAAC framework, which is another crucial layer of security that will dive into in a moment.
Okay, I'm starting to see how all of these pieces are connected. It's like a chain reaction. One security mechanism leading.
To the next exactly, and MAAC relies on these KUTH credentials to enforce its security policies. So understanding how cualth works is essential for grapping the bigger picture of how Apple secures its operating systems.
All right, you've peaked my curiosity. Let's talk about this MAAC framework. What is it and how does it fit into this whole security puzzle.
Think of MSS as the judge and jury in the court of your operating system. It's responsible for evaluating whether an action should be permitted based on a system of labels and policies, and it's deeply integrated with the kernel, which means it's very difficult to bypass or tamper.
With labels and policies. This sounds very official. Can you break it down for me?
Sure, every object in the system, whether it's a file, a process, or even a network socket, can be tagged with an a mass label. Think of it like a security clearance level for digital objects.
So some files might be marked as top secret while others are public exactly.
And then you have policies, which are essentially rules that determine how objects with different labels can interact.
So a top secret file can't be accessed by someone with a public clearance level.
You got it. It's all about controlling access based on these labels and policies, ensuring that sensitive information and resources are protected from unauthorized access.
This is fascinating. It's like a whole security ecosystem operating beneath the surface of our max. Now, the book also mentioned something called texts in relation to M SICK. What are those?
Texts? Are kernel extensions. They're basically little pieces of code that extend the kernel's functionality, and some texts are dependent on MAC for their operation.
Meaning they rely on MAS for security checks and enforcement.
That's right. The book even shows you how to use a simple command line tool to identify these MAC dependent texts. It's a good example of how Levin provides not just theoretical knowledge, but also practical insights into how these mechanisms work.
That's really cool. So we've covered authentication, auditing, COTH, and MA. It seems like we're building up a pretty solid understanding of Apple's security layers. What's next on our journey.
Let's talk about code signing, Apple's way of guaranteeing the integrity and origin of executable code. Think of it like a digital signature that verifies the authenticity of an app or software.
So it's how Apple ensures the apps were downloading and running are legitimate and haven't been tampered with, like a seal of approval.
Exactly, every piece of software that runs on mac os and iOS has a code signature attached to it. This signature is cryptographically generated, which means it's very difficult to forge.
Okay, but what does this signature actually look like? How does it work on a technical level?
Well, get ready to dive a bit deeper, because it involves something called the superblob.
Superblob sounds a bit intimidating.
Don't worry, it's not as scary as it sounds. It's basically a container that holds various pieces of information, including the actual signature itself, which is based on something called CMS Cryptographic Message syntax. And then there are these special slots within the superblob for storing additional metadata metadata.
What kind of information are we talking about here?
This is where things get really interesting. These special slots can contain things like entitlements, which we'll discuss later, but for now, just know that they add an extra layer of control over what an app can do.
Okay, entitlements sound intreating, But first, tell me more about this superblob. Can we actually see it? Can we examine its contents?
Absolutely? The book walks you through how to extract and inspect code signatures using the command line tools. You can actually see the structure of the superblob in its different components.
So we can peek under the hood and see how this digital signature is constructed. Very cool. What else is important about these code signatures?
They also include flags that influence how the code can be executed. These flags control things like whether the code can be debugged or injected into other processes, So another way Apple tries to limit what malicious actors can do.
So it's not just about verifying the integrity of the code itself, it's also about controlling how that code behaves once it's running on the system. Another layer of security.
You've got it. It's all about making it as difficult as possible for attackers to exploit vulnerabilities and compromise the system.
Well, it seems like Apple has put a lot of thought and effort into securing its operating systems. We've only just scratched the surface, and I'm already impressed by the complexity and depth of these security mechanisms, and.
We've only just begun. There's much more to explore in the world of Apple security, so stay tuned for more insights as we continue our deep dive.
Welcome back. It's amazing to think about all the security measures working behind the scenes every time we use our Apple devices. It's like having a whole team of digital bodyguards protecting us from unseen threats.
And like any good security team, they've got multiple layers of defense. It's not just about keeping the bad guys out, it's also about limiting the damage they can do if they manage to slip through the cracks.
Okay, that makes sense. So what kind of damage control measures are we talking about here? What else does Apple have up its sleeve?
Well, let's talk about software restrictions, specifically, how even Apple's own apps have limits on what they can do.
Wait a minute, even Apple's apps. I thought they had free rein of the system.
Not quite. Even Apple recognizes that some operations are just too sensitive to allow unrestricted access.
Like, what kind of things are we talking about?
Think about accessing your keychain, where all your passwords and sensitive data are stored, or modifying critical system files. Those are actions that shouldn't be taken lightly.
Right, That makes sense. You don't want just any app messing around with that kind of stuff. So how does macOS keep things in check?
It uses something called the authorizations mechanism, which relies on you guessed it, another Scoli database.
Cerusly, another Scualae database. They seem to be everywhere.
They're just really good at what they do. This particular database stores rules that is, termine which operations require special authorization and under what conditions that authorization can be granted.
So it's like a set of bylaws for apps, defining what they can and can't do exactly.
And what's really interesting is that you can actually examine this authorization database yourself using the command line.
Wait, you mean we can see the actual rules that govern what apps can do?
You can. The book even gives examples of how to extract specific rules from the database using this quad three tool. It's a fascinating way to see how these restrictions are implemented.
I can see how that would be useful for developers and security researchers. But is there any risk in making this information accessible. Could someone with bad intentions manipulate these rules?
It's definitely a possibility, although Apple has implemented various safeguards to make it more difficult. But it highlights the constant cat and mouse game between security and those who seek to circumvent it.
Right, because if you can change the rules of the game, you can potentially change the outcome exactly.
And that brings us to another important player in Apple's security lineup, Gatekeepers.
Gatekeepers is that like a bouncer for apps, checking IDs at the door.
You could say that it's Apple's first line of defense against untrusted software. When you download an application from the Internet, Gatekeeper steps in to verify its credentials.
Credentials, so is it looking for a code signature like we talked about earlier, that's.
A big part of it. If an app isn't signed by a trusted developer, Gatekeepers will raise a red flag and prevent you from running it without explicit confirmation.
I've definitely seen those warnings pop up before, especially when I try to run something I've downloaded from a less and reputable source.
That's exactly when Gatekeeper is doing its job, protecting you from potentially a harmful software. But you might be wondering how Gatekeeper knows that a file was downloaded from the Internet in the first place.
Yeah, how does it tell the difference between something I downloaded and something that's always been on my computer?
It uses a clever trick called quarantine attributes. When you download a file, the system automatically tags it with these attributes, marking it as potentially untrusted.
So it's like a little sticky note that says handle.
With care exactly. And what's really interesting is that you can actually manipulate these quarantine attributes yourself using the zatri command line tool.
Hold on, are you saying I could potentially remove these attributes and trick Gatekeepers into thinking a downloaded file is safe.
It's possible, but Apple has implemented additional measures to make it more difficult. For example, Keeper's also checks for a special extended attribute called comm dot apple dot quarantine, which stores more detailed information about the file's origin.
So even if you remove the basic quarantine attributes, there's still this extra layer of information that could trip you up exactly.
Apple clearly thought about this and built in some redundancy to make it harder for attackers to circumvent gatekeepers.
Speaking of redundancy, the book mentions something called lib quarantine and a rather oddly named system demon called SIPOILCID. What do those have to do with gatekeeper good catch?
Lib quarantine is basically the toolbox for managing these quarantine attributes. It provides the functions that apps can use to interact with these flags.
So it's the behind the scenes worker bee that makes the whole quarantine system tick. And what about sipoil sid.
That's the enforcer. Sipoil said, is a system demon that runs in the background and constantly monitors for new files and downloads.
So it's like a digital security guard patrolling the system, making sure nothing suspicious gets through exactly.
It works in conjunction with other components like the kernel and the authorization database to enforce gatekeepers policies.
Wow, it's amazing how much is going on behava scenes to keep our macs safe from harm. But I'm sensing a theme here. Apple seems to really like this layered approach to security.
You're absolutely right, it's all about defense and depth. Yeah, no single mechanism is perfect, so they combine multiple layers to make it as difficult as possible for attackers to exploit any weaknesses.
And that brings us to what might be the most important layer of all sandboxing.
Ah. Yes, sandboxing. It's one of Apple's most powerful security mechanisms and a cornerstone of both mac os and iOS.
I've heard the term before, but I'm not exactly sure what it means. Can you break it down for me?
Think of sandboxing like a playpen for apps. Instead of letting an app have free rein of the system, it confines it to a specific area with limited permissions.
So even if an app is militia or compromised, sandboxing prevents it from doing too much damage.
That's the idea. It's like containing a potentially dangerous experiment to a controlled environment.
Okay, I'm starting to see how this fits into the layered security model, But how does sandboxing actually work? What's the magic behind it?
The magic, or rather the technology behind it, is AMAC the mandatory Access control framework we discussed earlier. Each sandboxed app is given a set of Mac labels and policies that define what it's allowed to do.
AH. So it's back to those labels and policies, but this time they're being used to restrict what an app can do, rather than just controlling access to files.
Exactly, and the sandboxes evolved significantly over the years. In the early days, it used a blacklist approach.
Blacklist meaning they had a list of specific things that apps weren't allowed to do and everything else was permitted.
You got it. But this approach proved to be too limiting and difficult to maintain. As the threat landscape changed, Apple realized they needed a more flexible and robut.
So they switched to a whitelist approach.
Precisely, instead of focusing on what apps can't do, they shifted to defining what apps can do. This means everything is forbidden by default unless explicitly allowed by the sandbox rules.
That sounds much more secure, but I imagine it also makes things more complicated for developers.
It does, but it's a trade off worth making for the increased security and to make things easier for developers, Apple introduced sandbox profiles.
Sandbox profiles what are those?
They're essentially configuration files that define the allowed actions for a specific app.
So instead of having to manually specify every single permission, developers can just use a predefined profile that matches their apps needs.
Exactly, and you can actually inspect these profiles. The book gives examples of how to use a command line tool called ASTI to do just that.
Ask TI another cryptogachronym, I take it.
It stands for Apple Sandbox command Line Interface. It's a powerful tool for developers and security researchers.
Alike can peek into these profiles and see exactly what an app is allowed to do.
You can and you can even modify those permissions for testing purposes, although as always, we strongly advise against making any unauthorized changes to your system.
Right We don't want to accidentally unleash any digital monsters. But it's fascinating to see how much control and transparency Apple provides with its sandboxing system.
It really is a testament to their commitment to security, and it's one of the key reasons why macOS and iOS are considered to be among the most secure operating systems out there.
Okay, so we've covered code signing, authorizations, gatekeepers, and now sandboxing all working together to protect our devices. Are we finally done with our tour of Apple's security measures.
Quite There's one more big one we need to talk about. System Integrity Protection, or SIP for short SIP.
Okay, I'm all ears, what's that all about?
This is a relatively new addition to Apple's security arsenal, introduced in MACOSL CAPITAM. It adds an extra layer of protection for critical system file and processes.
So even if an attacker manages to gain root access, SIP prevents them from wreaking havoc on the most sensitive parts of the system.
You got it. SIP restricts root privileges in several ways. It prevents modification of certain system directories, limits the loading of unsigned kernel extensions, and restricts debugging of certain processes.
Wow. So it's like putting those critical system components under lock and key, even from the most powerful using.
Exactly and it's made a huge difference in terms of knack out security. But as with any security mechanism, attackers have been trying to find ways to bypass it.
That's what I was going to ask. Is SIP truly unbreakable or have there been cases where attackers have managed to circumvent it?
Well, no security system is truly unbreakable, but SIP has significantly raised the bar for attackers. They've tried different approaches like exploiting vulnerabilities in other parts of the system to gain control before SIP can kick in.
So it's like trying to sneak past the guards before they can lock down the fortress exactly.
And they've also tried targeting sip's own configuration and enforcement mechanisms, looking for subtle flaws or loopholes.
So even though SIP is a powerful defense, it's still a target for attackers. It's a reminder that security is an ongoing arms race, a constant battle between those who build walls and those who try to tear them down.
Well said, and that's one of the key insights from os Internal's Volume three. It doesn't just tell you how things work, it also shows you how those things can be broken, and more importantly, what can be done to make them stronger.
It's like a crash course in both offense and defense in the world of cybersecurity exactly.
And understanding both sides is essential for staying ahead in this constantly evolving landscape.
Welcome back, Deep Divers. We've spent the last two parts of this episode building up a pretty solid understanding of how Apple tries to keep our Max and iPhones safe. Now it's time to flip the script and explore the other side of the coin, the insecurity part of the equation.
Because as as robust as Apple security measures are, they've always faced challenges from those who seek to break them, bend them, or just plane bypass them.
It's like that old saying, every lock has its key, or in this case, every digital fortress has its potential weakness, right.
And that's where OS Internal's Volume three really shines. It doesn't shy away from the vulnerabilities and exploits that have targeted Apples operating systems.
So we're talking about specific instances where those layers of security we discuss were breached or circumvented exactly.
And it starts with some classic MAGOS vulnerabilities that existed in versions ten point two and ten point one to one, things like issues with specific system calls, exploits that took advantage of race conditions, and even clever tricks involving path manipulation.
Okay, I'm getting a little loss in the technical jargon here. Can you break it down for me? What kind of impact could these vulnerabilities have?
Imagine an attacker being able to execute arbitrary code on your system? Essentially gaining control of your machine. That's the kind of power these vulnerabilities could potentially grant.
That sounds pretty serious. So these weren't just minor glitches. They were potentially major security holes, right.
And what's fascinating is the variety of these vulnerabilities. They highlight the fact that security weaknesses can crop up in unexpected places, even in seemingly simple functions or operations.
It's like a reminder that attackers are always looking for those chinks in the armor, no matter how small they might seem.
Exactly, and that's why understanding these vulnerabilities is so important. It helps us see how attackers think and how they exploit. Even the smallest oversights are inconsistencies encode.
So it's not just about knowing what the vulnerabilities are, it's about understanding how they came to be in the first place. Right.
It's about seeing the bigger picture and recognizing the patterns that often lead to security weaknesses.
Okay, if that makes sense now. The book also delves into the world of jail breaking, which is something that's been a constant cat and mouse game between Apple and a certain segment of its users.
Absolutely, jail breaking is all about removing the restrictions that Apple places on iOS devices, essentially giving users more control over their devices.
So it's like saying, Hey, Apple, I appreciate the security, but I want to be able to do whatever I want with my own phone.
You could say that, and os Internal's Volume three provides a fascinating history of iOS jail breaks, starting with the very first one for the original iPhone all the way up to more recent exploits.
It's like a timeline of how hackers and security researchers have been pushing the boundaries of what's possible with iOS devices.
Right, and each jail break is a testament to the creativity and persistence of those who seek to understand and sometimes circumvent Apple's security measures.
Can you give me an example of a particularly clever or memorable jailbreak exploit?
Well, there was Evasin, a jail break for iOS six that took advantage of vulnerability in the way iOS handled.
PDF files BF files. Really that seems like a strange place to find a security hole.
It does, but that's the ingenuity of these exploits. Ye Evasian used a carefully crafted PDF document that, when opened, would trigger a chain of events that ultimately led to a jail break.
So it's like a trojan horse disguised as something harmless exactly.
And then there was Pangu, a jail break for iOS seven that targeted a vulnerability and a core system component called Apple key store.
And what did that allow attackers to do?
Pangu was a very powerful exploit that gave jail breakers almost complete control over the device. It was a major breakthrough in the jailbreak community.
Wow, these exploits sound incredibly complex. It must take a deep understanding of iOS internals to pull something like that off.
It does, and the book goes into detail about the technical intricacies of these exploits, showing how they leverage vulnerabilities bypassed security checks and ultimately achieved their goal.
It's like a masterclass in hacking, but from a defensive perspective exactly.
By understanding how these exploits work, we can learn how to better protect against them.
Okay, so we've talked about classic macOS vulnerabilities and iOS jail breaks. What other kinds of exploits does the book cover?
Well? It goes into some specific attacks like Yalu, which exploited a kernel memory management vulnerability in iOS ten, and then there's asinc Wake, which affected versions eleven point zero to eleven point one point two of iOS.
So it's a pretty comprehensive look at the history of iOS security research, both from the perspective of those who seek to protect the system and those who seek to find its weaknesses.
It is, and it's important to note that the book doesn't just focus on the exploits themselves. It also delves into the tools and techniques need to discover and analyze these vulnerabilities.
It's like a toolkit for security researchers and those who want to understand how these attacks work exactly.
Gives you a glimpse into the world of security research and the mindset of those who are constantly probing and testing the limits of digital security.
It sounds like an invaluable resource for anyone interested in cybersecurity, whether you're on the offensive or defensive side.
It really is. And one thing that stood out to me was the emphasis on understanding the why behind these vulnerabilities and exploits.
What do you mean by that?
It's not enough to just know how an exploit works. You need to understand the underlying design decisions or coding practices that made the vulnerability possible in the first place.
Hum, So it's about going beyond the symptoms and understanding the root cause of.
The problem exactly, because only by understanding the why can we hope to prevent similar vulnerabilities from appearing in the future.
That makes a lot of sense. So as we wrap up this deep dive into OS Internals Volume three, what are some key takeaways for our listeners?
Well, first and foremost, it's a reminder that security is an ongoing process, a constant evolution. There's no such thing as a perfectly secure system, and there will always be those who seek to find and exploit weaknesses.
It's a cat and mouse game, a constant back and forth between defenders and attackers.
Right, And that's why it's so important to stay informed, to keep learning, and to adapt to the ever changing threat landscape.
So it needs to be proactive, not reactive when it comes to security exactly.
We can't just wait for vulnerabilities to be discovered and exploits to be developed. We need to be constantly thinking about security, both as individuals and as a society.
And books like this one can play a valuable role in that process.
Absolutely, they provide the knowledge and insights. We need to understand the complexities of digital security and to make informed decisions about how to protect ourselves and our data.
Well said, so to our listeners, we encourage you to delve into OS Internal's Volume three yourself and explore the fascinating world of Apple security and insecurity.
It's a journey that will challenge your assumptions, expand your knowledge, and ultimately make you a more informed and security conscious user.
Thanks for joining us on this deep dive. We hope you've enjoyed the exploration and that you'll continue to be curious, to question and to learn. Until next time, Stay safe out there in the digital world.