[HN Gopher] Apple neglects to patch two zero-day, wild vulnerabi...
___________________________________________________________________
Apple neglects to patch two zero-day, wild vulnerabilities for Big
Sur, Catalina
Author : jiripospisil
Score : 150 points
Date : 2022-04-05 15:59 UTC (7 hours ago)
(HTM) web link (www.intego.com)
(TXT) w3m dump (www.intego.com)
| mcv wrote:
| Can someone explain to me what "zero day" still means these days?
| I thought it was the time the developer was aware of the
| vulnerability, so once they're patching it or deciding not to
| patch it, it's by definition not a zero-day exploit anymore,
| isn't it?
|
| Or do I understand this completely wrong?
| jedberg wrote:
| Nowadays a 0-day basically means the person who found it
| decided to exploit it instead of report it. So the company
| finds out because there is an active exploit instead of having
| it responsibly reported.
|
| It's shorthand for "an exploit that wasn't responsibly
| reported".
| creeble wrote:
| Yes, it has essentially lost all meaning as most vulns are
| exploited before ever being reported. And even those who
| responsibly report them call them "0-days", which is sort of
| true on the day they report them, but only if the company
| didn't receive any other reports, and why would they divulge
| that information unless they had to, like to give someone
| else the bug bounty? "Sorry, it's actually a 14-day, we're
| working on the fix." Right.
|
| So again, it's lost any useful meaning I think.
| jedberg wrote:
| > as most vulns are exploited before ever being reported.
|
| I don't think that's even remotely true.
|
| And given that it's not true, it's still a useful
| distinction. 0-day means an exploit that is being exploited
| before it was reported to the vendor, which is different
| than most exploits, which are reported to the vendor first.
| creeble wrote:
| I guess it's true that most vulns are either reported to
| (or originate from) a vendor, and that these dominate the
| CVE db.
|
| But naturally, unless you are the vendor, you will likely
| not have heard of these. Otherwise, by definition, they
| would be zero-day vulns.
| Vladimof wrote:
| > Nowadays a 0-day basically means the person who found it
| decided to exploit it instead of report it. So the company
| finds out because there is an active exploit instead of
| having it responsibly reported.
|
| Any vulnerability that was reported and not fixed could
| probably be considered one?
| tylerhou wrote:
| I've always interpreted it as "zero days since a fix was
| released."
| robotcookies wrote:
| I've always interpreted it as meaning no patch is available yet
| for a vulnerability. Does not matter whether a decision to
| patch or not has been made. Doesn't matter if it's been
| exploited yet.
| otterley wrote:
| The author of this blog post is lobbing some pretty serious
| accusations at Apple of being "neglect[ful]" and "deliberate,"
| when in fact it's much more likely that the responsible teams are
| carefully trying to backport the security patches without causing
| regressions. Sometimes a little patience is in order.
|
| But, of course, hysterics get you clicks.
| fartcannon wrote:
| What makes you sure your version is true, while there's isn't?
| They're not your friend, they're a giant, exploitative
| megacorp.
| pjbeam wrote:
| Yes, they are megacorp. In the general case I think that
| working to uphold brand standard is the parsimonious
| interpretation rather than hahaha won't fix.
| naoqj wrote:
| The author of this blog post is not my friend either and they
| sell an antivirus so they are trying to get me to give them
| money as well.
| [deleted]
| fartcannon wrote:
| Fair point. It does appear to be an antivirus software
| blog. Interesting, thank you.
| krnlpnc wrote:
| * Taking extra time for a stable fix
|
| * Rushing out a patch that introduces possible instability
|
| Which action do you think is better for business?
| rob74 wrote:
| That probably depends on the number of users whose Macs get
| pwned in this "extra time" they are taking - I guess these
| users would have preferred a potentially unstable fix to no
| fix.
| unethical_ban wrote:
| Not all theories deserve equal weighting.
| jedberg wrote:
| They are a megacorp which employs actual humans who generally
| aren't evil. The evilness is usually an emergent behavior.
|
| I doubt the security team is sitting there choosing not to
| patch this, given that they are passionate about security.
| And it's unlikely that management has told them "don't
| release the patch, we want the people on old OSs to
| suffer!!".
|
| Most likely is that they just don't have as many resources
| for writing and testing the patch on the old versions, so
| it's taking longer.
| amelius wrote:
| Or their security team is understaffed because of evil
| emergent greedy behavior of the company.
| stjohnswarts wrote:
| Yep this is the reason. Monterrey probably has 10X as
| many people on it.
| sulam wrote:
| This is probably off by a factor of 2 at least. Is if you
| told me that Monterrey has 5x as many users, I'd agree.
| Not 10X. That said, there are likely a sizable group
| (5%?) of customers that _cannot_ upgrade to Monterey.
| Apple should be worried for these customers, too.
| TheKnack wrote:
| Apple invites this kind of reaction by not being transparent
| and not cooperating with the larger security community, for
| reasons that are difficult to understand.
|
| This week's episode of the the podcast run by the Intego Mac
| Antivirus company talked about a new malware affecting Macos
| that was severe enough that Apple released Xprotect signatures
| for it, but didn't provide details to the rest of the security
| community, so anti-virus vendors had to reverse engineer the
| Xprotect signatures to figure out what they were for. Apple
| usually only updates Xprotect for the highest severity malware
| that's circulating widely.
|
| https://podcast.intego.com/233
|
| Most of the tech industry participates in information sharing
| through groups like the Cyber Tech Accord, the Cyber Threat
| Alliance, and several others. Apple is conspicuously absent
| from these groups.
|
| https://cybertechaccord.org/signatories/
|
| https://www.cyberthreatalliance.org/
|
| What reason does Apple have to withhold information about
| vulnerabilities from the rest of the industry? It just puts
| their customers at risk. They have a trillion dollars. There's
| no reason they couldn't dedicate entire teams to disseminating
| information in a responsible way, just like every other tech
| company that you've heard of.
|
| In the case of these Big Sur / Catalina patches, what benefit
| is it for them to not share their plans if they are in fact
| planning to release patches once the "regressions" are
| accounted for?
| sulam wrote:
| Not to take anything away from the other things you're
| saying, but there's a large difference between a company's
| valuation and how much cash plus equivalents they have. Apple
| has roughly $20B, most of their valuation is from other
| things. :)
| otterley wrote:
| > Apple invites this kind of reaction by not being
| transparent and not cooperating with the larger security
| community
|
| Eh, I disagree. While it's fair to wonder what's taking them
| so long, attributing malice or incompetence is unreasonable
| without more evidence than mere delay.
|
| > What reason does Apple have to withhold information about
| vulnerabilities from the rest of the industry? It just puts
| their customers at risk.
|
| I think the jury is out on the conclusion. While Apple is
| unquestionably peculiar with respect to their security
| community engagement, I think most would agree that they also
| have an outstanding overall security track record when you
| take into account the immense number of devices out there,
| all of which are connected to the Internet. It's difficult to
| identify a company that does better (again, relative to the
| overall risk exposure) than Apple in this aspect.
|
| > They have a trillion dollars. There's no reason they
| couldn't [insert anything here]
|
| Money can't buy you everything. Even Apple's war chest can't
| buy them the exact talent they need at the exact time. Talent
| is scarce and often happy and well-compensated at other
| engagements. Same goes for any of the FAANGs, one of whom I
| currently work for.
| chefandy wrote:
| I look askance at hair-on-fire security alarmism but unpatched,
| acknowledged, in-the-wild remote code execution vulnerabilities
| are a pretty huge problem. Indeed, their words are sharp, but
| judiciously applied pressure is warranted.
|
| For some, lagging updates for critical applications render a
| complete OS upgrade infeasible. Apple patching old versions was
| reliable enough to inform security praxis and they should warn
| users about delays, even if the policy hasn't changed.
| KarlKemp wrote:
| There just isn't much software that works on Big Sur but not
| Monterey, if any. It's not like a windows 95 to XP update.
| With yearly OS releases, the ecosystem is somewhat more up-
| to-date and resilient to typical changes.
| jmyeet wrote:
| This is my first reaction as well. Apple has a pretty good
| track record and a strong motivation to fix these
| vulnerabilities. It's a strong accusation to claim they're
| "neglecting" this deliberately and that needs some evidence.
|
| Here's some media literacy training for anyone seeing this: the
| title uses the word "neglecting". It's an odd word to choose
| but extremely deliberate. The author can't say "refusing"
| because that would require evidence as would "downplaying" or
| "dragging their feet". But "neglecting" allows you to use no
| action as "evidence" so you should be automatically suspicious
| of it.
|
| It's the same as "[Big Company] considering [controversial
| thing]". The word "considering" is deliberately chosen because
| it allows baseless speculation... which is the point.
| _-david-_ wrote:
| Apple is able to patch the newest version without regressions
| but not the older versions?
| op00to wrote:
| Every product team I've been on that kept multiple versions
| of a product going would fix the newest first, then the next
| newest and so on down the line until the oldest version got
| fixed. This is nothing new.
| brimble wrote:
| Is it not entirely normal for a version currently or recently
| under active development to be easier to confidently work
| with than something you have to pull out of mothballed
| status? I know good practices improve that situation (the
| "natural" default for which seems to be "lol good luck, you
| may as well re-write from scratch" absent _any_ forward-
| looking effort beforehand), but surely there 's still _some_
| friction that comes with that even in places that handle it
| very well.
| ectospheno wrote:
| Monterey came out late October. You only aren't on it if you
| decided not to be.
| pgwhalen wrote:
| Just checked, I'm not on Monterey, and I can't say I've
| decided either way.
| brimble wrote:
| I just checked and I'm on Big Sur.
|
| It's the reboot, for me. It's just inconvenient enough
| that I put off upgrades for a long time, usually. I
| usually apply iOS updates promptly, because it's much
| easier to say "yes" to those since it's not going to lose
| much useful state on re-boot. Plus they seem to complete
| a lot faster.
| pgwhalen wrote:
| Yeah I'm on Big Sur on my work computer, so I bet it's
| frozen by policy, but I bet it's the same on my personal,
| for the same reason.
| sulam wrote:
| Python 2.7 being removed has probably made corporate
| upgrades very slow.
| wayne wrote:
| Or you have a Mac from 6+ years ago that doesn't support
| it. https://support.apple.com/en-us/HT212551
|
| Apple doesn't support old hardware as long as
| Microsoft/Linux.
| brimble wrote:
| Big Sur should see at least another 18 months of support.
| Admittedly, that's just guessing based on past behavior,
| not a guarantee, which does kinda suck, but in fact it
| will probably see that much more support. Will likely
| remain safe to use for _some_ amount of time past that,
| though who knows how long. Realistically, and accounting
| for 18 months being a bit pessimistic, one might
| reasonably expect another 24-30 months of use with a
| machine that can 't upgrade past Big Sur, before having
| to make some kind of choice (install Linux, install
| Windows, or buy a new machine, I guess)
| haswell wrote:
| This is a very plausible problem.
|
| Backporting to older releases means finding potentially new
| solutions to the same problems depending on where the bugs
| sit in the codebase. This could also mean backporting more
| than just the fix itself, depending on how the codebase has
| evolved.
| jimbob45 wrote:
| Since when should zero-day vulns be treated with patience?
|
| Also
|
| >This isn't the first time that we've observed Apple neglecting
| to patch serious vulnerabilities, or even actively exploited
| ones.
| nipponese wrote:
| When you're "trying to backport the security patches without
| causing regressions". There's no silver bullet for patching
| large codebases at huge organizations.
| bell-cot wrote:
| > "Posted on April 5th, 2022 by Joshua Long [...] Last week, on
| May 31, Apple patched two...
|
| Ah...are the headline vulnerabilities related to date & time
| functions, perhaps?
| donohoe wrote:
| Yeah, I noticed that too. How can you confuse 'May' with
| 'March"?
|
| Update: They fixed it.
| jakear wrote:
| Better source (more technical details, less doomsaying):
| https://sensorstechforum.com/cve-2022-22675-kernel-privilege...
| CameronNemo wrote:
| This is not equivalent whatsoever. TFA's point is that the CVEs
| are unpatched in supposedly supported macOS versions. The link
| you provided just talks about the CVEs broadly.
| jakear wrote:
| Knowing that the ticket is still open is helpful, yes. But it
| can be expressed as a Boolean, dedicating a whole essay to it
| is pointless doomsaying. I'd much rather read the technical
| details and level of access needed to exploit it so I can
| take steps to protect myself.
|
| That a company selling antivirus software is more willing to
| devote an essay to doomsaying than technical info that might
| actually help users is a good indication to look for
| alternative sources.
| paultopia wrote:
| This kind of post isn't terribly helpful to end-users (though I
| guess the audience really is apple, for pressure purposes)
| without some kind of insight into how hard it is to actively
| exploit whatever these vulnerabilities are.
|
| Like, there's a big difference between actively exploited
| vulnerability that requires physical access to the machine or
| conscious user decision to run an untrusted executable, versus
| actively exploited vulnerability that can bite a user when they
| visit a website or read a text message. If these vulnerabilities
| are in the second category, maybe I freak out and upgrade to
| monterey today; if in the first, I just rely on the perfectly
| good lock on my front door until apple backports the updates.
| KarlKemp wrote:
| > Jin observed that M1-based Macs running macOS Big Sur remain
| vulnerable to CVE-2022-22675.
|
| So the first vulnerability affects only M1 macs, all of which are
| compatible with Monterey. There's your patch.
|
| > We have high confidence that CVE-2022-22674 likely affects both
| macOS Big Sur and macOS Catalina. Nearly all vulnerabilities [..]
|
| "High confidence" that it is "likely"? I have "absolute
| certainty" that it is "possible", then.
|
| Sure, it's a reasonable guess. But there's a lot of strongly
| worded outrage in this text. Personally, I'd hedge a bit on the
| accusations until they are shown to be true.
| [deleted]
| CameronNemo wrote:
| This can still help inform decisions for internal IT
| departments. My IT dept has put an update blocker to prevent
| users from upgrading to Monterey, for example. This information
| could help them remove the block.
| jiripospisil wrote:
| Related: "n-1 and n-2: Should we really trust in you?" by the
| same author https://www.youtube.com/watch?v=o5KUvgXHOFU
| HNHatesUsers wrote:
___________________________________________________________________
(page generated 2022-04-05 23:02 UTC)