"Oooh, boy, this is a doozy"
November 29, 2017 2:58 PM   Subscribe

There is a major security issue with macOS High Sierra. "We always see malware trying to escalate privileges and get root access," says Patrick Wardle, a security researcher with Synack. "This is best, easiest way ever to get root, and Apple has handed it to them on a silver platter."
posted by capnsue (63 comments total) 19 users marked this as a favorite
 
This was patched this morning, with a message to "install as soon as possible". Unusually, it didn't even need a reboot of the system.
posted by mephron at 3:03 PM on November 29, 2017 [5 favorites]


"You can log in as root without a password" is not so much a "major security issue" as a joke from an 80's movie. I can't comprehend how this happened.
posted by The Bellman at 3:04 PM on November 29, 2017 [23 favorites]


ROOT
posted by Fizz at 3:04 PM on November 29, 2017 [3 favorites]


Now what.
posted by Fizz at 3:04 PM on November 29, 2017 [5 favorites]


There was a security update released this morning to fix it. You can install it from Software Update in the App Store in about 30 seconds.
posted by zachlipton at 3:05 PM on November 29, 2017 [2 favorites]


>>This was patched this morning, with a message to "install as soon as possible". Unusually, it didn't even need a reboot of the system.

That's because the patch is an automatic (non-optional) update. Only the second time apple has done this.
posted by jeremias at 3:05 PM on November 29, 2017 [4 favorites]


What was the first time?
posted by holmesian at 3:10 PM on November 29, 2017 [1 favorite]


If your mac has already been compromised by this criminally negligent imbecillic abomination, isn't this bolting the stable door etc? Once someone's got root they can install backdoors etc....
posted by lalochezia at 3:11 PM on November 29, 2017 [2 favorites]


this would have been really scary if i ever left my laptop unattended

i suppose a hacker / cat burglar could have broken into my apartment and owned my Macbook Pro while I slept last night
posted by entropicamericana at 3:15 PM on November 29, 2017 [3 favorites]


What was the first time?

An NTP issue.
posted by Nonsteroidal Anti-Inflammatory Drug at 3:16 PM on November 29, 2017 [5 favorites]


"What's your password?"
""
"That's the stupidest password I've ever heard in my life! That's the kind of combination an idiot would have on his luggage!"
posted by East Manitoba Regional Junior Kabaddi Champion '94 at 3:17 PM on November 29, 2017 [4 favorites]




this would have been really scary if i ever left my laptop unattended

i suppose a hacker / cat burglar could have broken into my apartment and owned my Macbook Pro while I slept last night


Uh, that's not how malware works.
posted by Panthalassa at 3:19 PM on November 29, 2017


everything i've seen indicates that the exploit required physical access, but please, prove me wrong.
posted by entropicamericana at 3:21 PM on November 29, 2017 [3 favorites]


It's literally right there in the article:

Malware designed to exploit the trick could also fully install itself deep within the computer, no password required.
posted by Panthalassa at 3:23 PM on November 29, 2017 [1 favorite]


I can't comprehend how this happened.

The login code mis-interpreted a return value as "true" instead of as an error code.

The analysis in the article linked there is very good and comprehensive.
posted by GuyZero at 3:26 PM on November 29, 2017 [14 favorites]


my reading of it is that once root is obtained by physical access, then one can install malware; in which case, duh.
posted by entropicamericana at 3:27 PM on November 29, 2017 [1 favorite]


Also, Twitter guy did the worst vulnerability disclosure of all time with this, but it was actually reported two weeks ago.
posted by GuyZero at 3:30 PM on November 29, 2017 [3 favorites]


Not sure how you arrived at that reading. From the article, with emphasis mine:

The fact that the attack could be used on a logged-out account raises the possibility that someone with physical access could exploit it just as easily as malware
posted by Panthalassa at 3:34 PM on November 29, 2017 [1 favorite]


