Live data from Hacker News

About the security content of Security Update 2017-001

support.apple.com

81–90 of 158 posts

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

#81
post #26
post #23

"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 !…

That's kind of what it was: https://objective-see.com/blog/blog_0x24.html

It seems to me that the biggest problem highlighted by the link in parent is backwards compatibility of authentication metchanisms. OSX seems to support typical /etc/passwd hashed-user-credential authentication. However, it tries to "upgrade" that authentication mode to "shadowhash or securetoken", which appear to be two new auth schemes integrated with Open Directory.

All of those things might be fine, on their own.

However, the biggest issue is that there are now more than one primary way to get authenticated on the system. This is likely true because network accounts need to be supported in addition to local ones (I.e. apple accounts, LDAP accounts, etc.). However, my (admittedly uneducated) impression is that the systems for handling those accounts are totally separate--the part of the auth system that is swappable between shadowhash/old-school-passwd/etc. is . . . basically the whole auth system.

I'm sure that's a very quick and easy way to write authentication code, and it also preserves backwards compatibility of users doing the old method, but it seems inherently prone to more issues (even if you don't make screw-ups as obvious as this one). You have more auth stacks (and thus code) to debug in total, to say nothing of code that migrates credentials between different auth stacks.

Preserving backwards compatibility is important, to be sure, but only sometimes. This seems like a case where things would have been easily mitigated if Apple had done something like "everyone must sign in with their Apple account, now, as the sole authenticating credential for this operating system" during some OS upgrade (or "/etc/passwd no longer works; all these systems have been refactored to use a single central credential database in Keychain Services, update any code that cares since it's being aggressively deprecated", though that would probably have been both harder to implement and harder to sell to the user/developer-base). However, I'm far from an expert here, so maybe the "just expand on the existing UNIX local auth system" option is less-infeasible than it seems (linux ditched this too for network accounts, though, which doesn't give me confidence).

Either way, an old-auth-system removal like that would have crippled some of my workflows/code, and others', but it also would have allowed Apple (if they followed it up with a dead-systems-removal pass) to remove many of the then-redundant authentication systems in OSX.

TL;DR Linus isn't always right, backwards/userland compatibility shouldn't always be held paramount, especially when you're developing parallel systems for something as critical as authentication. Sometimes the pain caused by deprecation is worth the removal of a security risk.

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

#82

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…

Where are all the unit/integration tests for the APIs that this damned button is calling? Hindsight being 20/20, but I cannot imagine not asserting that a newly created/re-enabled root user has a non-empty password.

I don't think empty password on root is the issue here; enabling root when the user did not intend to and did not have permission to is. Isn't empty password for root a default state for systems where direct root login is not enabled? And isn't enabling root with no password the intended behavior when booting into Single User Mode?

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

#83
post #58

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)

it's all part of the fun

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

#84

Earlier quoted context omitted.

I'm no journalist, but I guess that being first to report is more important than minor errors in the article.

I don't know what timezone the article is in, but it's been at least an hour. Even if "post, then edit" were the strategy, the author clearly didn't read it after hitting publish either.

Most writers for online establishments have quotas of multiple articles/day, these days. Don't blame the writer.

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

#85

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…

Where are all the unit/integration tests for the APIs that this damned button is calling? Hindsight being 20/20, but I cannot imagine not asserting that a newly created/re-enabled root user has a non-empty password.

Exactly, testing the UI may be hard, but whatever API that UI is calling is amazingly horribly broken.

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

#86
> 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...

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

#87

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…

Check the dictionary -- "login" is also used as a verb: http://www.dictionary.com/browse/login?s=t

With a usage note that some people dislike it:

> And yet, this gluing together of terms like login, logon, backup, and setup as verbs is common, especially in writing about computers. Not for everyone, however. Some well-known software companies, for example, carefully maintain the distinction in their programs and documentation. But habits are difficult to change. Those who react to the one-word verb as an error will probably have to get used to it, and those who use the one-word verb will have to recognize that others will see it and wince.

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

#88

> 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...

I realise that this is a facile topic for engendering scandal amongst our geek demographic (and rightly so), but given the gravity of the underlying issue it’s actually entirely reasonable and indeed preferable to the alternative scenario of N hundred million insouciant users lagging behind with a gaping security hole.

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

#89

> 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...

People weren't upset about windows installing security updates. If this update adds nagware to OSX or forces people to restart their computer in the middle of whatever they are working on, your comment will be a fair point. Until then, it is an stupid comparison.

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

#90

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…

Where are all the unit/integration tests for the APIs that this damned button is calling? Hindsight being 20/20, but I cannot imagine not asserting that a newly created/re-enabled root user has a non-empty password.

Following and furthering your logic, what the hell could they have been doing in the codebase to revert a control mechanism that was effective up to and including 10.12.6, but unsafe as of 10.13.0 onwards???
Post reply on HN