Live data from Hacker News

About the security content of Security Update 2017-001

support.apple.com

151–158 of 158 posts

Re: About the security content of Security Update 2017-001

#151
post #142
post #55

Earlier quoted context omitted.

I've enabled root myself and set password on it. After installation of the patch root account was disabled.

Wow. Automatic security update locks me out of my computer without any explicit notice given. How very nice of them.

So you have only one user on your Mac and that user is named "root"? Really? That would be very strange.

I'm fairly confident most Mac users never enable the root account at all. We don't need to. I'm not sure people who've only used other Unix systems understand that; I didn't when I came to the Mac after using Linux and FreeBSD in the 1990s. You need an administrator account, but that's not really the same thing. I haven't had a root account enabled on a Mac in about 15 years. (Well, except for a 14 hour or so stretch from yesterday evening to this morning, between the time I enabled it with a strong password as a "fix" for this bug and the time the actual fix was pushed by Apple.)

At any rate, I'd be very surprised if there was even a single user literally locked out of their Mac because of this change. I think it'd have been better on general principle if they'd done some kind of check that boiled down to "if the root user is enabled but it doesn't have a password set, disable it, otherwise leave it enabled," but there may be perfectly valid reasons that they couldn't do that.

Re: About the security content of Security Update 2017-001

#153

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…

Oh it's never that easy. It happens 20 layers deep, with configuration set a certain way... only every Friday the 13th.

I.e. MacOS is based on UNIX/BSD, root is all powerfull. So root is disabled form login with password, but it's still there. Then there is the Apple autentication framework on top of that, here root is disabled. But if you try to log in with root, it gets enabled but can't login because password is still an disabled. Then somebody decides new password hashes are safer and we should update old hashes whenever possible. So now when a disabled root account gets enabled, the update routine mishandles password and updates the root password hash with .

Re: About the security content of Security Update 2017-001

#154
post #145

Earlier quoted context omitted.

Really? How do you do that? My windows machine informed me it was going to install the fall creators update when I shut it down for the night with no option not to (only to choose a different 8 your max active period)

Argh! It looks like it's only an option on Pro, my Home machine doesn't have it. That's lame... It's under Settings -> Updates & Security -> Advanced Options on Pro.

That is the really worrying trend in personal computing as of late. Treat consumers like dumb sheep, and "professionals" are barely competent children (only devs are "responsible adults", according to themselves)...

Re: About the security content of Security Update 2017-001

#155

Earlier quoted context omitted.

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…

> but they're still supporting it better than Microsoft manages to support Windows. I don't know what metric if any you're using to make that statement but any person working Enterprise/Corporate IT will tell you what MS manages to pull year over year with Windows, Office and bunch of other stuff is fairly monumental given the demands of their operating space. Only way Apple can survive there with their current Engin…

I bet Microsoft really does do a great job supporting corporate users. Apple does a miles-better job supporting consumers.

Re: About the security content of Security Update 2017-001

#156

Earlier quoted context omitted.

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…

No way. Microsoft has teams of people who own features. Their errors tend to be regressions related to some other workaround they need to support. 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.

> Apple leaves stuff to rot, then marketing cooks up some new requirement and a few programmers rush to build it.

Is this actually true? I have a hard time believing that. Are Apple developers really jumping around product to product? I'd be very interested to get some insight into their internal processes.

Re: About the security content of Security Update 2017-001

#157
post #127

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…

That approach works for behavior and UX, but is woefully inadequate for security, sadly. The space for shenanigans is exponentially greater.

Re: About the security content of Security Update 2017-001

#158
post #142

Earlier quoted context omitted.

Wow. Automatic security update locks me out of my computer without any explicit notice given. How very nice of them.

So you have only one user on your Mac and that user is named "root"? Really? That would be very strange. I'm fairly confident most Mac users never enable the root account at all. We don't need to. I'm not sure people who've only used other Unix systems understand that; I didn't when I came to the Mac after using Linux and FreeBSD in the 1990s. You need an administrator account, but that's not really the same thing. I…

> So you have only one user on your Mac and that user is named "root"? Really? That would be very strange.

It might be the only local user with a password set, with all other users coming from a remote directory service. Think university labs.

Also, you can always pardon a single incident. But Apple got so aggressive with casualties caused by their system updates that I'm really pissed off by it.

System updates regularly reset configuration to factory settings, breaking things in the progress. Note that I'm not talking about modified system files (those we expect to get reset and thus try hard not to touch) but documented configuration points.

This arrogant mindset is best described as "you surely didn't meant to deviate from our divine default settings, so let me fix that for you!".

For some files they recently started to move your modified files out of the way (creating a backup blah.conf.$(date) or whatever) before forcing the factory config anyway. Not that we need it, but it's probably all we'll ever get.

Post reply on HN