Apparently it could be exploited remotely if you had Remote Desktop enabled and accessible to the Internet, but... You don't, right? Also, if you heard about the bug and decided to try it out, you'd have enabled the root account with an empty password, so theoretically you could be vulnerable if you had Internet-accessible SSH and had for some reason changed the SSH config to allow empty passwords and root login, but that's even less likely.
It's literally right there in the article:

Malware designed to exploit the trick could also fully install itself deep within the computer, no password required.
If malware finds another way to get running on your system, it could have used this vulnerability to escalate from your limited account to root privileges. That doesn't mean this could be used to remotely install malware; it would need another vulnerability to do that.

Honestly, this bug is pretty hilarious, but I think it's getting more coverage than it merits just because it's so simple to explain. Privilege elevation bugs are extremely common, and any such flaw is as much of a malware risk as this one. The biggest worry here is that because it's so simple, it could have been used by less technically proficient users to gain access to Macs they have physical access to and invade the owner's privacy. From a malware/network security perspective, this is utterly commonplace.
posted by skymt at 3:38 PM on November 29, 2017 [4 favorites]


Also, if you heard about the bug and decided to try it out, you'd have enabled the root account with an empty password, so theoretically you could be vulnerable if you had Internet-accessible SSH and had for some reason changed the SSH config to allow empty passwords and root login, but that's even less likely.

Apparently the patch re-sets the root account to disabled.
posted by GuyZero at 3:39 PM on November 29, 2017


If your mac has already been compromised by this criminally negligent imbecillic abomination, isn't this bolting the stable door etc?

The exploit only works if the "root" user did not have a password set. So if the hypothetical attacker had already changed the password for "root" to a non-empty value, the unpatched exploit would not have allowed a legitimate user to reclaim the system.
posted by tobascodagama at 3:39 PM on November 29, 2017 [1 favorite]


The exploit only works if the "root" user did not have a password set.

But this is like 99.99% of Macs out there.
posted by GuyZero at 3:40 PM on November 29, 2017 [1 favorite]


Shall we go to Ars Technica, folks?

Whatever the case, he agreed with Wardle that the flaw likely represents a major privilege-escalation vulnerability that can be exploited easily by malware developers.

"If they're using API (programming interface) calls, it's a matter of writing the appropriate code," Serper told Ars. "An attacker should be able to trigger it."

posted by Panthalassa at 3:42 PM on November 29, 2017


I never thought I'd be quite this happy about the slow pace at which new releases are certified for use at my company. This bug is specific to High Sierra, and there's precisely two High Sierra systems here, both of which are only for certification testing. Remediation of this particular vulnerability was super easy.
posted by curiousgene at 3:45 PM on November 29, 2017 [1 favorite]


Back during undergrad in 1996 or something, I somehow convinced the computing services dept at my large NJ university that I was competent enough to become a "student sysadmin" or "studsys." This allowed me to have root access to a couple (non-essential) unix (mostly solaris) systems.

They didn't actually give out the root password, instead they used something called "slide" which was some sort of (shell?) program that only users in a certain group could use (there was even 2-factor authentication! a little calculator-thingy that gave me an 8 digit number to append to my password.) It was basically "sudo bash" (or sudo whatever-shell)

One day early in my career i was "slid" (meaning root) on some machine I had access to, and realized i needed to log into the main student server to check my email or something. from my xterm window i typed "ssh whatever.university.edu" and waited for the password prompt.

instead, i got this:
# _

HOLY SHIT. the main student unix machine (that EVERY student logged into to get their email and stuff) didn't have a root password set. at all. since i was effectively "root" on the machine i ssh-ed from, it tried to log me in as root on the main student machine, and IT WORKED. without a password.

That's NOT supposed to happen.

I immediately told my boss (who was, now that i realize it, just couple years older) and his jaw hit the floor and said something like "oh shit, you're gonna get in TROUBLE"

i was like "how am i the first person to have ever done this?!?!"

he was like "you should have used ssh -l !! everyone knows that!!"

