Apple's macOS Screen Sharing Flaw Is Being Exploited in the Wild

[bzgnyc2]

It's the opposite: they generally design their daemons such that they only run when a socket is open.

It depends. Ideally daemons should only run when enabled but one can clearly see 100s of daemons running on modern Mac systems including for services not enabled. For example there are 4 iCloud-related services running on one of my laptops even though I don't have iCloud enabled and have never enabled it. Similarly, studentd -- something for classroom management -- more than occasionally updates a preferences file under ~/Library even though I don't use that and my laptops have never been part of an educational system. Clearly it runs even when not used.

That's also true of screensharingd. You can easily try this yourself:

1. With Screen Sharing disabled, open Activity Monitor, and search for screensharingd. You probably won't find it.
2. Now in Terminal, do telnet localhost 5900. This will fail with "connection refused", as there's nothing listening. screensharingd still won't be running, of course.
3. Now turn it on. Notice that screensharingd still isn't running!
4. Finally, try telnet localhost 5900 again. This time, it'll work, and the very act of connecting to that port is what actually launches the daemon.

This is a mechanism in launchd with security and energy benefits. Instead of having screensharingd constantly listening for connections, launchd does the listening:

Yes glad to see that Apple handled this one like that -- kind of like the old BSD inetd design. That's the way it should be but not the way that a lot of Mac services are setup.

Then for now I am going to assume that the bug is in screensharingd and/or ScreensharingAgent and not launchd or related configuration of such, and therefore having the Firewall On and this Off is good protection against this hole (short of the patch -- but even on patched system, what similar holes are out there waiting to be discovered in other Apple services?).

Still it would be better if Apple provided more information on the bug. Apple goes crazy with protections against "evil maid" scenarios but I am most concerned about vulnerabilities to remote exploits.

P.S.Apple removed Telnet from macOS years ago -- nc(1) would be the builtin tool to test something like this now.

 

[bzgnyc2]

Linux and Windows.....

Well those aren't Apple's but I agree with you as far as well-configured Linux machine. OpenBSD better but partially because it doesn't do as much...

 

[ScooterComputer]

