Get root on macOS 13.0.1 the macOS Dirty Cow bug(worthdoingbadly.com)
worthdoingbadly.com
Get root on macOS 13.0.1 the macOS Dirty Cow bug
https://worthdoingbadly.com/macdirtycow/
7 comments
"Will this be useful for jailbreak?
Probably not.
This - as far as I can tell - affects userspace processes only. Jailbreaks require a kernel exploit. (The Apple Security release notes says that this bug may allow “arbitrary code with kernel privileges”, but I can’t see how.)
You might still do something cool on iOS with this, but I’m not sure what you’d overwrite: codesigning should protect all executables and libraries. (I have not tested this: let me know if you find anything!)"
Looks like system integrity protection? or some other mechanism preventing this?
This - as far as I can tell - affects userspace processes only. Jailbreaks require a kernel exploit. (The Apple Security release notes says that this bug may allow “arbitrary code with kernel privileges”, but I can’t see how.)
You might still do something cool on iOS with this, but I’m not sure what you’d overwrite: codesigning should protect all executables and libraries. (I have not tested this: let me know if you find anything!)"
Looks like system integrity protection? or some other mechanism preventing this?
As root the machine is yours to do what you will -- as I have unfortunately learned the hard way many many moons ago.
Not on iOS or macOS (unless SIP is disabled), no.
Can't you disable SIP as root? What can't you do as root? You could replace the kernel. I guess I am use to the Linux world where I build kernels and install as root.
With SIP you can only reboot the machine into recovery mode, but the user would then have to go into the recovery mode terminal and run `csrutil disable` to disable SIP.
You can't disable SIP on a live system and you can't automate actions in recovery mode.
You can't disable SIP on a live system and you can't automate actions in recovery mode.
You cannot do these with all security enabled, no. There are lots of other things that are prevented by SIP and/or Secure Boot. One of the principles is that being root should not mean that the kernel can be readily attacked without further bugs.
That also means no /dev/kmem etc., and on top of that POSIX file permissions are by far not the only thing that is protecting access to the file system.
If you want to go down the rabbit hole: https://help.apple.com/pdf/security/en_US/apple-platform-sec...
That also means no /dev/kmem etc., and on top of that POSIX file permissions are by far not the only thing that is protecting access to the file system.
If you want to go down the rabbit hole: https://help.apple.com/pdf/security/en_US/apple-platform-sec...
That is a deep hole. I see there is a chain of certificates of trust for fine grain control to all the system parts beginning with the boot sequence. A lot more complicated than Unix systems of yore.
Apple goes through a lot of effort to keep control of the system out of their customer's hands.
SIP really helps protect people from themselves, and it’s easily disabled for those who need it (but it’s definitely a red flag).
A couple years ago many edit houses in LA suddenly had boot issues because a Chrome update was over writing system files when the updater was run with elevated privileges.
The issue was that these studios used Avid which required disabling sip at the time.
Other houses that didn’t disable sip were unaffected because it protects against exactly this kind of scenario.
A couple years ago many edit houses in LA suddenly had boot issues because a Chrome update was over writing system files when the updater was run with elevated privileges.
The issue was that these studios used Avid which required disabling sip at the time.
Other houses that didn’t disable sip were unaffected because it protects against exactly this kind of scenario.
I don't want to be protected from myself. As the admin I should have full access to the stuff I buy.
Disabling it is ok but the problem with that is that you lose all security. There should be a way to add our own signing keys to persist changes to the SSV (Signed System Volume) and SIP protected folders. It shouldn't be trust only Apple or nothing.
Disabling it is ok but the problem with that is that you lose all security. There should be a way to add our own signing keys to persist changes to the SSV (Signed System Volume) and SIP protected folders. It shouldn't be trust only Apple or nothing.
This is not for you, rather for the kind of people that get Ask Jeeves installed when clicking on popups while browsing the Web.
They shouldn't have the same rights? Just because someone is less technologically aware today, you think it's OK to start stripping away their rights? That's like saying poor people shouldn't be allowed to own a house because they won't be able to afford the maintenance.
The more accurate version of your analogy is that they can choose to do their maintenance, they just won’t be covered by insurance (their own or that of a tradesman) if something goes wrong.
That is actually how it is in reality, and maps very well to as analogies to the two levels of SIP.
That is actually how it is in reality, and maps very well to as analogies to the two levels of SIP.
Many insurances don't cover house repairs if not done by companies specialised on the repair domain....
You do have full access to what you buy. While it would be nice to both have full access AND the security, that’s still not denying you full access.
The new cryptex mechanism could be used to allow persistent modifications to the SSV (that's how it's done on the iOS Security Research Devices), but no idea if Apple will actually implement that.
It's a delicate balance because Apple has to support a lot of people and at this point there are literally decades of experience showing that many people, including administrators and developers, will make mistakes or bad decisions due to social engineering or simply greed (how many people installed malware because they thought it was cheaper than paying $20 for a software license?).
SIP is a good compromise: it prevents malware from gaining completely control of the system but someone with physical access and administrator privileges can disable it for the few situations where that's desirable. That's not a high bar when you need it but it probably has a 100000:1 ratio of time preventing someone's day from getting worse to actually preventing legitimate work.
SIP is a good compromise: it prevents malware from gaining completely control of the system but someone with physical access and administrator privileges can disable it for the few situations where that's desirable. That's not a high bar when you need it but it probably has a 100000:1 ratio of time preventing someone's day from getting worse to actually preventing legitimate work.
Linux and the BSDs really should have a more restricted default desktop capability model compared to macOS by now. It's a shame that Qubes is the main response we have, not because it's bad, but because it's almost necessary.
You shouldn’t run a web browser on any system with less security than this.
(It doesn’t have nearly enough security yet, but it’s much more advanced than Linux. And strangely also OpenBSD, who like defending against imaginary attackers doing imaginary attacks instead of their real weak points.)
(It doesn’t have nearly enough security yet, but it’s much more advanced than Linux. And strangely also OpenBSD, who like defending against imaginary attackers doing imaginary attacks instead of their real weak points.)
securelevel [1] is a similar feature from/for FreeBSD. As an example, it could be used to build e.g. a true append-only syslog server which even root would not be able to manipulate the data without a reboot or, in combination with other techniques like a capiscum-sandboxed tcpdump implementation, highly secure network appliance.. plenty of use-cases.
[1] https://www.freebsd.org/cgi/man.cgi?query=securelevel&apropo...
[1] https://www.freebsd.org/cgi/man.cgi?query=securelevel&apropo...
Then it's not root...
SIP is another system that exists besides POSIX and the root user. With SIP enabled, let me demonstrate:
SIP also protects other things like your apple messages DB located at `~/Library/Messages/chat.db` . Even the root user, if running from a non-privileged origin process, can't read that file:
chris@chriscomp /usr/bin # sudo su root
root@chriscomp /usr/bin # touch testo
touch: testo: Operation not permitted
SIP also protects other things like your apple messages DB located at `~/Library/Messages/chat.db` . Even the root user, if running from a non-privileged origin process, can't read that file:
root@chriscomp / # cat /Users/chris/Library/Messages/chat.db
cat: /Users/chris/Library/Messages/chat.db: Operation not permitted
root is essentially a POSIX concept, and from a POSIX perspective this is still root, it’s just that the POSIX security model is by far not the only thing in play here.
When Apple introduced SIP, they marketed it as “Rootless”.
OK ... so w MacOS there is a user w more power than root? There has to be some entity that can ultimately install a new kernel and subsystem.
There could be code in the system that directs IO and only allows write requests to parts of the OS if they include a signature from Apple.
I'm not sure if "a user with more power than root" would be the right way to describe that. The code would have a permission that "root" doesn't, but I wouldn't call the code "a user". It's a Unix idea that "a specific set of permissions" and "a user" are synonyms. Systems can exist where some permissions aren't represented as users.
I'm not sure if "a user with more power than root" would be the right way to describe that. The code would have a permission that "root" doesn't, but I wouldn't call the code "a user". It's a Unix idea that "a specific set of permissions" and "a user" are synonyms. Systems can exist where some permissions aren't represented as users.
No, there is no more powerful user, it’s just that the root user no longer has arbitrary control - it means that if an attacker compromises a root owned process the attacker can’t turn around and control the kernel.
The kernel has a number of things it can do: if you try to do a special thing it could force authentication itself - eg a “root”/admin user can still do the action, but a process with “root privileges” cannot, it can require the process attempting the action have correct entitlements, it can simply reject the operation entirely, etc. it can do all of the above: I recall there being some operations that can only be performed by specific apps, with specific entitlements, as special users, with immediate authentication (startup items and the like)
The kernel has a number of things it can do: if you try to do a special thing it could force authentication itself - eg a “root”/admin user can still do the action, but a process with “root privileges” cannot, it can require the process attempting the action have correct entitlements, it can simply reject the operation entirely, etc. it can do all of the above: I recall there being some operations that can only be performed by specific apps, with specific entitlements, as special users, with immediate authentication (startup items and the like)
It’s more that there is far more protecting the system (and also e.g. data from different apps against each other, or things like access to your screen content), than the current user. Some of this is because we’re in a world where Macs and iPhones are far more likely to be single user machines than the UNIX machines of lore. See the PDF in my other answer.
How crazy is it that getting root on your own device is an accomplishment?
Edit: I didn't realize this post is about a privilege escalation exploit, not about getting root on your own device necessarily. My point still stands though.
Edit: I didn't realize this post is about a privilege escalation exploit, not about getting root on your own device necessarily. My point still stands though.
For a random bit of code that's running on your machine? zero day levels of crazy: that should never be possible, and you should update your macos if you haven't yet.
This is not about "you being able to become root", of course you can do that whenever you want, with authentication. This is a random bit of code that compiles to something that goes "cute, let me just get root access without any passwords or user noficiations. Tadah, I can do whatever I want on this system now"
This is not about "you being able to become root", of course you can do that whenever you want, with authentication. This is a random bit of code that compiles to something that goes "cute, let me just get root access without any passwords or user noficiations. Tadah, I can do whatever I want on this system now"
> This is not about "you being able to become root", of course you can do that whenever you want
"of course", yeah...
Tell that to iOS and most Android users (even among techies, 95% is afraid of the steps you have to take for getting root on your own damn phone). This used to be normal but for our own good it has been decided that this is not normal now anymore. That kids are growing up with this worries me. When is the market ready for Microsoft and Apple to decide the same for desktops? Not running the DRM and trying to WINE some application is going to be similarly thwarted as doing banking on a phone that the user fully owns is today.
"of course", yeah...
Tell that to iOS and most Android users (even among techies, 95% is afraid of the steps you have to take for getting root on your own damn phone). This used to be normal but for our own good it has been decided that this is not normal now anymore. That kids are growing up with this worries me. When is the market ready for Microsoft and Apple to decide the same for desktops? Not running the DRM and trying to WINE some application is going to be similarly thwarted as doing banking on a phone that the user fully owns is today.
I wonder how dangerous it really is to have root access on your phone? How many people got real damage by rooting their phone for their own usages?
All people just say it's dangerous however I cannot find data or user reports of people who got hurt badly by rooting their phone and a malicious app was exploiting this attack vector (wonder how big of a deal this niche attack vector is anyway). Sure some people shoot in their own foot with root but that's the danger of root anyway.
All people just say it's dangerous however I cannot find data or user reports of people who got hurt badly by rooting their phone and a malicious app was exploiting this attack vector (wonder how big of a deal this niche attack vector is anyway). Sure some people shoot in their own foot with root but that's the danger of root anyway.
How are personal gripes about phone operating systems even remotely related to the factual matter of being able to su/sudo whenever you want on a desktop operating system?
Just pointing out that what you take for granted today is being removed from newer systems (which additionally relates to the thread as a whole since it uses an alternative way to get ownership over the software running on the device), so maybe it's not such an 'of course' anymore in the way you said :(
Sorry that I wasted your time with my, eh, "personal gripes"
Sorry that I wasted your time with my, eh, "personal gripes"
We've had smartphones without superuser rights for checks notes literally forever. There hasn't been a single mass market phone ever created that required you to run anything as root. Yeah, we can jailbreak phones, but until the law busts up the "app store" model, phones don't need root. General computing devices might, and you might want to turn your phone into one of those, but as the device it's sold as, no phone has ever needed you to have access to, or use. , root privileges.
Because they're not designed to be computers (yet). Operating systems for desktop have given you the power to superuser-up since day one, to this day, and the odds of that changing any time soon is pretty much zero, because without superuser privileges we can't use those computers for what they're intended to be used for.
So yeah, personal gripes: they are wildly and completely different types of devices, for different markets.
Because they're not designed to be computers (yet). Operating systems for desktop have given you the power to superuser-up since day one, to this day, and the odds of that changing any time soon is pretty much zero, because without superuser privileges we can't use those computers for what they're intended to be used for.
So yeah, personal gripes: they are wildly and completely different types of devices, for different markets.
The alternative is the internet would be vastly more saturated with botnets and the accompanying fraudulent they are used for.
I totally get what you are saying though. But kids these day can have way more impact than the bad old days of C64 command line basic. It’s just at a different level of abstraction. And people who want to tinker with the bowels of a device can always run Linux or one of the many microcontrollers on the market. A $5 ESP32 can do way, way more cool shit than my old commodore computer.
I totally get what you are saying though. But kids these day can have way more impact than the bad old days of C64 command line basic. It’s just at a different level of abstraction. And people who want to tinker with the bowels of a device can always run Linux or one of the many microcontrollers on the market. A $5 ESP32 can do way, way more cool shit than my old commodore computer.
[deleted]
The vulnerability isn’t that the person who owns the machine can get root. Your user on a personal Mac is, by default, an Administrator, and can just sudo to root.
The “accomplishment” is that somebody who can execute code on your laptop (say, somebody who notices you forgot to lock your laptop at Starbucks, or a malicious app developer, or somebody who compromises the update server for an app you use) can escalate to root.
The “accomplishment” is that somebody who can execute code on your laptop (say, somebody who notices you forgot to lock your laptop at Starbucks, or a malicious app developer, or somebody who compromises the update server for an app you use) can escalate to root.
How crazy is it that getting root on your own device is an accomplishment?
We're not living in Commodore 64 days anymore.
The vast majority of people have to be protected from themselves, or they'd all be following online instructions to delete files in Win32 to free up space.
On HN, people know what they're doing, but for some reason complain as if every person on the planet has the same level of technical knowledge they do. They don't. People on HN like to moan about not being able to hack stuff because they think it gives them street cred. It doesn't.
HN: "This product is awful! It has no security!"
Also HN: "This product is awful! Its has security!"
We're not living in Commodore 64 days anymore.
The vast majority of people have to be protected from themselves, or they'd all be following online instructions to delete files in Win32 to free up space.
On HN, people know what they're doing, but for some reason complain as if every person on the planet has the same level of technical knowledge they do. They don't. People on HN like to moan about not being able to hack stuff because they think it gives them street cred. It doesn't.
HN: "This product is awful! It has no security!"
Also HN: "This product is awful! Its has security!"
It is as it always was an attitude of trust and defaults. You can get locked down bootloaders that only load windows and specifically signed Linux distros. This is totally fine for the 99%, but still most bios allow you to drop into non-secureboot if you choose. They've given the trust that you're going to do so responsibly. No random is going to do this for lols. It's largely for enthusiasts and non-institutional professionals building their stacks.
This is the have your cake and eat it too. Android has its "dev" mode, and most android phones allow for bootloader unlocks. Giving people to option to explicitly drop the security for their own reasons is great as long as the default is " idiot proof". Who's complaining about this model? Nobody
This is the have your cake and eat it too. Android has its "dev" mode, and most android phones allow for bootloader unlocks. Giving people to option to explicitly drop the security for their own reasons is great as long as the default is " idiot proof". Who's complaining about this model? Nobody
And honestly there are way cooler “raw hardware” things out there now that you can tinker with. ESP32 or even an Arduino can run circles around a C64 as far things you can do… (at least I can think of… who knows what my life would be like growing up around $5 microcontrollers with easy to use IO and whatnot…)
Indeed, plenty of power, ESP32 even has more juice than a PC 1512, and we got plenty of games and other stuff on them.
Right, the hard question is how do you prevent the spread of trojan horses which use basic social engineering?
It's not difficult to get people to run a sketchy program and type their password into any old prompt. You need layers upon layers of security to mitigate this.
It's not difficult to get people to run a sketchy program and type their password into any old prompt. You need layers upon layers of security to mitigate this.
it's privilege escalation, the script is not being run as sudo
also you can enable root by going to Directory Utility -> (unlock) -> Edit -> Enable Root User. Haven't found a need for this though.
also you can enable root by going to Directory Utility -> (unlock) -> Edit -> Enable Root User. Haven't found a need for this though.
It depends. Privilege escalation can allow rootkits to install themselves. To get a really severe exploit you usually need to combine a remote code execution with a privilege escalation. So this would only be one part.
But you never know if somebody already has another zero day exploit in their pocket and waits for such an opportunity. Some bugs are there for years before they are found. This doesn’t mean that nobody found them before. It only means that nobody used them in a way that it got detected.
But you never know if somebody already has another zero day exploit in their pocket and waits for such an opportunity. Some bugs are there for years before they are found. This doesn’t mean that nobody found them before. It only means that nobody used them in a way that it got detected.
Is a rootkit possible with SIP turned on? Seems like that’s what it is designed to prevent.
[deleted]
This is a privilege escalation exploit, it gets a root shell from a non-root process. You can get root privileges on macOS using su/sudo.
It doesn't have to be your machine -- imagine this is a Mac in a lab or a cloud machine.
Many, many macOS devices are not 'your own' devices, and have access to many development backends and infrastructures.
That has nothing to do with this. Everyone can become root on their mac by typing their password. This exploit shows that you you can compile a bit of code that can then bypass that and run anything it wants with full root permissions.
In most cases, yes, but that's not what the parent meant. In managed environments, it's common to not have root login access, and local privilege escalation is sometimes more critical than normal.
Only if you have admin permissions. If you don’t have them, you need to type in the password of an admin to become root.
Flamebait?
If you know the password you can enter it when ‘su’ asks. This vulnerability allows all processes, even untrusted one, to gain root privileges- which is a problem if that is not what you intend.
MacOS is actually less locked down than a Linux server built by even a half competent sysadmin.
If you know the password you can enter it when ‘su’ asks. This vulnerability allows all processes, even untrusted one, to gain root privileges- which is a problem if that is not what you intend.
MacOS is actually less locked down than a Linux server built by even a half competent sysadmin.
> MacOS is actually less locked down than a Linux server built by even a half competent sysadmin.
In no way is this true. Linux servers built by half-competent sysadmins don't have System Integrity Protection, read-only boot images with digital signatures, or even proper secure boot.
In no way is this true. Linux servers built by half-competent sysadmins don't have System Integrity Protection, read-only boot images with digital signatures, or even proper secure boot.
Or any of the ARM hardware security features like PAC.
Why can't C programmers stop themselves from writing something like:
size = (unsigned)(expression);
Every time I use C it feels like working on wiring without popping the breaker.
A LOT of code just shouldn’t be C or C++.
A LOT of code just shouldn’t be C or C++.
> If a variable deserves the name `size` it deserves the type `size_t` as well.
That would be a mistake since size_t is poorly designed - it’s unsigned and you should use signed integer types whenever possible in C, as the Google C++ style guide says.
This is more secure because UBSan is more likely to find bugs using it. Bit unfortunate the STL doesn’t like you doing it.
That would be a mistake since size_t is poorly designed - it’s unsigned and you should use signed integer types whenever possible in C, as the Google C++ style guide says.
This is more secure because UBSan is more likely to find bugs using it. Bit unfortunate the STL doesn’t like you doing it.
At F5 while I was there it was explicit coding practice to never use size_t, "because it wastes bytes". If you used size_t it'd get caught in code review and you'd be asked to remove it.
That's both scary and entirely believable with the number of CVEs they have due to 90s-style coding practices.
Well, it's not a size, it's a page count.
Because only the others are bad C programmers.
I think the real question is "if this is so bad, why does the language allow it". Because asking why people use the language in a way it was designed for has the obvious "because they can, and the language allows them to" as answer.
There's nothing fundamentally bad about the code above. It's a smell but could make sense.
Like for example if I'm writing an interpreter that runs on devices with limited memory size_t might be bigger than I need for the length of a buffer in user code, and using a shorter integer might be a useful optimization.
This is really an example where you have a sharp tool and need training/oversight/experience to use it safely. And even with those things, mistakes happen. The same is true of power tools as memory unsafe systems code.
Like for example if I'm writing an interpreter that runs on devices with limited memory size_t might be bigger than I need for the length of a buffer in user code, and using a shorter integer might be a useful optimization.
This is really an example where you have a sharp tool and need training/oversight/experience to use it safely. And even with those things, mistakes happen. The same is true of power tools as memory unsafe systems code.
Many things "could make sense", but often do not in the common case.
Your optimization is a good example for something where jumping through explicit hoops would not only be palpable, but even help signify the intent of your code optimization, while protecting common code from nasty surprises.
Otherwise, we could also go back to earlier C days and, for example, let the compiler be silent about assigning a pointer of the wrong type without an explicit cast. That makes sense a lot of times, but still I want the compiler to tell me that I passed a struct foo* where a struct bar* was needed, or worse, a struct foo**.
Your optimization is a good example for something where jumping through explicit hoops would not only be palpable, but even help signify the intent of your code optimization, while protecting common code from nasty surprises.
Otherwise, we could also go back to earlier C days and, for example, let the compiler be silent about assigning a pointer of the wrong type without an explicit cast. That makes sense a lot of times, but still I want the compiler to tell me that I passed a struct foo* where a struct bar* was needed, or worse, a struct foo**.
It blew my mind (in a bad way) when i went from CodeWarrior to GCC, and suddenly basic pointer typechecking was a minor warning that you had to enable instead of a hard compile error that was on all the time. My takeaway was that Unix people were lax because they didn’t have to worry about corrupting system data structures like we did on classic MacOS, AmigaOS, Windows pre-NT, etc.
Sure, but I think a lint to warn you that a variable named "size" should be size_t is complete overkill.
What I'd rather see are better lints and a better culture around them instead of the cowboy attitude you see in a lot of systems code. Today, lints for C are pretty bad and the default attitude isn't to fix warnings but to disable them when compiling the software. Even worse is when distro maintainers patch the sketchy code instead of the 1p devs doing it right from the beginning.
It doesn't matter what your warnings are if the attitude is to ignore them. And in this case, there are several warnings that would tell you the code smells and needs attention.
What I'd rather see are better lints and a better culture around them instead of the cowboy attitude you see in a lot of systems code. Today, lints for C are pretty bad and the default attitude isn't to fix warnings but to disable them when compiling the software. Even worse is when distro maintainers patch the sketchy code instead of the 1p devs doing it right from the beginning.
It doesn't matter what your warnings are if the attitude is to ignore them. And in this case, there are several warnings that would tell you the code smells and needs attention.
That really seems like something that should generate warning, when a value assigned to a size_t was cast to a type smaller than size_t from a value that was as >= size_t.
If you wanted to deliberately do that kind of cast, for some reason, you could prevent the warning like this:
size_t v; //64-bit size_t
v = (unsigned)0xff00000001;
printf("%zu\n", v); //Prints 1
If you wanted to deliberately do that kind of cast, for some reason, you could prevent the warning like this:
v = (size_t)(unsigned)0xff00000001;"Dirty Cow" is a reference to the similar Linux COW bug CVE-2016-5195: https://en.wikipedia.org/wiki/Dirty_COW .
> Apple for the test case[1] and patch. (I didn’t change anything: I just added the command line parameter to control what to overwrite.)
Nice of Apple to provide the exploit code. ;-)
[1] https://github.com/apple-oss-distributions/xnu/blob/xnu-8792...
Nice of Apple to provide the exploit code. ;-)
[1] https://github.com/apple-oss-distributions/xnu/blob/xnu-8792...
macOS Catalina 10.15.7 is also affected and there is no official patch from Apple.
https://bugs.chromium.org/p/project-zero/issues/detail?id=23...