I don't remember what happened but I didn't get in trouble, they "fixed the glitch" pretty quickly, and i was glad that i'd resisted the temptation to, i dunno, delete my ex boyfriend's account or something. (actually i was way too terrified to do anything of the sort.)
posted by capnsue at 3:55 PM on November 29, 2017 [43 favorites]


Yes, Panthalassa, this flaw could have been exploited by malware. Malware that was already running on a victim's High Sierra Mac could have used this to elevate from the user's account to root privileges, giving it a greater degree of control over the system. That doesn't at all imply that the flaw could have been used to remotely install malware onto the victim's Mac in the first place. That would require a vulnerability that allows remote code execution, a far less common and more serious class of bug. The only danger from remote attackers with this bug alone was in combination with Internet-exposed remote login systems like Remote Desktop, which a tiny minority of users have enabled.
posted by skymt at 3:56 PM on November 29, 2017 [1 favorite]


Sure, skymt, I'm just responding to entropicamericana's initial assertion that exploiting this bug required physical access.
posted by Panthalassa at 3:58 PM on November 29, 2017


Indeed, as you point out, if there was malware designed to take advantage of this bug on our learned friend entropicamericana's Mac while they were running High Sierra, their Mac could indeed have been owned while they slept last night, hacking catburglar in the apartment or not.
posted by Panthalassa at 4:02 PM on November 29, 2017


Ah, sorry, I misread your posts! I've just seen quite a few people online today who thought this could have let a hacker just log into any Mac in the world and install spyware, so I jumped the gun on that explanation. Sorry!
posted by skymt at 4:04 PM on November 29, 2017


he was like "you should have used ssh -l !! everyone knows that!!"

Sheesh, some excuse. That's like trying to justify not repairing a huge gaping hole through the server room wall by yelling at anyone who uses it instead of the keycard-secured door to enter the room.
posted by Greg_Ace at 4:06 PM on November 29, 2017 [7 favorites]


No problem, skymt! I found your comments interesting and informative anyway haha
posted by Panthalassa at 4:10 PM on November 29, 2017


Summary to-date:

The automatic patch will be applied to any 10.13.1 system that goes online for any reason, without user consent and without a reboot. This is totally excellent and is something like 12 hours overnight turnaround from "notified" to "patch auto-applies to any internet-connected device", which is pretty awesome for a chemspill.

However.

It also appears to break file sharing for many users the instant it's applied, so if y'all are library-types supporting others and they suddenly have issues, that's very unfortunate. It's safe to say that Apple won't leave file sharing broken for very long, but as a FYI.
posted by crysflame at 4:25 PM on November 29, 2017


The analysis in the article linked there is very good and comprehensive.

Yes, thank you. I didn't mean I don't understand the bug, I mean I don't understand how it got by Apple's security QC, which is usually very good.

But whatever, feel free to snark. I love a good Snark. As long as it's not a Boojum (you see).
posted by The Bellman at 4:26 PM on November 29, 2017 [2 favorites]


But this is like 99.99% of Macs out there.

Yes, I know. See the second sentence of my comment for appropriate context on the first sentence. See also the sentence that I quoted because I was replying to it.
posted by tobascodagama at 4:27 PM on November 29, 2017


I AM Groot
posted by TrinsicWS at 4:30 PM on November 29, 2017 [2 favorites]


