1. 90
  1.  

  2. 47

    https://forums.developer.apple.com/thread/79235

    November 13th, this was a known behavior

    1. 6

      Your comment should be on the top. Looks like apple should have responded two weeks ago. It would be interesting to study how widely exploited this bug has been. Does anybody have an estimate how many people could have seen that solution post on the developer forum?

      1. 2

        Does anybody have an estimate how many people could have seen that solution post on the developer forum?

        One fewer than should have seen it.

      2. 3

        So odd… The solution of entering “root” twice is given as if that’s just kind of a normal thing to do if you need to create an admin account. Is this behavior perhaps actually intentional, but should only work if there are no existing admin accounts?

        1. 1

          Here is the security patch: https://support.apple.com/en-us/HT208315

        2. 22

          Just watched a half-dozen increasingly horrified devs repro this. Gossip is that the only current remediation is to set a root password, disabling the account clears the password and enables the bug.

          1. 6

            I have yet to see an explanation on why this is happening? Has anyone found the underlying bug?

            1. 1

              Yep, that’s available now.

          2. 12

            As a Linux user, I don’t really care, because I’ve lived with the knowledge that my screen locker (whatever the local DE’s substitute for xscreensaver is) has been totally busted(*) for years without it really bothering me.

            (* by which I mean, multiple times it has manifested security vulns wherein mashing randomly on the keyboard for a bit would crash the screen locker and unlock the screen)

            Something something if you have access to the hardware you can just futz with it anyway.

            1. 5

              Something something if you have access to the hardware you can just futz with it anyway.

              A critical difference here is that “you can futz with the harder” is something you’d need at least some knowledge and some equipment to do, not necessarily much of each, but you need to know what you’re doing.

              You can fit the instructions for this exploit in a single tweet.

              1. 2

                Very much this, but:

                You can fit the instructions for this exploit in a single tweet.

                That has also been the case for many other exploits of that kind, independent of operating system, with or without a graphical shell.

                Screen locking seems to be a surprisingly nasty problem, even all smartphone platforms have had similar issues.

              2. 4

                This one is accessible remotely.

                1. 3

                  Oh, it is? The exploit described here sounds like you need local access. This is interesting.

                  Is it exploitable via RDP or VNC or something if you have screen sharing turned on, and if so do you need to log in as an ordinary user account first?

                  1. 3

                    Screen sharing is indeed the remote exploit vector, [1] [2]. You don’t need to log in as an ordinary user account first.

                    1. 3

                      Does Remote Login allow SSH’ing in as root? I’m not familiar with the default macOS config.

                      1. 2

                        I don’t know, but you could enable it pretty trivially.

                        1. 1

                          I did try after enabling SSH to “All Users” and it didn’t allow me to log in as root.

                        2. 2

                          Thank you for elaborating. Yeah that’s genuinely scary. Good reason to leave screen sharing turned off I guess. :x

                    2. 3

                      Another reason to consider a Wayland composer? I’ve got Wayland and Weston with xwayland comparability running on my media PC right now. Seems to work pretty well.

                      1. 2

                        Yeah I’m hoping Wayland fixes this properly by using a protocol for screen locking that is not intrinsically silly like X11’s is. I assume it does (why would Wayland devs bother to copy such an obvious misfeature of X11?), but I haven’t checked.

                      2. 1

                        You’re perhaps referring to gnome-screensaver https://www.jwz.org/blog/2015/04/i-told-you-so-again/ ?

                        How is light-locker’s track-record? KDE’s thing?

                        I still use xscreensaver on Xubuntu 17.10. I have a feeling jwz has a better track-record than all of the above, but it’s probably not perfect either …

                        1. 3

                          Yes. I don’t know about the others’ record but I’d be surprised if it was perfect. xscreensaver can’t do a perfect job here either because it, like any process, could be arbitrarily killed by something like an OOM killer or a hardware bug causing SIGBUS to be emitted in it.

                          The underlying problem is that X11’s protocol for screen lockers is silly: the screen unlocks when the locker quits for any reason at all. jwz asserts that gnome-screensaver ought to take more care about crash proofing in light of that, which I can’t dispute. Solving the root problem is going to be much more robust anyway though.

                          The 2004 article on this is much better BTW: https://www.jwz.org/xscreensaver/toolkits.html

                      3. 11

                        Just in case anyone wants an easy link to send to people for fixing this: https://9to5mac.com/2017/11/28/how-to-set-root-password/

                        1. 6

                          I’ve just reproduced it using my admin account which is named Admin rather than root. My Admin account has a password set. It’s intermittent, but I managed to unlock a couple of times without ever entering a password. I’ve also unlocked with “root” and no password. Changing the username seems to make it easier.

                          1. 5

                            Not able to reproduce this behavior. On Mac OS, I believe the root account is disabled by default; it gets enabled when a password is set for it. I wonder if the behavior they’re reporting is still present when a root password has been set.

                            1. 7

                              It is not, it gets fixed by setting a root password.

                              I’ve been able to reproduce this on my 5K iMac but not my 13” TB MacBook Pro.

                            2. 7

                              Really? 24 comments already and no one has even mentioned the phrase responsible disclosure?

                              Bugs are bugs. No one can claim Apple deliberately shipped this behaviour. Yes it should have been caught but there is no malicious intent.

                              This fucking clown knowingly publicises a vulnerability with instructions on fucking Twitter.

                              This is 0% about security and 100% about some jackass getting his 15 minutes of fame. “Software Craftsman” my ass.

                              1. 16

                                Over on the Orange Site half the people are having to explain to the other half what responsible disclosure even is. I wouldn’t be terribly surprised if this guy, of which there is no signs he’s familiar with standard security community practices, just didn’t know that there was a standard practice for disclosure. especially when these days the only way to get half-decent tech support is to publicly complain on Twitter.

                                Yes, he should have done the research on responsible disclosure. But if we’re willing to say extend the benefit of the doubt to the richest tech company on the planet, we should extend the benefit of the doubt a random guy who stumbled into this bug.

                                1. 1

                                  Oh believe me, I saw the comments in that other place.

                                  And I agree the guy is clearly not a security researcher or anything close to it. But even so - he clearly understood the ramifications of the bug, heck he could have just stopped typing at the first full stop (period) and hit “Send Tweet”.

                                  Apple Support would have responded, asking for more details via DM.

                                  I understand you want to give him the benefit of the doubt, but I find it hard to believe anyone who understands how powerful a local root account is, didn’t comprehend the danger of publicising an exploit to the fucking world.

                                  As I said. He wants his 15 minutes of fame.

                                2. 8

                                  Responsible disclosure is a “truthy” phrase like “responsible encryption”. It sounds good on the visceral level but once you unpack the arguments, not so much.

                                  Full disclosure is actually preferred by a lot of security people, because - especially in the case of a very simple bug - you never know who knows about the security issue already.

                                  In this case, before it was posted on twitter someone already mentioned this issue two weeks ago on apple’s developer forum and I find it hard to believe that adversaries do not already have pretty thorough test suites running against popular operating systems to discover vulnerabilities like this.

                                  Apple should also have a bug bounty program covering macOS. Reporting a vulnerability is a long and painful* task, where a security researcher is playing project manager for months with oftentimes unfriendly organizations. I perfectly appreciate the argument that people who discover vulnerabilities are under no obligation to spend a lot of time and effort helping random companies fix security issues. That’s where a bug bounty should come in.

                                  *I regularly watch security researchers ask their twitter followers to help them get in touch with organization x or y, after they already exhausted pretty much every other avenue of contacting people in an org who can deal with a security issue. See this for an example from today.

                                  (Disclaimer: I’m blue team infosec)

                                  1. 3

                                    Full disclosure is actually preferred by a lot of security people, because - especially in the case of a very simple bug - you never know who knows about the security issue already.

                                    I would seriously question the judgement or motivations of any researcher who believed that. You may not know who knows about the issue already, but following disclosure, you can be extremely confident that a whole lot more people know. If your goal is to minimize harm to users, letting a whole bunch of attackers know about a vulnerability before the vendor has a chance to patch it is not a rational route to that goal.

                                    1. 4

                                      More people know about it, therefor they can mitigate the impact even before a vendor patch is out. Once a vulnerability is publicly known, vendors usually react faster too. Compare that to a month-year-multiyear process where some people know, noone knows to which extent blackhats know about it (they are heavily incentivised against disclosing what they know) and people who would be impacted by a given issue generally don’t.

                                      For example in the recent infineon RSA vulnerability the >6 month timeline put people relying on that faulty library at risk.

                                    2. 2

                                      I would totally buy this argument in general, but for Apple it’s not that hard. I did a search for “Apple security” and literally the first result had an email for the security team and even a PGP key you could use if you wanted. No excuses for this guy, he put lots of people at risk and acted like an ass for no reason.

                                    3. 3

                                      Responsible disclosure is for security researchers. When your bug is so bad that someone who has no idea what they’re doing finds it they’re just going to tell their friends, or maybe even just exploit it themselves quietly. We’re frankly lucky he decided to shout that out to the whole world, and that everyone didn’t think it was a prank.

                                      1. 0

                                        Right, like driving safely is only for bus drivers and safe sex is only for hookers?

                                        1. 1

                                          The difference is that driving safely and safe sex have personal implications. With responsible disclosure there really are absolutely no consequences for not doing it. So don’t expect people to do it, and definitely don’t depend on it.

                                      2. 2

                                        If apple quietly fixed it without fanfare, mac customers wouldn’t realize they bought from a shit company. Especially important since Apple has been hitting the security angle. If they can’t get this right, what chance in hell do they have getting a neural net based face detection as password system right?

                                        1. 2

                                          Apple has been ‘hitting’ the privacy angle.

                                          But frankly, I say bullshit to your entire premise. Responsible disclosure doesn’t mean:

                                          you can’t say shit about this

                                          It means (assuming the vendor responds and is cooperative):

                                          You can’t tell the world about this until an agreed upon date, before which the vendor will distribute a patch to users

                                          Once the embargo date passes, you can make any manner of publication about the bug you like.

                                          What this guy did is just fucking dickish.

                                          1. 7

                                            He’s not a security researcher, he’s just some dude. I don’t understand what incentive he has, or how he would even know to do what you’re saying. Just be grateful he didn’t sell it on the black market.

                                            1. 1

                                              The responsible thing to do is publish it as soon as possible with a known work around. Since users can protect themselves without waiting for Apple to fix the issue, they should know about it NOW. In this case the known work around is to set a password for the root account. Another work around is to never let anyone near your computer until its fixed.

                                              Users can fix it themselves, they need to know NOW.

                                              In regards to my premise, I disagree. In most cases users can take actions to protect themselves. It is irresponsible for the security community to keep these these private to “protect the weak and useless user”.

                                              These embargoes serve only the purpose of minimizing embarrassment and cost to the bottom line. “Look, we screwed up a month ago but fixed it, so don’t worry” doesn’t really bring about the same anger as “Look, you are exposed now, protect yourself by doing X, we are working on a fix.”, which brings less anger than “Hey guys, Apple has this huge issue and they didn’t even know about it”. The first costs Apple little. The second costs Apple more. The third costs Apple the most. Which do you think will push Apple to change their processes to prevent these problems?

                                              1. 3

                                                The responsible thing to do is publish it as soon as possible with a known work around. Since users can protect themselves without waiting for Apple to fix the issue, they should know about it NOW. In this case the known work around is to set a password for the root account. Another work around is to never let anyone near your computer until its fixed.

                                                Users can fix it themselves, they need to know NOW.

                                                This really depends on what your mental model of a “user” is:

                                                1. In a “Responsible Disclosure” scenario, there are certainly users who are being “hung out to dry” in that they would be in a position to do something to protect themselves a lot sooner if there were informed of the bug ASAP. These users are exposed to risk by not being informed immediately.

                                                2. In an “Immediate Disclosure” scenario, there are a large number of users who will not hear about the security bug, and are not possessed of the kinds of skills that would allow them to mitigate the problem even if they did hear about it. These users are exposed to risk by not giving the vendor time to step in and provide them with mitigation via automated channels.

                                                It is irresponsible for the security community to keep these these private to “protect the weak and useless user”.

                                                I would suggest that this is in no way a clear-cut conclusion, and that reasonable people have room for reasonable disagreement on this topic. It’s fundamentally a train-tracks Ethics problem, and there is no real “right answer” here, however passionately you believe that yours is the only correct one.

                                                These embargoes serve only the purpose of minimizing embarrassment and cost to the bottom line.

                                                I don’t think that’s a charitable reading. My own take is that the number of users exposed to risk in scenario #2 is larger than the number in scenario #1, and therefore scenario #1 is preferable. You’re free to disagree, of course, but attributing that disagreement to bad faith isn’t conductive to communication.

                                                1. 1

                                                  I don’t believe your disagreement is in bad faith. I believe there are business reasons, not user reasons, that disclosure rules for bounties are the way they are.

                                                  Read the first paragraph of their disclosure. https://support.apple.com/en-us/HT208315

                                                  Might as well say “we will keep security issues secret from you so forget any thought you had of keeping yourself safe. Let us adults take care of you.”

                                                  If you are right that the #2 group is larger, doesn’t that bother you? What would have to change so most users have power to protect themselves vs rely on the paternal powers of the company?

                                        2. 4

                                          The security patch for it just dropped - https://support.apple.com/en-gb/HT208315

                                          1. 4

                                            Any guesses as to how this could happen?

                                            There must be some timing involved because of how you need to press the button quickly, but I am struggling to think of why you would put any timing code in there at all apart from exponential backoff, which would result in things slowing down, not passing.

                                            Maybe some wacky timing attack protection that bugged out?

                                            1. 2

                                              my experimenting didn’t reveal any timing element; it worked consistently for me without any kind of trickery.

                                              1. 1

                                                Yeah, I’ve been puzzling over this. I simply do not understand how this happens. Assuming it’s not an intentional backdoor left by a departing employee (which I doubt), it has to be related to something in Directory Services? I am really at a loss.

                                              2. 3

                                                I think this person just missed out on a huge bug bounty.

                                                1. 5

                                                  I don’t believe Apple has a public bug bounty program.

                                                  1. 3

                                                    maybe this will teach them haha.

                                                    1. 6

                                                      They got $45.4 billion worth of justification to keep doing what they’re doing as of last quarter. ;)

                                                    2. 1

                                                      https://techcrunch.com/2016/08/04/apple-announces-long-awaited-bug-bounty-program/

                                                      I guess it’s not what you mean by “public” though.

                                                  2. 3

                                                    https://medium.com/@lemiorhan/the-story-behind-anyone-can-login-as-root-tweet-33731b5ded71

                                                    The author’s follow-up to the tweet. I’m not sure it really clears up too much, except that they knew the issue had been mentioned in other places already.

                                                    1. 4

                                                      I left in 2014; software quality has been dropping since. Hmmmmm.

                                                        1. 1

                                                          Does not work for me: macOS Sierra 10.12.6 (16G29). I don’t have a root password or separate admin account. My user account is admin.

                                                          1. 7

                                                            High Sierra exclusive.