Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Security Desktops (Apple)

macOS Exploit Published on the Last Day of 2017 (bleepingcomputer.com) 62

Posted by msmash from the security-woes dept.
An anonymous reader shares a report: On the last day of 2017, a security researcher going online by the pseudonym of Siguza published details about a macOS vulnerability affecting all Mac operating system versions released since 2002, and possibly earlier. Siguza did not notify Apple in advance, so at the time of writing, there is no fix for this flaw. Despite the doom and gloom, the vulnerability is only a local privilege escalation (LPE) flaw that can only be exploited with local access to a computer or after an attacker has already got a foothold on a machine. The vulnerability grants root access to an attacker. The issue affects the IOHIDFamily macOS kernel driver, a component that handles various types of user interactions. Siguza said he read about various flaws in this component and took a look at it to find new ways to compromise iOS, Apple's mobile operating system, where IOHIDFamily is also deployed. The expert says he found the LPE flaw in the IOHIDFamily code specific to macOS versions only. In a tweet, Siguza said, "My primary goal was to get the write-up out for people to read. I wouldn't sell to blackhats because I don't wanna help their cause. I would've submitted to Apple if their bug bounty included macOS, or if the vuln was remotely exploitable.
This discussion has been archived. No new comments can be posted.

macOS Exploit Published on the Last Day of 2017 More

macOS Exploit Published on the Last Day of 2017

Comments Filter:

  • only a local privilege escalation (Score:1)

    by Anonymous Coward

    Oh, it's "only a local privilege escalation". No worries then.

    • Re:only a local privilege escalation (Score:5, Insightful)

      by Penguinisto ( 415985 ) on Tuesday January 02, 2018 @10:42AM (#55848771) Journal

      Oh, it's "only a local privilege escalation". No worries then.

      For the majority of use cases, that's pretty much it; you still have to convince someone to give you basic (local or remote) access to the box first.

      Same story on *any* OS, come to think of it.

      • If you have a process running on macOS with ambient authority then in most cases a root exploit doesn't give you much - you can already access and modify everything that the user cares about. A vulnerability like this; however, can also be exploited by sandboxed applications (though hopefully not sandboxed daemons, which shouldn't have access to the HIDs).

        Most Apple apps are now sandboxed, as are Microsoft Office and anything that is distributed via the App Store. I posted above that most people don't

      • In a business environment, where users are not allowed to be admins on their boxes, this is a frak'ng nightmare.

      • Stuxnet needed a local privilege escalation to work

        http://www.zdnet.com/article/s... [zdnet.com]

        As new details emerge to shine a brighter light on the Stuxnet attack, Microsoft said the attackers initially targeted the old MS08-067 vulnerability (used in the Conficker attack), a new LNK (Windows Shortcut) flaw to launch exploit code on vulnerable Windows systems and a zero-day bug in the Print Spooler Service that makes it possible for malicious code to be passed to, and then executed on, a remote machine.

        The malware also exploited two different elevation of privilege holes to gain complete control over the affected system. These two flaws are still unpatched.

        I.e. the problem is not your buddy lends you their machine, it's that code arrives by more dubious means and uses a privilege escalation to be able to do more damage.

        I could see Macs being hit with something which encrypts files and demands a password to decrypt them and privilege escalation would be necessary for such an attack.

        Best make sure you've got a Time Machine backup on a removable disk.

      • Comment removed based on user account deletion

    • Re:only a local privilege escalation (Score:4, Interesting)

      by TheRaven64 ( 641858 ) on Tuesday January 02, 2018 @11:29AM (#55849091) Journal
      This looks as if it's exploitable even for sandboxed processes. This isn't such a big deal on macOS, where both users of the Mac App Store might need to worry, but most other people are only running sandboxed apps written by Apple (I'm not sure if WebKit renderer processes have direct HID access - I don't think they do, because HID events are proxied for them from the privileged component, though the XPC vulnerability a few months ago turned sandboxed WebKit component vulnerabilities into whole-machine compromises). It is a much bigger deal for iOS, where most users run not-very-trusted applications from the iOS App Store and rely on the sandbox framework to isolate them. The sandbox framework doesn't work so well on a compromised kernel.

    • Re: (Score:3)

      by guruevi ( 827432 )

      It's worse than that. It's a local privilege escalation, already patched in macOS 13.0.2 via ROP and race conditions during logout/shutdown of the computer, it requires a LOT of luck and is very time sensitive for it to work, in my testing most of the time the thing will either fail or crash the kernel.

      • Re: (Score:2)

        by Troed ( 102527 )

        I don't think it's patched.

        From the description (regarding the kernel slide part only):

        The technique explained below has for some reason stopped working on macOS High Sierra 10.13.2. I don’t know why and I didn’t bother to investigate, but the IOHIDFamily vulnerability is still there all the same. So while the hid binary in its current state will only work up to 10.13.1, you could just patch together hid and leak to get everything working on 10.13.2 - or even write a mach-port-based exploit out

        • Re: (Score:2)

          by guruevi ( 827432 )

          Yeah, so in theory it works but I've tried it, I can't get it to work. The kernel will literally block either the hid or the leak binaries from working, the bug may still be there but the kernel prevents it from working. But even on older kernels, the worst I got was a kernel panic, I never got root access or SIP to turn off on 10.12 or 10.13.

  • Impressive (Score:3)

    by 110010001000 ( 697113 ) on Tuesday January 02, 2018 @11:17AM (#55848993) Homepage Journal
    Reading the writeup I would say this guy really knows his Mac internals. Apple is getting better at security though: the last root exploit only required you to type "root" and no password. And the one before that required a single line of script to get root.

    • ...the last root exploit only required you to type "root" and no password.

      A computer does exactly as it’s instructed and you complain. There’s just no pleasing some people...

  • This is sooooo 2017 (Score:3)

    by DickBreath ( 207180 ) on Tuesday January 02, 2018 @02:25PM (#55850289) Homepage
    A vulnerability from back in 2017 is probably old enough to not be worth fixating.

    • A vulnerability from back in 2017 is probably old enough to not be worth fixating.

      I remember 2017 like it was only a couple of days ago...

  • I read IOHIDFamily, which contain IO and HID. Obviously, but, this means USB to me, and, doing basic math, I'm wondering whether a no-name Chinese USB device could use this hole to implant some malware.

Slashdot Top Deals

IOT trap -- core dumped

Close