61–70 of 158 posts
"Description: A logic error existed in the validation of credentials. This was addressed with improved credential validation." I hope they won't stop to this brief summary, because a "logic error in the validation of credentials" shouldn't be able to allow the creation of a root super user with empty password. I'm hope they'll go deep in the gory details, to show us how it's in fact much more complicated than a "if !…
I heard the bug was working on El Capitan for some people [1]. Some Mac devices aren't able to upgrade past El Capitan; will they just forever have this vulnerability? [1] https://news.ycombinator.com/item?id=15800817
Earlier quoted context omitted.
I read that it worked even with Remote Management and Screen Sharing. https://twitter.com/voretaq7/status/935609138725425153
Yep. We blocked VNC at the border routers. Now you need to use our VPN in order to use VNC. And we are very glad to know we can triage and log. Yeah internal users could still exploit machines. But that fact is recorded. Fired and criminal charges are not a light thing.
Earlier quoted context omitted.
Once the exploit is done (clicking the unlock button w/ the user root on the settings pane), the root account is setup with a blank password. At this point any remote access methods that use the accounts on the system should allow access. Depending on SSH config, root may be disallowed. I've seen rumors otherwise, but until someone with experience verifies those pathways I can only guess.
Not any method. It worked for screen sharing but it did not for SSH, even after the bug was triggered locally.
PermitRootLogin no
/private/etc/ssh/sshd_configI heard the bug was working on El Capitan for some people [1]. Some Mac devices aren't able to upgrade past El Capitan; will they just forever have this vulnerability? [1] https://news.ycombinator.com/item?id=15800817
Apple says "Not impacted: macOS Sierra 10.12.6 and earlier" in their security advisory for the patch.
Earlier quoted context omitted.
Yep. We blocked VNC at the border routers. Now you need to use our VPN in order to use VNC. And we are very glad to know we can triage and log. Yeah internal users could still exploit machines. But that fact is recorded. Fired and criminal charges are not a light thing.
So you log and audit this kind of unusual event, but you didn't require VPN access for critical resources?
This policy applies to everyone. Students, faculty, staff. Previously, a student could set up VNC to allow remote access to their machine in their dorm. Now it takes VPN to do so.
Earlier quoted context omitted.
Actually entering blank passwords and automated password entry should be Test Cases #0 and #1 for any thing that has a login. OS and other critical infrastructure vendors should go beyond that and explore the vast space to make sure nothing like this ever happens.
They may have even had a test case that entered "root" and no password and hit OK once , but that wouldn't have caught it. What if you'd had to hit "OK" forty-one times to trigger the bug? It's deeply unsatisfying to just say "the problem space is so vast that it's hard to even know what to try beyond the basics that every QA person knows" but I don't personally have a better answer than that. Maybe those that study…
Earlier quoted context omitted.
I don't know how you could expect QA to be able to have a rigorous process to catch security problems of this type. It's one thing to audit the strength of crypto protocols, quite another to rigorously test every conceivable attack surface for privilege escalation. That space is vast.
Actually entering blank passwords and automated password entry should be Test Cases #0 and #1 for any thing that has a login. OS and other critical infrastructure vendors should go beyond that and explore the vast space to make sure nothing like this ever happens.
But that's the nasty thing about InfoSec. It's a never-ending process. There's always realms you haven't considered yet. I'd bet that they had a process in place that they thought could catch these, but it managed to fail somehow. You're always in a hindsight-is-20-20 situation.
Earlier quoted context omitted.
Actually entering blank passwords and automated password entry should be Test Cases #0 and #1 for any thing that has a login. OS and other critical infrastructure vendors should go beyond that and explore the vast space to make sure nothing like this ever happens.
They may have even had a test case that entered "root" and no password and hit OK once , but that wouldn't have caught it. What if you'd had to hit "OK" forty-one times to trigger the bug? It's deeply unsatisfying to just say "the problem space is so vast that it's hard to even know what to try beyond the basics that every QA person knows" but I don't personally have a better answer than that. Maybe those that study…
Earlier quoted context omitted.
Apple says "Not impacted: macOS Sierra 10.12.6 and earlier" in their security advisory for the patch.
My fear is that Apple doesn't know that it still affects El Capitan, though the poster I linked to could have just been lying.
Apple knows when the bug materialized (sounds like it was part of a UX simplification of migration and/or upgrades) and I'm sure before getting embarrassed yet again they would have done due diligence.
Probably.