Hacker News Reader

Comment by anyfoo | Hacker News Reader

Note that if SIP is enabled (the default), "root access" does not mean full compromise. On macOS, root is far from being as privileged as it was in the old days of UNIX yore. (Even on Linux it does not have to be, but my impression is that on most distributions it probably still is.)

Just because you're root does not mean you get any entitlement you want, or arbitrary access to the whole filesystem, arbitrary memory access (a la /dev/(k)mem), or can replace the kernel just like that.

(That's also probably why you don't hear of iPhones being "rooted", but rather "jailbroken". Just being root on an iPhone wouldn't do that much.)

Make no mistake, this is still a privilege escalation attack and needs to be fixed.

View on HN

I read your first 8 words and was momentarily confused because I thought you were referring to https://en.wikipedia.org/wiki/Session_Initiation_Protocol , and can indeed join Zoom meetings with a standard SIP client, but it's an optional paid feature --- nonetheless likely to be available in a corporate environment. Look for the IP address to dial in meeting invites to see if you have that option.

SIP is System Integrity Protection

https://en.m.wikipedia.org/wiki/System_Integrity_Protection

I don’t need root access.. just your .ssh dir

Good luck bypassing my CGNAT ;)

Well.. with ipv6, there’s no need to nat anymore

Though you should keep your private keys protected by a pass phrase.

Top tip for people that use 1Password: I’ve discovered recently that you can run it as an ssh agent. That way your keys never leave the 1password app.

Either you're forced to type in your password 100 times a day (so the rootkit has to wait until you type it in) or you use ssh-agent and your decrypted key is in memory for all to see.

Indeed. Use the Mac’s Secure Enclave [1] or a Yubikey, preferably with Touch ID or touch confirmation on a YK.

https://github.com/maxgoedjen/secretive

Judging by the downvotes, my suggestion isn't great, though it does seem a tiny bit better.

I was under the impression that 1password uses secure enclave on the Mac and that it only decrypts the key as it's needed. I guess depending on the implementation the decrypted key could be in memory for a moment - or maybe longer.

The GP said they just need access to your .ssh directory (not root access, no mention of a root kit). A pass phrase on the key is a valid mitigation for that level of access.

You don’t need to type it, you can store it in a password manager and copy/paste, which is pretty fast. I do it all the time, it’s not a big deal.

Ok fair, but IMO there are few threat models where that would make a difference. In practice the attacker can just edit your bashrc and alias ssh-agent to log the password. Same for the password manager. Btw user mode rootkits are a thing and they typically don't need root despite the name.

If attacker code can run under your user, you're kinda screwed.

This would be just a minor speed bump if the adversary has control of the user account.

And I’d though everyone else also kept their gpg and ssh keys on Yubikeys[1].

[1]: https://github.com/drduh/YubiKey-Guide

Or in the Secure Enclave on Macs.

https://github.com/maxgoedjen/secretive

I don’t store them on it but I do require it to use it.

I keep my subkeys on my YubiKey and my master key on a printed QR code in a safe. Submitted some binary data decoding patches to ZBar just to make this easier.

You’re going to need my U2F key too.

You still need some way to be able to manage the system and have unrestricted access to admin stuff. Moving the problem to some other place doesn't really solve it

Well if that other place is having to have the device in physical possession, and having to enter the admin password in person, before you can e.g. replace the kernel or critical system libraries...

https://help.apple.com/pdf/security/en_US/apple-platform-sec...

Tried `rm -rd /` as root on a Mac once. I didn’t expect it to boot just fine after :)

So what DID happen after? :)

Well, in recent Mac systems '/' is read only so nothing will happen.

Can't SIP just be turned off by using root?

No - you need to boot the system into the recovery mode so you would need the exploit to be working in that mode.

Reply on news.ycombinator.com