hades beat me to it. It sounds exactly like what happened with one of our production FreeBSD systems and a Solaris system that we used for a continuing education UNIX admin class. The instructor had sudo access on the FreeBSD system (for reasons I've never quite understood), and put a hosts.equiv in place that allowed the students to have root access via ssh from the lab system to the production system.

This tells you something, I would imagine, about the quality of his administration class.
posted by curiousgene at 4:37 PM on November 29, 2017 [6 favorites]


The login code mis-interpreted a return value as "true" instead of as an error code.

Don't they do unit testing at Apple? Certainly, logic which interprets return values from processes and determines whether to grant access should be unit-tested to within an inch of its life.
posted by acb at 4:40 PM on November 29, 2017


ps. They posted a filesharing fix:

sudo /usr/libexec/configureLocalKDC

HT208317 (apple.com)
posted by crysflame at 4:45 PM on November 29, 2017 [1 favorite]


This is why I never upgrade the OS until the IT group forces me to. My Macbook has never rebooted cleanly anyway so I avoid doing any upgrades.
posted by octothorpe at 5:17 PM on November 29, 2017 [1 favorite]


my reading of it is that once root is obtained by physical access, then one can install malware; in which case, duh.

It works great over VNC or ARD as well. Which, if you happen to operate a fleet of these things, elevates it from a cute if embarassing physical-access timesaver to a five-alarm fire.

One tragedy here is that there's no bug bounty program for MacOS, which means no incentive to responsibly disclose apart from, y'know, being responsible.
posted by mhoye at 5:59 PM on November 29, 2017 [2 favorites]


I always really enjoy these computer-related FPPs, even though I never understand the details. I don’t know what that says about me. But, anyway, thanks for posting!
posted by Don.Kinsayder at 6:21 PM on November 29, 2017 [1 favorite]


Don't they do unit testing at Apple? Certainly, logic which interprets return values from processes and determines whether to grant access should be unit-tested to within an inch of its life.


Sure, but the danger of unit testing has always been that you have to make sure you cover every scenario, and people are bad at that.

I suspect there is NOW a unit test for this....
posted by thefoxgod at 7:33 PM on November 29, 2017 [2 favorites]


(Like, someone may have said "I'll make a unit test for a correct value, an incorrect value, and NULL", but forgot to test empty string, or something like that. Very common).
posted by thefoxgod at 7:34 PM on November 29, 2017 [2 favorites]


hosts.equiv in place that allowed the students to have root access via ssh

Nerdy point of order: hosts.equiv is for rlogin, but I like the crustiness if your jib.
posted by Ogre Lawless at 7:39 PM on November 29, 2017 [8 favorites]


My MacBook is downloading High Sierra as I type. Guess this is my comeuppance for complaining about how long it’s taking.
posted by space_cookie at 9:26 PM on November 29, 2017 [1 favorite]


This vulnerability reminds of an old joke we hackers used to tell about the -froot bug: "It's easier to hack root on an AIX than it is to change directories in VAX/VMS."
posted by xyzzy at 9:26 PM on November 29, 2017 [4 favorites]


I upgraded to High Sierra just last week. Thought it was long enough that the bugs would have been worked out... maybe I was almost right?

Anyhow does the file sharing fix apply automatically too, or do I have to restart for it?
posted by nat at 2:02 AM on November 30, 2017


I mean I don't understand how it got by Apple's security QC, which is usually very good.

Usually very good? This is the crew who just exposed FileVault passwords in clear text in the UI, and whose fix for this particular issue caused a regression that killed filesharing (which wasn't caught).

People inside Apple say that they did at one time have decent QA, but a number of internal changes (not least the massive merger of mac/iOS teams) have crippled that.
posted by bonaldi at 3:56 AM on November 30, 2017 [3 favorites]


I tried the exploit on my own machine yesterday morning after a friend shared the Register's article about it. After trying 5 times to get the escalation to work, I got bored and closed System Preferences. Then I spent a minute re-reading the Register article, got paranoid, and tried it again. After 2 attempts, the escalation worked.

To be clear, I tried it a little bit, got bored and went away, then went back and clicked twice.

This is not deep, obscure, black-hat magic.

This is literally how a 12-year-old would try to hack into your computer right after you left the room to go to the toilet.

If Apple are prepared to fuck up my security so egregiously, they need to - I dunno - pay their fucking taxes, maybe.
posted by prismatic7 at 4:10 AM on November 30, 2017 [7 favorites]


Yes. Do that most recent update immediately.
posted by mhoye at 5:04 AM on November 30, 2017 [1 favorite]


> I didn't do the last tiny update they sent out tho.

The emergency auto-update without user intervention is only happening on 10.13.1 systems, apparently - if you're on 10.13.0, update at once!

(Appple Menu -> About this Mac -> Version if you need to check.)

nat: does the file sharing fix apply automatically too, or do I have to restart for it?

I believe running the Terminal command
sudo /usr/libexec/configureLocalKDC
is all that's required.

But I'm still hanging out with Sierra (10.12.6) - in the past I've only upgraded at .3 releases or later, but this time I really wanted to update earlier. Guess I'll wait till .2 at least, at this point.
posted by RedOrGreen at 6:50 AM on November 30, 2017 [1 favorite]


Nice idea, the penalty for every OS-level remote exploit should be that you have to repatriate $1bn in offshore assets.
posted by benzenedream at 10:21 AM on November 30, 2017 [7 favorites]


Oh sure, they release the rest of the JFK files, and now this! Coincidence?!?

I_think_not.gif
posted by petebest at 2:21 PM on November 30, 2017


"If they're using API (programming interface) calls, it's a matter of writing the appropriate code," Serper told Ars. "An attacker should be able to trigger it."

$ osascript -e 'do shell script "id" with administrator privileges user name "root" password ""'

uid=0(root) gid=0(wheel) egid=20(staff) groups=0(wheel)
posted by scalefree at 4:05 PM on November 30, 2017 [1 favorite]


It works great over VNC or ARD as well. Which, if you happen to operate a fleet of these things, elevates it from a cute if embarassing physical-access timesaver to a five-alarm fire.

Saw a Shodan screenshot right after the story broke that showed 100,000 Macs potentially vulnerable to this over VNC & another 85,000 over ARD.
posted by scalefree at 4:16 PM on November 30, 2017


And you can find it with nmap now.
posted by scalefree at 12:02 AM on December 1, 2017


Update: Well, fantastic.

It looks like the latest update to the OS - 10.13.1 - _undoes_ the fix installed by the quickly released previous patch, which is a fair bit less than great. So you should be 100% sure you've set a strong root password for yourself whatever your current update situation is.

Siri play yakety sax.
posted by mhoye at 9:27 AM on December 2, 2017 [2 favorites]


The latest alleged OS X security fun:
I open my MBP, type the session password, hit return, nothing happen. I realize that the password field is not focused, I click on it, type the pass again and it works. The focus was on the Slack window behind, I just sent my session pass to my whole team
via HN
posted by Nonsteroidal Anti-Inflammatory Drug at 9:59 AM on December 8, 2017 [2 favorites]


I have had that exact scenario happen to me on older OSX versions. Thankfully, I noticed before hitting enter.
posted by tobascodagama at 10:59 AM on December 8, 2017


I've been holding off on the High Sierra upgrade. I am guessing I should continue to wait?
posted by tavella at 11:39 AM on December 8, 2017


I open my MBP, type the session password, hit return, nothing happen. I realize that the password field is not focused, I click on it, type the pass again and it works. The focus was on the Slack window behind, I just sent my session pass to my whole team

WHAAAAT!? WHAT WHAT WHAT?!?

Yeah, no strings, inputs or commands should be going anywhere but the damn lock application. Cripes, how many people leave a shell open and just lock their screen when they walk away? How many people leave open a shell to a remote production server as SU and lock their screen to preserve the shell session?

This stinks of bad programming and not some weird error that creeped in from compatibility issues. The login/lock should be a top level security issue. It's like they didn't even bother to consider controlling the focus or gapping the session login/lock from, well, everything that wasn't session login/lock.
posted by loquacious at 12:05 PM on December 8, 2017


Cripes, how many people leave a shell open and just lock their screen when they walk away?

Yeah, I've been seeing people riffing about changing their password away from "rm -rf /" (uh, or the rather verbose password of "rm -rf / -no-preserve-root")
posted by Nonsteroidal Anti-Inflammatory Drug at 1:48 PM on December 8, 2017


« Older Not exactly Socrates   |   "The Aldovian castle is about as nice as a... Newer »


This thread has been archived and is closed to new comments