121–130 of 158 posts
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
See Apple's comment on this, given to BuzzFeed I assume: https://twitter.com/JohnPaczkowski/status/935909264362586112 / https://www.buzzfeed.com/josephbernstein/apple-released-a-pa... "Security is a top priority for every Apple product, and regrettably we stumbled with this release of macOS. When our security engineers became aware of the issue Tuesday afternoon, we immediately began working on an update that closes…
Why is all communication from Apple on this case, both yesterday and today, being channeled via screenshots of text appended to random twitter users posts or blogs? It's weird that there's no official page on apple.com for these statements. (Beyond the actual "security update 2017-001" announcement webpage, which wasn't published until the patch was available)
disgusting.
Earlier quoted context omitted.
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…
But if the 2nd attempt does something different, there must be some sort of logic happening, and whoever built this magic (maybe it's an if-block like: (if loginAttempts++ > 0) ... ) should've tested it. We cam see that the function f(a, b) { return a+b; } should return the same value for the same a and b, so testing that once is enough. But if there's something in there that reads a global variable, maybe check who…
Earlier quoted context omitted.
That last sentence [0] suggests that the patch will disable every single activated root account. [0] > If you require the root user account on your Mac, you will need to re-enable the root user and change the root user's password after this update.
Which could lock some users out permanently if the root user was the only user they knew the password to.
If you can get in from an install CD, you can reset passwords as needed.
If I were writing this patch, I'd probably check to see if the root user's password was indeed blank, but given that use of the root account only is extremely unsupported I cannot get too upset about Apple breaking that use case as long as you can get back in.
> it will be automatically installed on all systems running the latest version (10.13.1) of macOS High Sierra So uh... where are all those people who lost their mind about Windows 10 forcing updates? http://i2.kym-cdn.com/photos/images/newsfeed/001/042/619/4ea...
Apple still allows users to control their system's update behavior. "Install system data files and security updates" is turned on by default in the App Store Control panel, but the user can turn it off if they (unwisely) wish to. In Windows XP, for example, Windows Update had a similar option, but that was removed in Windows 10.
(BTW the patch doesn't require restarting the machine, so it's not going to interrupt anyone's workflow)
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.
And I'm sure they've had privilege escalation vulns before and a workflow already in place for catching a lot of them. I mean, it's not like Apple's totally asleep at the wheel here. OSX may not be a front-burner project anymore, but they're still supporting it better than Microsoft manages to support Windows. But that's the nasty thing about InfoSec. It's a never-ending process. There's always realms you haven't con…
Apple leaves stuff to rot, then marketing cooks up some new requirement and a few programmers rush to build it.
Disk utility is the canonical and obvious example of this. There are many others.
Earlier quoted context omitted.
> We are auditing our development processes to help prevent this from happening again. That's great to hear even if it took multiple stumbles for them to finally admit - but surely they should be also audit their QA/testing processes? Or does development in AppleSpeak mean everything?
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.
It was a company that you never heard of. It's a normal thing for me to require such things from QA.
I also worked in big corporation that you heard about, developing embedded software. Same thing happened.
Testing is doing things that most users do. But most of all testing is monkey bashing trying to break the thing. That's the mindset that QA must have.
EDIT: typos, thanks
Earlier quoted context omitted.
Apple still allows users to control their system's update behavior. "Install system data files and security updates" is turned on by default in the App Store Control panel, but the user can turn it off if they (unwisely) wish to. In Windows XP, for example, Windows Update had a similar option, but that was removed in Windows 10.
AIUI the expectation is that Apple is going to force all 10.13.1 machines to automatically upgrade themselves regardless of settings. This is something they've apparently done once before, with an ntpd remote vulnerability. Given the nature of this bug, forcing all machines to automatically apply this patch seems like the right move. (BTW the patch doesn't require restarting the machine, so it's not going to interrup…
Here's an article discussing their first use of this mechanism.
https://www.computerworld.com/article/2862976/apple-deploys-...
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.
I worked on mobile games few years back. Our tester always did everything that was sane and most things that were not sane. For every version. He tried to break the game. He was randomly and wildly tapping the screen. He was repeatedly going through menus. The most things he did us developers thought: who would do that? We caught lots of bugs this way. It was a company that you never heard of. It's a normal thing for…
Earlier quoted context omitted.
Off-topic, but it blows my mind how poorly proofread many articles are nowadays. In this example, there's a 3-word sentence fragment - "That login gave" - hanging out in between two other sentences. If the author even read what he'd written once before posting, he ought to have caught that.
The ability to write is largely ignored at tech firms these days. Grammar is viewed as a bunch of stodgy rules to be ignored at will. Some are indeed silly throwbacks, but the basic structures are what allow us to communicate effectively. Drop them and errors in understanding creep into nearly every email. Yesterday I had a back-and-forth with a boss over "login", "log in", "log in to" and "log into". That might seem…
Dutch has this much more systematically than English, where when this happens you can form the infinitive for the verb by prepending the verb with the preposition. So "someone who breaks in" would be an "in-breaker" and the infinitive form is "to in-break". (In modern English one would have to say a "breaker-inner" to convey the idea of one who breaks in.) Similarly the Dutch might look at the verb "with-hold" and assume that you would say "the company held with that information, not disclosing it" rather than "the company withheld that information."
Anyway, since the verb is "in-log" you "log in", as opposed to the conventional meanings for the verb "logging" (writing down something or clearing trees) where you might "log into" (respectively writing down into, or clearing trees from).