Get root on macOS 13.0.1 the macOS Dirty Cow bug

https://worthdoingbadly.com/macdirtycow/

by todsacerdoti • 4 years ago

183 71 4 years ago

worthdoingbadly.com

MaxLeiter• 4 years ago

The project zero bug linked in the post (which I recommend reading first) has more details on the exploit

https://bugs.chromium.org/p/project-zero/issues/detail?id=23...

MichaelZuo• 4 years ago

"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?

waynecochran5• 4 years ago

As root the machine is yours to do what you will -- as I have unfortunately learned the hard way many many moons ago.

anyfoo5• 4 years ago

Not on iOS or macOS (unless SIP is disabled), no.

forgotmypw17• 4 years ago

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.

count• 4 years ago

Many, many macOS devices are not 'your own' devices, and have access to many development backends and infrastructures.

TheRealPomax5• 4 years ago

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.

fathyb• 4 years ago

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.

jackson1442• 4 years ago

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.

mritun• 4 years ago

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.

gjsman-1000• 4 years ago

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.

akerl_• 4 years ago

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.

TheRealPomax5• 4 years ago

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"

lucb1e2• 4 years ago

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.

waynecochran5• 4 years ago

It doesn't have to be your machine -- imagine this is a Mac in a lab or a cloud machine.

andix3• 4 years ago

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.

e40• 4 years ago

Is a rootkit possible with SIP turned on? Seems like that’s what it is designed to prevent.

reaperducer• 4 years ago

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!"

TillE• 4 years ago

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.

adra• 4 years ago

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

spookthesunset2• 4 years ago

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…)

jeffbee• 4 years ago

Why can't C programmers stop themselves from writing something like:

  size = (unsigned)(expression);

? The contradiction is stark. If a variable deserves the name `size` it deserves the type `size_t` as well.

TheRealPomax5• 4 years ago

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.

duped2• 4 years ago

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.

TapamN• 4 years ago

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.

  size_t v;  //64-bit size_t
  v = (unsigned)0xff00000001;
  printf("%zu\n", v);  //Prints 1

I don't get any warnings for this on GCC 9.4 or Clang 15.0.4 with Wall+Wextra.

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;

andix3• 4 years ago

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++.

mlindner• 4 years ago

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.

acdha2• 4 years ago

That's both scary and entirely believable with the number of CVEs they have due to 90s-style coding practices.

tedunangst• 4 years ago

Well, it's not a size, it's a page count.

astrange3• 4 years ago

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.

pjmlp4• 4 years ago

Because only the others are bad C programmers.

loeg• 4 years ago

"Dirty Cow" is a reference to the similar Linux COW bug CVE-2016-5195: https://en.wikipedia.org/wiki/Dirty_COW .

musicale• 4 years ago

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...

super_mario• 4 years ago

macOS Catalina 10.15.7 is also affected and there is no official patch from Apple.

Get root on macOS 13.0.1 the macOS Dirty Cow bug

Related Stories