| it's a vnc port, it'd also require the router to have it opened. Reading the article I think the user opened it themselves.
It does get opened automagically on the mac side when screen sharing is turned on. > The problem is that for my particular use case — a headless, always-on Mac Mini that I primarily access from other computers and my phone through the ChatGPT and Claude apps — macOS is incredibly hostile > As noted by the NCSC, the vulnerability is being exploited when port 5900 is exposed to the Internet. When screen sharing is turned on, the macOS firewall opens the port. Routers and dedicated firewalls generally block the port unless configured to override that setting. > Obviously I should have — and will be — using a VPN going forward (the foundation of my entire approach to security is Tailscale); what I will note, however, is that TCC basically leaves me no choice but to have screen sharing enabled if I want to actually use my Mac Mini in the way I want to use it. I use screen-sharing constantly — including from my phone — and almost every time it’s to click “OK” on a stupid prompt that I’ve long since stopped taking seriously. |
| |
| ▲ | fg137 a day ago | parent [-] | | > Obviously I should have — and will be — using a VPN going forward That's my takeaway from the article. I have trouble understanding how the author managed to extrapolate all these things about Apple from an obvious oversight on their part. I would never write a 3,000-word article about how bad someone else is because of an issue I caused for myself. Software WILL have bugs and vulnerabilities, regardless of whether it's an OS or user application, whether it's from Apple or another company, or the update frequency/mechanism. If you can't even follow the most basic security practice on your part, you simply don't have any authority to discuss security otherwise. | | |
| ▲ | user43928 a day ago | parent | next [-] | | Disagree. Apple's remote access feature, that you would make remotely accessible for obvious reasons, apparently had a critical authentication bug. Apple did not ship a security patch for this, allowing the vulnerability to be exploited a week later despite "automatically install security updates" being on. Yes, OP could have prevented this by putting an additional VPN authentication layer in front of the Mac's built-in remote access. That doesn't excuse the mistakes on Apple's part. | | |
| ▲ | fg137 a day ago | parent [-] | | > That doesn't excuse the mistakes on Apple's part. Let's first establish that Apple definitely has a stake in this. How long they can come up with a fix and then distribute them, that's a question. You can't expect any company to fix a vulnerability within 5min. Whether one week is too long or their delivery mechanism is good, I can't tell, and I don't think there is a standard in the entire industry. That doesn't mean it's useful to write an article about "I didn't do my part BUT you are too slow". Even if Apple somehow fixes this within an hour of the disclosure and delivers the update, with the bad configuration, the machine is still vulnerable within that window. Does that change the nature of the narrative? | | |
| ▲ | dannyw 13 hours ago | parent | next [-] | | Yes, the timeframe does matter. An actively and easily exploited (just a port scan), and high-impact root RCE needs faster patching than one week. When there was a more user visible bug (2017, empty root password gives you root, CVE-2017-13872), Apple managed to remotely patch this across all supported macOS versions in about 26 hours + next macOS online, end to end, without user intervention or manual updates. And that was a decade ago before Apple built “rapid response security updates” | |
| ▲ | user43928 a day ago | parent | prev [-] | | I don't think anyone criticized the timing of the patch. But I find it egregious that they didn't roll it out as a security update at all, which is why it was not automatically installed in OP's case, even though the fix was already available. I mean, what else requires a hotfix via security update if not a fatal flaw in your remote access authentication leading to full root access, that is actively being exploited in the wild? Also, it's not really on the user to gate remote access behind an additional firewall and authentication layer. This is something that just has to work securely. If it doesn't, that's understandable, but still hardly the user's fault. | | |
| ▲ | fg137 a day ago | parent [-] | | > what else requires a hotfix via security update if not a fatal flaw in your remote access authentication leading to full root access, that is actively being exploited in the wild? > Also, it's not really on the user to gate remote access behind an additional firewall and authentication layer. This is something that just has to work securely. About that, I have a bridge to sell. |
|
|
| |
| ▲ | someguyiguess a day ago | parent | prev | next [-] | | > I would never write a 3,000-word article about how bad someone else is because of an issue I caused for myself. Welcome to hacker news! | | |
| ▲ | otterley a day ago | parent [-] | | In this case, the author literally writes blog posts for a living. This just happened to be a free article, and, well, you get what you pay for. |
| |
| ▲ | mrheosuper 17 hours ago | parent | prev [-] | | Most of "basic security practice" assume that software does not have or have very few, hard-to-discover bugs. For Ex, the best practice is to use VPN, so you only open port for VPN, and you assume whatever VPN protocol/software does not have any bugs. You can use tailscale so you dont have to open port, but after all, tailscale is also software. |
|
|
