4 ms·

because it doesn’t provide remote access, you’re right. But it’s been released publicly before there was a patch available, on an OS that’s only used as a perso

by bsaul 9y ago

because it doesn’t provide remote access, you’re right. But it’s been released publicly before there was a patch available, on an OS that’s only used as a personal computer, not as a server. And is immediately exploitable by just anyone, with 0 technical background. I think that makes it a very big deal, no matter what CVE usually use for a scale. I also don’t remember any macOS security breach getting that much publicity.

ben174 9y ago
You'd still need physical access to a logged-in machine to exploit it. I'm not sure what the latest default is as to Guest accounts and whether or not those can exploit it, but it's a significantly different story if it requires you to exploit it on an unattended logged in machine. If guest accounts are enabled by default and a guest account can exploit it, yea.. that's pretty bad.
- miles 9y ago
  > You'd still need physical access to a logged-in machine to exploit it Not necessarily; this aspect was unfortunately underreported: "macos 10.13 bug isn't limited to root in all circumstances; via ARD, you can log in as any existing user (e.g. _applepay) and share the screen of the logged-in user. also _uucp is allowed to log in" https://twitter.com/unsynchronized/status/935656609140711426 https://twitter.com/unsynchronized/status/935656609140711426
  - X-Istence 9y ago
    The defaults don't allow for remote management, screen sharing, or SSH or anything. Most of these devices are going to be sold without those options ever being touched. So that limits things in terms of who is affected.
    - Someone1234 9y ago
      None of which makes this statement any less inaccurate: > You'd still need physical access to a logged-in machine to exploit it.
      - miles 9y ago
        > None of which makes this statement any less inaccurate: >> You'd still need physical access to a logged-in machine to exploit it. Yes it does; if Remote Management was enabled (as is often the case for remote servers or mass deployments), an attacker could login via Apple Remote Desktop using default, pre-existing user accounts (_applepay, _uucp, etc) and a blank password without ever needing physical access. Just tested again with a new, unpatched install of 10.13.1 on one Mac, connecting via Screen Sharing from another. To be clear, I never logged in as root on the 10.13.1 Mac at all, even via the exploit.
        59nadir 9y ago
        You are agreeing with the comment you're replying to. He/she was saying that the defaults being what they are do not make the statement that you need physical access any less inaccurate.
        miles 9y ago
        Thank you for the kind correction and clarification, 59nadir. And my apologies to you, Someone1234, for having hastily misread your comment.
    - miles 9y ago
      Just as a very simple, isolated example, think of all the Mac Mini servers with Remote Management enabled at https://macminicolo.net https://macminicolo.net . As I mentioned below, this remote exploit did NOT require ever logging in as root, whether with or without a password. This was a much more serious bug than is commonly understood.
- Someone1234 9y ago
  > You'd still need physical access to a logged-in machine to exploit it. You don't. You can exploit it from the login screen after a machine wakes from sleep, you can also exploit it remotely via Screen Sharing.
  - thecynh 9y ago
    But from a shut-off machine it wasn't exploitable? Have an iMac sitting at work (turned off) and am on vacation =)
dsacco 9y ago
I agree it's a big deal, in that it's serious - it's a security vulnerability after all, yes. But I disagree about its significance for Apple in the face of the sheer number of security advisories that come out across iOS and macOS each year. When we broaden perspective away from just Apple, this becomes absolutely miniscule. There's a lot of navel gazing going on, but there's not a lot of reason to read anything particular out of this at all. It's very silly, and I would also be embarrassed if I was involved in it, but those aren't good metrics for judging the realistic frequency of bugs like this, nor their severity. I've had vulnerabilities I've reported picked up by a bunch of news media before even though they weren't that serious. As it turns out, the media just latches on to security headlines, and everyone sort of forgets about it except us grumblers on Hacker News, because we Never Forget. Someone from Google Project Zero has probably been inspired to start fuzzing the macOS at the UI level now, and that's a good thing - they should. But that's about all I'm taking away from this story. Moreover: > on an OS that’s only used as a personal computer, not as a server This makes it less severe, not more so. I'd rather have a Heartbleed impacting nearly every server on the internet than a...whatever we're calling this, impacting every macOS computer in the world. I guess I can make a botnet...except I still have to be local to it in the majority of cases, or do specific targeting, or chain this with another piece of popular, compromised software, etc. It suddenly becomes a bit more complex than just someone pressing enter on a root prompt twice. Plus, if the vulnerability is laughably silly, it's usually easier to find than a chain of them that evidences a systemic misconfiguration in the entire OS. In fact, I'd posit that the reason this story is getting so much attention is precisely because the vulnerability is so easy to understand, and because someone disclosed it on Twitter. Frankly, the whole situation is really quite funny in a black comedy sort of way. But while it's fun to write stories poking fun at large companies for their silly mistakes, it doesn't meaningfully reflect their security competency or the long term perception of their security competency. Really I don't mean to trivialize it. It's not a good look, and definitely it's worthy of being patched. But I think it's worth looking at from a much broader perspective.
- toyg 9y ago
  >> on an OS that’s only used as a personal computer, not as a server > This makes it less severe, not more so. You are looking at it from the perspective of a seasoned security professional. It's like looking at the terrorist attack in Nice from a military point of view and saying "eh, this was just a guy on a lorry; it's much more difficult to raid Osama in the middle of Pakistan". That might well be, but this does not matter to the general public - to them, concepts like "botnets" are immaterial, whereas Slippin' Jimmy entering their macbooks to read their emails while they're sleeping is very real. In that sense, the impact here was bigger than any other security hole ever experienced on the Mac.
