301–310 of 1001 posts
I still can't believe more people complain about this being publicly disclosed than this being possible in the first place. No one is obligated to know the procedures on InfoSec 0-days and follow those steps.
My guess is he found this vulnerability on accident, freaked out, and tweeted about it. Probably has limited infosec experience.
Excuse my language, but this was a dick move to post this publicly, especially on Twitter. Go through private bug channels properly for something as serious as this. Of course doing it that way doesn't give you your 15 minutes of interweb fame.
When I put it into my personal malice / ignorance balance, it weighs out to the likelihood that the discloser isn't plugged in enough to the infosec scene to be aware that there are already best practices for this kind of disclosure. It's a big world out there, especially nowadays. And nothing I've seen in recent history suggests to me the average user knows or cares about infosec concerns beyond basic hindsight unde…
I wonder what is going on with software quality and testing at Apple. It feels like recently there have been quite a few issues like this (the FileVault password bug, numerous issues with iOS 11, the issue that totally broke iOS Safari a couple of years ago) which should have been fairly easily caught, especially given the limited range of devices their software runs on. I know testing is hard, but a company with App…
Insufficient testing at today's Apple is not limited to software. They bragged about their extensive input testing lab [0] when the new line of Magic accessories was released, but the Magic Keyboard with Numeric Keypad launched last summer had all of its inventory pulled from the channel last month because users discovered that the model was so thin that its midsection bowed over time.
[0]: https://medium.com/backchannel/what-i-saw-inside-apple-s-top...
I'm guessing it probably would've been a fairly big chunk of change.
Earlier quoted context omitted.
This bug exists regardless of user reproducing it or not. If there is anything good, reproducing it actually brings awareness to the user (make them change the password maybe). Hacker will "enable" the root user anyway. What should be done is that Apple releases fix to this problem.
Not the case. Once you enable root access - by 'testing' this - others can remotely & silently access the system as root. GP is right - don't encourage people to test this, as there's nothing to gain from it. If you're on a shared machine you need to mitigate. If you're on your own dedicated machine you need to not share it until this is fixed.
That's not accurate. The user appears to be there either way, but attempting to log in to a machine remotely using 'root' and no password does not work - even after doing the preference pane thing...
I wonder what is going on with software quality and testing at Apple. It feels like recently there have been quite a few issues like this (the FileVault password bug, numerous issues with iOS 11, the issue that totally broke iOS Safari a couple of years ago) which should have been fairly easily caught, especially given the limited range of devices their software runs on. I know testing is hard, but a company with App…
If you have `osquery` deployed to your fleet you can detect compromise with this query: SELECT * FROM plist WHERE path = "/private/var/db/dslocal/nodes/Default/users/root.plist" AND key = "passwd" AND length(value) > 1;
Am I missing something or does this require the attacker to have access to an unlocked computer? In which case all bets are off anyways.
>In which case all bets are off anyways How are all bets off if they don't have access to a root user? This isn't Windows we're talking about.