About the security content of updates for High Sierra, Sierra, El Capitan | Hacker News Reader

About the security content of updates for High Sierra, Sierra, El Capitan

support.apple.com

97 pointscylo32 comments

So I guess the interesting thing here is that if you visit http://webcache.googleusercontent.com/search?q=cache%3Ahttps... you'll see that yesterday's version of this document claimed that the fix for CVE-2017-5754 was "Available for: macOS High Sierra 10.13.1, macOS Sierra 10.12.6, OS X El Capitan 10.11.6" (search for "2018" to find "Entry added January 4, 2018").

Now it just says "Available for: macOS High Sierra 10.13.1". (search for "2018" to find "Entry updated January 5, 2018")

Yesterday's version was wrong: https://twitter.com/lunixbochs/status/949121236428181508

This is the diff: https://twitter.com/lunixbochs/status/949374313978875904

I wouldn't be surprised if they actually do patch soon (someone posted on Reddit about seeing a Security Update 2018-001 beta in their app store).

An example of why I generally jump to the comments on HN before clicking through. Because the OP's info is sorted alphabetically, there's little guidance on what's supposed to be eye-catching, nevermind that what we're supposed to be concerned with is literally not in the OP (as of posting time).

As a comparison:

- Apple was warned about this half-a-year-ago and cannot give certainty that their previously current OS is patched (High Sierra only was announced on June, about the same time they were warned about Meltdown)

- DragonflyBSD, arguably the underdog of the BSD's was not warned about the bug, like apparently all the other BSD's, and now have commited the patch to their current OS version http://lists.dragonflybsd.org/pipermail/users/2018-January/3...

Apple needs to step up their game.

These issues are new to us (not just on Apple). But I wonder how long they have been know to the NSA.

In the past few days there were a handful of links dated as far back as 2006, directly explaining the attack vector, or strongly hinting at it. So, the likelihood that NSA and a bunch of other groups knew is 100%.

Unfortunately, Intel knew, too, and didn't bother fixing it in the next 6 generations of their CPUs since they originally admitted the issue with the Intel Core 2.

Can you provide those links?

Maybe he's referring to this: https://marc.info/?l=openbsd-misc&m=118296441702631&w=2

Just. Wow.

so, conspiracy?

Interesting question. I think it's fairly reasonable to assume that:

1) The NSA knew about it and had exploits for it. 2) Google Project Zero spoke with the NSA prior to releasing the advisory.

An exploit for such a pervasive vulnerability represents a susbtantial asset to one intelligence agency. Right up until the enemy discovers and develops the same capability.

How can you say the likelihood is near 100%?

I'd bet much smarter people work at Google than the NSA.

I would point out that nearly all those smart people at google are working on product teams, not security teams, and that enough good security researchers still go to the NSA.

Also, the NSA still tapped google for up to 6 years, and might have continued doing so to this day if it weren't for Snowden.

But then again, these weren't in his leaked documents so maybe not.

> WH Cyber Coordinator @RobJoyce45 on Intel chip flaw: "NSA did not know about the flaw, has not exploited it and certainly the U.S. government would never put a major company like Intel in a position of risk like this to try to hold open a vulnerability."

https://twitter.com/nakashimae/status/949451178110279680

Well that one statement certainly puts my mind at ease!

So Microsoft, Facebook and Google are not major companies ?

Thanks for this update; Apple has changed the text since yesterday. I pasted the original text just 18 hours ago: https://news.ycombinator.com/item?id=16076658 .

Is Apple screwing up a lot lately, or is it me..?

Information regarding security fixes are published every time there is an OS update. This one is actually from December, although the following was added today:

> Kernel

> Available for: macOS High Sierra 10.13.1

> Impact: An application may be able to read kernel memory

> Description: Systems with microprocessors utilizing speculative execution and indirect branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis of the data cache.

We've updated the title from “Apple retracts confirmation that Meltdown is fixed in 10.12 and 10.11”, which is the sort of thing that makes a fine initial comment but not what the guidelines ask for headlines.

I think that 'About the security content of macOS $SOMEVERSION' is far less useful as a headline.

Whatever the headline is needs to come from the article, and we're more than happy to update it again if someone can suggest a better one.

Although I agree more with the original title, as that would be the exact message I need at this time, I would suggest to then at least also include Sierra, and El Capitan in the title as the fact that the document was updated is most relevant for users of those systems. Maybe reflect that something changed as well. Maybe:

About the security content of macOS High Sierra, Sierra and El Capitan [updated]

Sure thing, we've updated the title to include the other releases, but we'll let the article speak for itself on what was updated and when.

https://www.apple.com/feedback/

Given the current circumstances, it's pretty clear what it is about.

I still see the Google Project Zero mitigations in this list. What did they walk back?

They have changed the document today (Jan 5th) and removed the confirmation that Meltdown was fixed in 10.12 and 10.11. It was previously thought to be patched but can no longer be considered fixed in those versions of the OS with this change.

Can't delete comments, so an actual question will destroy my karma count.. great system HN.

Because it's very easy to see how this flaw came about.

Branch prediction and caching is necessary for modern processor performance and it turns out that these two features can interact in a way that allows software to employ timing attacks to determine memory state for areas of memory that should't be readable.

I think the only more concrete way you're going to determine intentional vs. unintentional is some type of paper trail being exposed.

stop being concerned about imaginary internet points and it won't bother you so much.

Reply on news.ycombinator.com