It might should be noted that several ISPs in the U.S. (at least), eg Comcast, have been enabling IPv6 on their consumer-rented routers without really advising customers that it is happening, or requiring opt-in. WHEN this happens, while there IS a firewall that runs on the router, your LAN-local devices that were once 'protected' by an IPv4 NAT firewall suddenly are ass-out on the internet, relying nearly entirely on whatever firewall is running locally, IF a firewall is even running locally. Worse, older hardware—like multifunction printers—often had IPv6 enabled, but often not particularly well-tested (ie buggy), and had firmware vulnerabilities and static passwords (or passwords based on MAC address) that attackers have long since targeted… this gives an attacker a secondary vector: they get control of a mfc, and can then jump (from inside the same subnet) to other vulnerable devices that would ordinarily have been protected by firewall, but because firewall rules often allow LAN-local peer-to-peer communications (as Apple's firewall in macOS does), are bypassed.
This problem is going to get worse as more ISPs do this nonsense and A.I. fuzzes out more and more vulnerabilities in older code. IPv6 is great, but it cannot and should not be entered into lightly. And irresponsible ISPs have been throwing non-tech-savvy customers into the deep end of the pool without floaties.

 

[bzgnyc2]

The ones not listed in the article? I guess the article does only mention macOS, so “all of the other ones”.

All macOS before August 6th (the release of 26.6.1/15.7.9/14.8.9) were likely vulnerable to this bug. Or at least all macOS since this network/launchd/etc configuration was implemented. Then 26.6.1/15.7.9/14.8.9 fixed this bug but they are not magically more secure than other macOS. Just not vulnerable to this bug. Apple doesn't have a more secure class of OS other than these with Lockdown enabled (which has its own issues).

 

[chucker23n1]

It depends. Ideally daemons should only run when enabled but one can clearly see 100s of daemons running on modern Mac systems including for services not enabled. For example there are 4 iCloud-related services running on one of my laptops even though I don't have iCloud enabled and have never enabled it. Similarly, studentd -- something for classroom management -- more than occasionally updates a preferences file under ~/Library even though I don't use that and my laptops have never been part of an educational system. Clearly it runs even when not used.

Sure, but daemon ≠ "something with a socket". I don't think iCloud opens an incoming socket, whether you use it or not.

Then for now I am going to assume that the bug is in screensharingd and/or ScreensharingAgent and not launchd or related configuration of such,

Yes, the flaws are/were in screensharingd.

and therefore having the Firewall On and this Off is good protection against this hole (short of the patch -- but even on patched system, what similar holes are out there waiting to be discovered in other Apple services?).

I mean, yes, but if you want a VNC server, all a firewall could do is restrict which hosts can connect. And on most setups these days, that will almost always be "hosts on the local network" anyway; everything beyond that is generally behind NAT.

Which is not to downplay the severity. I just don't think there's much the macOS firewall could've done. It needs to be fixed on screensharingd's end, plus people should look into their router / firewall / etc. outside the Mac and audit whether fewer hosts should be let through (or whether they really need VNC at all).

P.S.Apple removed Telnet from macOS years ago -- nc(1) would be the builtin tool to test something like this now.

Ah yes. I do have Telnet, but through Homebrew.

 

[chucker23n1]

All macOS before August 6th (the release of 26.6.1/15.7.9/14.8.9) were likely vulnerable to this bug. Or at least all macOS since this network/launchd/etc configuration was implemented.

Yep. I imagine this bug has been there for a long time.

launchd dates back to 10.4 (2005), although that doesn't mean this specific implementation of screensharingd does. But I wouldn't be shocked if this bug has been in there for two decades.

 

[Unregistered 4U]

All macOS before August 6th (the release of 26.6.1/15.7.9/14.8.9) were likely vulnerable to this bug. Or at least all macOS since this network/launchd/etc configuration was implemented. Then 26.6.1/15.7.9/14.8.9 fixed this bug but they are not magically more secure than other macOS. Just not vulnerable to this bug. Apple doesn't have a more secure class of OS other than these with Lockdown enabled (which has its own issues).

Having fewer vulnerabilities = more secure. Even when having fewer vulnerabilities means fewer features. Non-macOS operating systems offered by Apple doesn’t expose port 5900, so not only are they not vulnerable, they can’t be MADE vulnerable to this exploit (unless the user takes steps that aren’t available to non-developers).

 

[svish]

Disappointing that software issues exists in the first place. Glad that it has been fixed now.

 

[Ben11]

personal alternative: never installing Tahoe to begin with

My 2019 iMac doesn’t support it anyway guess I’m not screwed lol

 

[bzgnyc2]

Sure, but daemon ≠ "something with a socket". I don't think iCloud opens an incoming socket, whether you use it or not.

General rule in security is to minimize surface area. These days there aren't too many daemons not connected to a socket. All those processes have to be listening to something or how would they know what to do? Better off than on I say.

Yes, the flaws are/were in screensharingd.

Ah that's great -- those are the details I was looking for. Though disturbing...

I mean, yes, but if you want a VNC server, all a firewall could do is restrict which hosts can connect. And on most setups these days, that will almost always be "hosts on the local network" anyway; everything beyond that is generally behind NAT.

Which is not to downplay the severity. I just don't think there's much the macOS firewall could've done. It needs to be fixed on screensharingd's end, plus people should look into their router / firewall / etc. outside the Mac and audit whether fewer hosts should be let through (or whether they really need VNC at all).

Actually I don't want a VNC server -- I want as many layers of protection I can get. By definition we're protecting against things that shouldn't happen anyway. Just because some program shouldn't be running or shouldn't be listening on a socket doesn't mean it doesn't. Clearly this pre-auth bug shouldn't have happened but it did.

 

[bzgnyc2]

personal alternative: never installing Tahoe to begin with

My 2019 iMac doesn’t support it anyway guess I’m not screwed lol

It's not a Tahoe-specific security vulnerability. It was patched in Sonoma, Sequoia, and Tahoe. I bet it existed in many prior versions of macOS as well.

 

[Cloudane]

Generally people behind NAT (a router) should be okay with a few caveats:

* make sure the port isn’t forwarded. Hot take, no one should be forwarding ports on their home network in 2026. This kind of incident is exactly why. If any service requires it, consider switching to something that doesn’t. If you need to connect in from outside use Tailscale or some other VPN.

* Check uPNP. I’m not sure if macOS triggers it, but if it’s enabled it allows things to open ports dynamically for you. It’s insecure and should be disabled in the router these days.

* Old versions of macOS might have the old “connect from anywhere” service, I think it was called Back to My Mac, hopefully that used a tunnel and it’s probably not available on any version now but one to keep in mind if running an ancient version.

 

[bzgnyc2]

Having fewer vulnerabilities = more secure. Even when having fewer vulnerabilities means fewer features. Non-macOS operating systems offered by Apple doesn’t expose port 5900, so not only are they not vulnerable, they can’t be MADE vulnerable to this exploit (unless the user takes steps that aren’t available to non-developers).

If you want to call an OS with one bug fixed a more secure OS sure go ahead. But it feels like talking about infinity + 1.

Agree that iOS, iPadOS, etc are more secure out-of-the-box by virtue of having less surface area (and practically speaking its a lot of work to secure macOS to the same level). However, I do wish that iOS/etc had a real firewall and it was enabled by default.

 

[CharlesShaw]

I always feel more vulnerable on Mondays, so may as well add some more anxiety about what could go wrong.

 

[Unregistered 4U]

If you want to call an OS with one bug fixed a more secure OS sure go ahead. But it feels like talking about infinity + 1.

Agree that iOS, iPadOS, etc are more secure out-of-the-box by virtue of having less surface area (and practically speaking its a lot of work to secure macOS to the same level). However, I do wish that iOS/etc had a real firewall and it was enabled by default.

Yeah, it’s an iterative thing and the macOS will trend towards greater security. Between .kext’s being supported and today, macOS is more secure, but it will never be as secure as their non-macOS operating systems due to macOS users desiring a less secure system.

 

[now i see it]

Screen sharing is off by default and pretty much nobody uses it anyway.

 

[CarAnalogy]

In practice, I haven't found Windows's scopes of Domain/Private/Public to be that great (for example, it's not very transparent which external hosts it considers to be in which scope, and don't get me started about the Scope tab, where you can add IP addresses, but not host names, the dialog is not resizeable no matter how long your list, and there's no way to add comments, so you end up with this giant list of IP addresses).

But… yes. macOS's built-in firewall is even more limited. I also don't love that most of its settings are now cramped inside a sheet.

(edit) Having said that, this is irrelevant for most users anyway. Almost nobody actually has their Mac publicly exposed — at home, you'll likely have it behind a router, and even if you don't, your ISP may put you behind CGNAT. At work, there will probably be some form of NAT, too.

But it would be nice if, when explicitly allowing port 5900, there'd be another layer that restricts "do you want this for the local network? Or anyone on the Internet?", etc.

Yeah I should clarify that the actual Windows firewall management itself is still not great I mostly meant the firewall profiles being built in and locked down by default.

Hopefully anyone who has 5900 open did it on purpose and for a reason (which unless it's a honeypot is beyond me).

Reminds me of back in the day when people had RDP exposed to the internet all the time. Some still do. Mostly because some out of practice "IT person" did it a long time ago.

I don't think macOS makes a uPNP request to open that port, but some home routers are either too "helpful" or compromised.

 

[iamasmith]

I would like to know that too. Most internet routers should block incoming connections from the Internet by default. Unless you explicitly forward all (or selected) ports to your Mac of course. But the article above is very not clear about that.

I haven't seen the exploit specifically but if screen sharing handshake was the target for the attack and some of that surface was cloud based and screen sharing used Hole Punching https://en.wikipedia.org/wiki/Hole_punching_(networking) then public attacks even behind your router's NAT could still be very real. Given the nature of the fix being a Mac update rather than a Cloud service update (they have had to do that too??) I think you are correct though.

 

[Speed38]

I am a senior who helps other seniors in two aging-in-place communities who are barely computer literate and are all spun up about this exploit. I'd be obliged if someone could tell me if they go to https://www.grc.com/default.htm and on that site continue to https://www.grc.com/x/ne.dll?bh0bkyd2 (Shield Up) and do the UPnP Exposure Test, the File Sharing Test, the Common Ports Test, the All Service Ports test and pass all with flying colors, may I tell them with confidence that they can attend Zoom sessions and share their screen with TRUSTED individual? As for my own M5 MB Air running the latest version of Tahoe, I found that port 515 (Printer) and 63 (IPP) also printer-associated were open. I presume I do NOT want to close them??

 

[chucker23n1]

Reminds me of back in the day when people had RDP exposed to the internet all the time. Some still do. Mostly because some out of practice "IT person" did it a long time ago.

Well, RDP's security layers were vastly improved in Server 2008, which has been a while.

Really, the only two alternatives are a) route everything through SSH instead (which puts a lot of trust in that protocol), or b) use a VPN (which… same thing).

I don't think macOS makes a uPNP request to open that port, but some home routers are either too "helpful" or compromised.

I'm not sure macOS has any UPnP client at all; Apple prefers Bonjour. (And has mostly abandoned things like Back to my Mac.)

 

[Steve Adams]

Well those aren't Apple's but I agree with you as far as well-configured Linux machine. OpenBSD better but partially because it doesn't do as much...

That was sort of the joke. But in all honesty, there seems to be way more security flaws for Apple these days than any other platform out there. Both in mobile and compute space.

 

[chucker23n1]

there seems to be way more security flaws for Apple these days than any other platform out there. Both in mobile and compute space.

I'm not sure how you would measure that.

Another way of looking at it is that iOS is used by some extremely valuable targets.

 

[Radeon85]

And this is why you should always keep your OS up to date, even if you don’t like it.

 

[inventor7777]

It might should be noted that several ISPs in the U.S. (at least), eg Comcast, have been enabling IPv6 on their consumer-rented routers without really advising customers that it is happening, or requiring opt-in. WHEN this happens, while there IS a firewall that runs on the router, your LAN-local devices that were once 'protected' by an IPv4 NAT firewall suddenly are ass-out on the internet, relying nearly entirely on whatever firewall is running locally, IF a firewall is even running locally. Worse, older hardware—like multifunction printers—often had IPv6 enabled, but often not particularly well-tested (ie buggy), and had firmware vulnerabilities and static passwords (or passwords based on MAC address) that attackers have long since targeted… this gives an attacker a secondary vector: they get control of a mfc, and can then jump (from inside the same subnet) to other vulnerable devices that would ordinarily have been protected by firewall, but because firewall rules often allow LAN-local peer-to-peer communications (as Apple's firewall in macOS does), are bypassed.
This problem is going to get worse as more ISPs do this nonsense and A.I. fuzzes out more and more vulnerabilities in older code. IPv6 is great, but it cannot and should not be entered into lightly. And irresponsible ISPs have been throwing non-tech-savvy customers into the deep end of the pool without floaties.

Really? If they are enabling IPv6 why wouldn't it have a global inbound firewall? Have you actually seen that happen?!

I thought that blocking unsolicited inbound connections would be the default behavior of basically all relatively modern routers. At least that is the behavior I saw on my previous Asus router, a TP-Link router, and my current OPNsense, because you can run a firewall without NAT.