Someone1234 9y ago
> because it doesn’t provide remote access It was, via Screen Sharing and a few other remote mechanisms. It "likely" wasn't often internet accessible due to firewalls, but it was remotely exploitable on many large Mac deployments in enterprise and education.

by bsaul 9y ago

ben174 9y ago

You'd still need physical access to a logged-in machine to exploit it. I'm not sure what the latest default is as to Guest accounts and whether or not those can exploit it, but it's a significantly different story if it requires you to exploit it on an unattended logged in machine. If guest accounts are enabled by default and a guest account can exploit it, yea.. that's pretty bad.

miles 9y ago
> You'd still need physical access to a logged-in machine to exploit it Not necessarily; this aspect was unfortunately underreported: "macos 10.13 bug isn't limited to root in all circumstances; via ARD, you can log in as any existing user (e.g. _applepay) and share the screen of the logged-in user. also _uucp is allowed to log in" https://twitter.com/unsynchronized/status/935656609140711426 https://twitter.com/unsynchronized/status/935656609140711426
- X-Istence 9y ago
  The defaults don't allow for remote management, screen sharing, or SSH or anything. Most of these devices are going to be sold without those options ever being touched. So that limits things in terms of who is affected.
  - Someone1234 9y ago
    None of which makes this statement any less inaccurate: > You'd still need physical access to a logged-in machine to exploit it.
    - miles 9y ago
      > None of which makes this statement any less inaccurate: >> You'd still need physical access to a logged-in machine to exploit it. Yes it does; if Remote Management was enabled (as is often the case for remote servers or mass deployments), an attacker could login via Apple Remote Desktop using default, pre-existing user accounts (_applepay, _uucp, etc) and a blank password without ever needing physical access. Just tested again with a new, unpatched install of 10.13.1 on one Mac, connecting via Screen Sharing from another. To be clear, I never logged in as root on the 10.13.1 Mac at all, even via the exploit.
      - 59nadir 9y ago
        You are agreeing with the comment you're replying to. He/she was saying that the defaults being what they are do not make the statement that you need physical access any less inaccurate.
        miles 9y ago
        Thank you for the kind correction and clarification, 59nadir. And my apologies to you, Someone1234, for having hastily misread your comment.
  - miles 9y ago
    Just as a very simple, isolated example, think of all the Mac Mini servers with Remote Management enabled at https://macminicolo.net https://macminicolo.net . As I mentioned below, this remote exploit did NOT require ever logging in as root, whether with or without a password. This was a much more serious bug than is commonly understood.
Someone1234 9y ago
> You'd still need physical access to a logged-in machine to exploit it. You don't. You can exploit it from the login screen after a machine wakes from sleep, you can also exploit it remotely via Screen Sharing.
- thecynh 9y ago
  But from a shut-off machine it wasn't exploitable? Have an iMac sitting at work (turned off) and am on vacation =)

dsacco 9y ago

I agree it's a big deal, in that it's serious - it's a security vulnerability after all, yes. But I disagree about its significance for Apple in the face of the sheer number of security advisories that come out across iOS and macOS each year. When we broaden perspective away from just Apple, this becomes absolutely miniscule. There's a lot of navel gazing going on, but there's not a lot of reason to read anything particular out of this at all. It's very silly, and I would also be embarrassed if I was involved in it, but those aren't good metrics for judging the realistic frequency of bugs like this, nor their severity. I've had vulnerabilities I've reported picked up by a bunch of news media before even though they weren't that serious. As it turns out, the media just latches on to security headlines, and everyone sort of forgets about it except us grumblers on Hacker News, because we Never Forget. Someone from Google Project Zero has probably been inspired to start fuzzing the macOS at the UI level now, and that's a good thing - they should. But that's about all I'm taking away from this story. Moreover: > on an OS that’s only used as a personal computer, not as a server This makes it less severe, not more so. I'd rather have a Heartbleed impacting nearly every server on the internet than a...whatever we're calling this, impacting every macOS computer in the world. I guess I can make a botnet...except I still have to be local to it in the majority of cases, or do specific targeting, or chain this with another piece of popular, compromised software, etc. It suddenly becomes a bit more complex than just someone pressing enter on a root prompt twice. Plus, if the vulnerability is laughably silly, it's usually easier to find than a chain of them that evidences a systemic misconfiguration in the entire OS. In fact, I'd posit that the reason this story is getting so much attention is precisely because the vulnerability is so easy to understand, and because someone disclosed it on Twitter. Frankly, the whole situation is really quite funny in a black comedy sort of way. But while it's fun to write stories poking fun at large companies for their silly mistakes, it doesn't meaningfully reflect their security competency or the long term perception of their security competency. Really I don't mean to trivialize it. It's not a good look, and definitely it's worthy of being patched. But I think it's worth looking at from a much broader perspective.

toyg 9y ago
>> on an OS that’s only used as a personal computer, not as a server > This makes it less severe, not more so. You are looking at it from the perspective of a seasoned security professional. It's like looking at the terrorist attack in Nice from a military point of view and saying "eh, this was just a guy on a lorry; it's much more difficult to raid Osama in the middle of Pakistan". That might well be, but this does not matter to the general public - to them, concepts like "botnets" are immaterial, whereas Slippin' Jimmy entering their macbooks to read their emails while they're sleeping is very real. In that sense, the impact here was bigger than any other security hole ever experienced on the Mac.

Someone1234 9y ago

> because it doesn’t provide remote access It was, via Screen Sharing and a few other remote mechanisms. It "likely" wasn't often internet accessible due to firewalls, but it was remotely exploitable on many large Mac deployments in enterprise and education.