[HN Gopher] Apple fixes an in-the-wild exploited 0-day (iOS 14.7.1)
___________________________________________________________________
Apple fixes an in-the-wild exploited 0-day (iOS 14.7.1)
Author : jiripospisil
Score : 348 points
Date : 2021-07-26 17:59 UTC (5 hours ago)
(HTM) web link (support.apple.com)
(TXT) w3m dump (support.apple.com)
| fsflover wrote:
| See also: https://news.ycombinator.com/item?id=27946945.
| PostThisTooFast wrote:
| Whatever "0-day" is...
| useragent86 wrote:
| The link says that iPad Air 2 and later are supported. Does this
| mean that the original iPad Air is vulnerable? There must be many
| of them still in use for Web browsing, video, games, etc.
| nicebill8 wrote:
| If this is really critical, it would not be unprecedented if we
| were to see another iOS 12.x.x release.
| slownews45 wrote:
| For sure - I've been impressed here on older device support.
| I've seen 7 year old devices getting updates - 5s etc?
| dogsgobork wrote:
| For anyone curious, Apple has release a few updates for iOS
| 12 since support for some devices was dropped with iOS 13,
| with 12.5.4 being released in June. The iPad Air mentioned
| above being a nearly 8 year old device. Are any Android
| devices of that vintage still receiving any updates?
| SV_BubbleTime wrote:
| It goes both ways. If something is too old to get the fix,
| there is just as good a chance it's too old to have the bug.
|
| Can't say for sure that the exploitable code ever existed on
| that device. Like Win10 0-days not being an issue for Windows
| 7. But...
|
| Yea, I wouldn't bet on it either way.
| richardwhiuk wrote:
| I don't think you can conclusively say either way. iPad Air 1st
| gen only supports iOS 12, which was patched 40 days ago. So
| either they haven't released a fix yet, or it's not vulnerable.
| praseodym wrote:
| IOMobileFrameBuffer has seen a lot of vulnerabilities over the
| years:
|
| https://nvd.nist.gov/vuln/detail/CVE-2011-0227
|
| https://nvd.nist.gov/vuln/detail/CVE-2015-1097
|
| https://nvd.nist.gov/vuln/detail/CVE-2015-5843
|
| https://nvd.nist.gov/vuln/detail/CVE-2016-4654
|
| https://nvd.nist.gov/vuln/detail/CVE-2017-13879
|
| https://nvd.nist.gov/vuln/detail/CVE-2018-4335
| brundolf wrote:
| Even the name just _sounds_ like something that would get
| exploited
| SheinhardtWigCo wrote:
| iOS is hundreds of millions of lines of C and C++, with
| immeasurable ways to feed in untrusted inputs. In that setting,
| it's guaranteed that there will be a constant supply of
| remotely exploitable memory corruption bugs.
|
| The 0-days will continue to drop on a regular basis until OS
| vendors embrace widespread memory safety as something that's
| vitally important to more than just a handful of dissidents and
| journalists.
|
| edit: parent comment previously said "Makes me wonder how
| secure iOS really is", which is what I was responding to.
| praseodym wrote:
| Agreed. What makes this worse is that apparently a single
| component is responsible for so many vulnerabilities over the
| past ten years. One would hope that over the years this
| component would've gotten thorough reviewing and have
| hardening added to make it less exploitable.
| cube00 wrote:
| Looking at web browsers it doesn't matter how much
| reviewing and hardening you do, some of this just can't be
| 100% secured.
| npteljes wrote:
| >something that's vitally important
|
| Why would that be vitally important? They are a business
| selling lifestyle and technology. For them vitally important
| is staying in a profitable business. I think we can agree
| that we're past the point where we can believe that these
| vulnerabilities threaten that. These vulns mean to them, I
| think, only risk. Mitigation will come in a form of some
| patches, and some PR. And the world will go on, continuing to
| circulate these phones.
| zacwest wrote:
| Is the implication here that Apple doesn't value memory-
| safety? Why would you say that?
|
| Apple have created and embraced an entire language (Swift)
| around the idea that things like memory safety are important,
| but you cannot just rewrite an entire operating system
| overnight into a new language.
| SheinhardtWigCo wrote:
| I didn't say that. Their MacGyvered memory-safe iBoot
| implementation [1] shows that it's at least a consideration
| and that they're exploring ways to shore up vulnerable
| components.
|
| Swift is not (currently) a viable replacement for C.
|
| I'm not saying they should rewrite the entire OS
| immediately, but: given the pace at which they're able to
| pump out new marketable features; the massive deployed base
| of iOS devices; and the sensitivity of the data that is
| kept on those devices, I would argue that they damn well
| better have a long-term plan to replace their bug-ridden
| kernel and other important low-level systems, with code
| that isn't vulnerable to classes of bugs that have been
| solved for decades and are frequently exploited in the
| wild. And I'm not just talking about Apple here.
|
| [1] https://support.apple.com/guide/security/memory-safe-
| iboot-i...
| Silhouette wrote:
| _Is the implication here that Apple doesn 't value memory-
| safety? Why would you say that?_
|
| Presumably because they also said
|
| > iOS is hundreds of millions of lines of C and C++
|
| and Apple _did_ write a whole new operating system that way
| not so long ago despite the well-known safety issues of
| doing so. If any company in the world has the resources to
| incrementally rewrite an entire operating system with huge
| numbers of active users so that the attack surface becomes
| progressively smaller, it 's Apple.
| stefan_ wrote:
| Clearly they don't care enough to force their own employees
| to use it, which is how we got the absolute utter crap that
| is a proprietary 802.11 protocol implementation _in the
| kernel_ and the endless streams of ObjectiveC userland
| exploits.
| laumars wrote:
| Counting the number of CVEs to measure the security of a piece
| of software makes as much sense as counting lines of code to
| measure a developer's performance.
| malwarebytess wrote:
| I don't agree with this analogy. It may very well point to a
| fundamental problem with the design of the software, or in
| methodologies employed in its development. In this case a
| reasonable inference could be that Apple's memory safety
| design principles need some re-examination. Hard to tell
| without being on the inside.
| gorgoiler wrote:
| Maybe. Quantifying your counter argument would help. If one
| developer writes 90% of the code there is signal in the
| statistics.
| okwubodu wrote:
| Someone breaking into my house 10 times by jiggling the same
| doorknob a contractor told me they "fixed" would be very
| concerning.
| CharlesW wrote:
| A door would need thousands of doorknobs for that analogy
| to make sense.
| okwubodu wrote:
| No, you would need to admit your current approach is
| ineffective and replace the door and/or the repairman.
| hk__2 wrote:
| > Someone breaking into my house 10 times by jiggling the
| same doorknob a contractor told me they "fixed" would be
| very concerning.
|
| The complexity is not the same. My grandfather is not
| questionning my ability to fix his computer that "breaks"
| once in a while just because I already fixed it the last
| time.
| mox1 wrote:
| But the result is the same!
|
| I don't care how complex the vulnerability is. The
| consequences I do.
| pixl97 wrote:
| Then I recommend you stop using software.
|
| Pretty much every operating system has some fun places
| near its core that are a steady stream of problems.
| joebob42 wrote:
| I think the "counterpoint" here is that that makes an amount
| of sense >0. While it's far from a complete story, and there
| are plenty of edge cases where it can be misleading, it's
| also a metric that will tend to bias in the right direction
| and has a decent relation to what we are trying to measure.
| jonplackett wrote:
| Is there any reverse-engineered write up of how it was done
| anywhere?
| muricula wrote:
| Saar Amar, who works at MSRC, wrote a writeup & POC for what he
| says is the same bug:
| https://saaramar.github.io/IOMobileFrameBuffer_LPE_POC/ He says
| he found it independently.
| yellow_lead wrote:
| Probably not yet. If we're lucky, someone will provide a write-
| up soon.
| mzs wrote:
| >CVE-2021-30807 POC:
|
| int main(){ io_service_t s = IOServiceGetMatchingService(0,
| IOServiceMatching("AppleCLCD")); io_connect_t c;
| IOServiceOpen(s,mach_task_self(),0,&c); uint64_t a[1] =
| {0xFFFFFFFF}; uint64_t b[1] = {0}; uint32_t o = 1;
| IOConnectCallScalarMethod(c,83,a,1,b,&o); }
|
| >Make sure you have "http://com.apple.private.allow-explicit-
| graphics-priority" entitlement and IOKit headers imported.
|
| >Patch for this bug was released with iOS 14.7.1 less than 2
| hours ago. Might be useful for a jailbreak but not sure due
| to the entitlement check.
|
| https://twitter.com/b1n4r1b01/status/1419734844909637642
| xoa wrote:
| As always with patches to something of this level (if it is
| indeed Pegasus related say) it's important to note that if this
| was a rarified targeted-use exploit before it won't stay that way
| for long. Now that Apple has released a patch for it widespread
| reverse engineering will begin immediately and it'll only be a
| matter of time until packaged exploits become part of standard
| mass-use toolkits. Having a patch ready to deploy is great, but
| simultaneously means it's all the more important to get it
| deployed fairly promptly if it's something that could have
| serious root/remote execution potential.
|
| Though I suppose if this bug can be used for a jailbreak there
| may be some people who'd actively want to stay on 14.7 as well.
| It's too bad on iOS Apple forces people to choose between
| security and control of their own systems and doesn't at least
| allow a purchase-time option to have the ability to load ones own
| root signing certificate.
| refulgentis wrote:
| taking note of multiple comments mentioning Pegasus, wanted to
| flag on the top one: this is very unlikely to be a fix for it.
|
| - reported by anonymous researcher
|
| - if it is related, this would be the 2nd of 2 bugs that would
| need fixing. The first is the 0-click escape hatch from the
| Messages sandbox to calling functions on IOMobileFramebuffer
|
| - there is only one bug listed for this release, and it is
| unlikely Apple would publicly flag #2 of 2 bugs was fixed, but
| not #1
|
| - extremely tight timeframe from press reports of _a_ bug to a
| fix deployed, I'd like to think you could get a week turnaround
| on that, but...in practice, at BigCo, that timeframe would
| require moving heaven and earth, and yet still choosing to be
| irresponsible by skipping most of the gates on the release
| process
| [deleted]
| radley wrote:
| > it is unlikely Apple would publicly flag #2 of 2 bugs was
| fixed, but not #1
|
| It's very possible Apple doesn't want to verify that Messages
| was compromised, particularly if they can blame everything on
| something obscure.
| ComputerGuru wrote:
| There isn't a separate "messages" from anything else,
| that's an illusion Apple marketing encourages. iOS is a
| shared-tenancy, general-purpose operating system. A
| vulnerability in any of the core libraries can affect any
| of the apps (first party or otherwise) and a hostile or
| compromised application (first party or otherwise) can
| compromise the entirety of the device and its data.
|
| Whether something is a Messages vulnerability or "something
| obscure" is just marketing spin.
| kall wrote:
| I think the important part is any person can force data
| onto your device via messages. If that is exploitable,
| it's a huge oroblem. That's why people care.
| clairity wrote:
| > "It's too bad on iOS Apple forces people to choose between
| security and control of their own systems..."
|
| moreover, one of the critical vulnerabilities from a user's
| perspective is the network connections that a device makes,
| nominally on behalf of the user, but really on behalf of
| privacy-forsaking data harvesters like google and facebook (and
| even apple themselves, to a certain extent).
|
| jailbreaking is one method users can (potentially) regain a
| modicum of control over their own private information as well
| as block exfiltration from exploited security vulnerabilities.
| kmeisthax wrote:
| AFAIK the current exploitable firmware for jailbreaking is 14.3
| and I'm genuinely surprised that all these exploits for later
| versions aren't trickling down into Taurine or unc0ver.
| jbarrs wrote:
| They probably are, and this bug may already have been known.
| Many jailbreaks are often held back for as many versions as
| possible, since that can allow the jailbreak to target more
| iOS versions with a single exploit without Apple quickly
| blocking it for future versions.
| kmeisthax wrote:
| I guess that retroactively justifies my decision to keep my
| iOS devices on 14.5 at least...
| isodev wrote:
| That really doesn't sound very ethical though. An exploit
| can literally put people in danger. Holding back on
| reporting just so a few enthusiasts can fiddle with parts
| of their phone nobody intended for them to use is plain
| irresponsible... even antisocial.
| Matheus28 wrote:
| If Apple gave people control over their own hardware,
| these enthusiasts wouldn't have an incentive to hold onto
| those exploits
| realusername wrote:
| > Though I suppose if this bug can be used for a jailbreak
| there may be some people who'd actively want to stay on 14.7 as
| well. It's too bad on iOS Apple forces people to choose between
| security and control of their own systems and doesn't at least
| allow a purchase-time option to have the ability to load ones
| own root signing certificate.
|
| That exactly why the jailbreak scene has no incentive to share
| any exploit with Apple and is obfuscating everything. That's
| not great for security but that's a direct consequence of
| Apple's policies.
| richardwhiuk wrote:
| There's basically no difference between a jailbreak bug and a
| 0 day.
|
| Both are vulnerabilities in the sandboxing.
| solarkraft wrote:
| Jailbreaks require 0 days. What's amazing is that they keep
| coming out despite the prices being so high and the game
| already having been played for so long.
|
| Just a shame it won't be in iOS 15.
| Ajedi32 wrote:
| Correct. The issue is that Apple takes security systems
| designed as a defense against local attackers and uses them
| as a bulwark against their own customers.
|
| Come to think of it, maybe that could be the basis of a
| right-to-repair law: companies which sell hardware products
| that restrict functionality or access to those who know
| some secret value must divulge those secrets to the device
| owner upon request at the time of purchase.
|
| The only issue I can think of with a law like that is that
| it'd make DRM significantly less effective, though IMO
| that's not necessarily a bad thing.
| martimarkov wrote:
| I bought an iPhone because of the fact those things are
| mostly hidden.
| kube-system wrote:
| The customer is the biggest security hole. Most security
| breaches these days are social-engineered.
| acdha wrote:
| That's the hard part for all of this: if you are building
| an unlock mechanism the first question you need to ask is
| how you build a UI which clearly communicates to a user
| that they are likely giving control of all of their data,
| location/camera/microphone, etc. to whatever they're
| installing.
|
| The scammers who push malware under the guise of tech
| support, free porn/games, etc. are effective enough to
| compromise millions of people and that's before you get
| to the question of what it'd look like if a government
| started pushing access for monitoring. How many people
| might consider installing something which this guy they
| met in a coffeeshop says will protect their messages from
| government surveillance? Now consider how many people
| might have malware installed by an abusive domestic
| partner, and where control of the device would extend to
| hiding the existence of spyware.
|
| This is not to say that Apple is acting without self-
| interest here, only that I think there's really a pretty
| nasty market failure making it quite difficult to
| reconcile someone being able to make choices about their
| device with a fairly high risk of compromise with
| potentially significant consequences.
| cmg wrote:
| > if you are building an unlock mechanism the first
| question you need to ask is how you build a UI which
| clearly communicates to a user that they are likely
| giving control of all of their data,
| location/camera/microphone, etc. to whatever they're
| installing.
|
| Facebook puts a large "Stop!" warning in the browser
| console when you try to open developer tools with a link
| to https://www.facebook.com/selfxss. I'd be really
| curious to see if that's helped to stop such attacks on
| their side.
|
| Full text: "This is a browser feature intended for
| developers. If someone told you to copy-paste something
| here to enable a Facebook feature or "hack" someone's
| account, it is a scam and will give them access to your
| Facebook account."
| dadver wrote:
| Source?
| kbenson wrote:
| > Most security breaches these days are social-
| engineered.
|
| I don't know why people even bother making statements
| like that here without backing them up, when it's pretty
| obvious the first response is going to be to request a
| source.
|
| So, source please?
| kube-system wrote:
| I made the claim from first-hand experience, but if you'd
| like third party sources, here's one:
|
| https://enterprise.verizon.com/resources/reports/2019-dat
| a-b...
| kbenson wrote:
| Thank you for the link. FWIW, as I understand it, that
| indicates that social is neither the majority, nor the
| most common form of breach, but it is increasing over
| time.
|
| That's the problem with using first hand experience.
| Unless you're doing a statistical review and your
| experience is actually collating data, the chance that
| your experience accurately reflects real world data is
| wildly dependent on the topic, and with one with as many
| variables as this, I would expect the chance a statement
| like that be correct more akin to luck than an correctly
| inferred results from a relevant subset of data. i.e.
| What industry you work in, what your actual job is, and
| what you already know about it is likely to wildly
| influence what you see. Even someone working in the
| security industry is likely to see only a subset related
| to their job/interests.
| Ajedi32 wrote:
| Probably true, but the solution to that must _not_ be to
| treat the user like a child unable to make decisions for
| themself.
|
| If a person _decides_ to give up control of _their_
| device to another person or organization (like the device
| manufacturer) fine, but that should be a voluntary
| decision on the part of the user, not something forced.
| acdha wrote:
| What if that person's "decision" was being tricked by a
| scammer? Or being in an abusive relationship? Or living
| in a surveillance state?
|
| I want people to have more control over devices but there
| are some non-trivial threats which millions of people
| face which are currently defanged by things like the OS
| not allowing malware installs, or hiding the use of
| various sensors or data access, etc.
| Ajedi32 wrote:
| So people might make bad decisions, therefore they should
| not be allowed to make decisions at all?
|
| Sure, do everything you can to educate the user on what
| they're doing and make things as hard as possible for
| scammers, but ultimately it must be _their choice_ who
| controls _their_ device, not yours.
| acdha wrote:
| We don't have absolute freedom in many areas because the
| law recognizes that the general public either is not
| capable of making informed decisions when that requires
| high-levels of skill or when there is a high likelihood
| of bad outcomes due to malicious actors.
|
| For example, if you buy a car there are safety features
| you cannot turn off without major modifications.
| Dangerous tools often have safety guards built-in to the
| design -- for example, my blender doesn't say it's my
| choice whether to keep the spinning blade covered. My
| bank doesn't say it's my choice whether or not to
| identify myself when making a withdrawal.
|
| For most people, iOS limiting the damage when they get
| compromised is a huge plus. Removing that entirely in the
| absolute position is bringing people back a couple of
| decades ago only now the malware will have access to
| their most private moments and data 24x7 rather than just
| their Geocities browsing history.
|
| Now, consider what that means for something like
| unlocking the bootloader. Allowing that means
| undetectable malware, potentially irrecoverable. There's
| not really a good way around that and even if you try to
| inform people at the time they enable it that doesn't
| help if it's done when the device is out of their control
| (abusive partner, boss, police, etc.), and every on-
| screen indicator can be faked by the malware vendor. That
| leaves options like a physical switch in a prominent
| location which most people aren't going to want to pay
| for or see, and are more likely to be used by accident
| than intentionally.
| feikname wrote:
| > Dangerous tools often have safety guards built-in to
| the design
|
| A phone is not, usually, a dangerous tool. Unless you can
| make it explode :)
|
| > For most people, iOS limiting the damage when they get
| compromised is a huge plus.
|
| Then just dont unlock. The unlock would need to be done
| from inside the OS, by the user, not by external actor.
|
| > Now, consider what that means for something like
| unlocking the bootloader. Allowing that means
| undetectable malware, potentially irrecoverable. There's
| not really a good way around that and even if you try to
| inform people at the time they enable it that doesn't
| help if it's done when the device is out of their control
| (abusive partner, boss, police, etc.)
|
| If you have an abusive partner, boss, etc. you're already
| at risk because they will keep looking at your phone
| anyway and you're in no position to refuse. A way better
| solution is to have a burner phone they don't know about.
|
| Agreed with the police point, but I think after getting
| your phone from police you could just clean install iOS
| again to make sure nothing unwanted is there.
|
| P.S. On 2nd hand market, you could just as easily
| reinstall stock iOS once you buy a new phone to prevent
| buying 2nd hand unlocked iPhone with malware.
| heavyset_go wrote:
| > _For example, if you buy a car there are safety
| features you cannot turn off without major
| modifications._
|
| To use a direct analogy with Apple's restrictions on
| users, you're free to modify and flash your car's ECU
| firmware. In fact, it's quite common.
| JumpCrisscross wrote:
| > _the solution to that must not be to treat the user
| like a child unable to make decisions for themself_
|
| There is a wide gap between being unable to decide for
| oneself in the general case, like a child, and being
| unable to decide for oneself due to lack of expert
| knowledge. Sometimes, less is more. Apple built its brand
| on this insight.
| pjmlp wrote:
| The old Internet Explorer full of toolbars, and a
| notification area with an endless amount of background
| services, kind of proves the point that the general
| public are children unable to make decisions for
| themselves.
| feikname wrote:
| These toolbars were usually bundled with legit software
| (Heck, even Java installed Bing toolbar..) behind dark
| patterns where a computer beginner would, understandably,
| not realize they were also installing something else.
|
| As long as the dialog for unlocking your phone would
| clearly state the risks and what it does, unlike those
| toolbars upon installation, I think it would totally be
| OK.
|
| Imagine if you couldnt install Linux on any PC because
| Dell didnt give you the keys to prevent you from hurting
| yourself. Or Apple didnt allow sudo in macOS. Seems kinda
| absurd right? Yet this is the standard for phones.
|
| Also Id like to point out that Android allows
| installation of external APKs (after activating) and it
| didnt lead to a super increase in malware, as user still
| prefer the Play Store, and APK are usually left for the
| more technically inclined user for niche purposes or
| often times Region lock circumventing.
| Spooky23 wrote:
| There probably hasn't ever been a time with more options
| to do just that than today.
|
| The reality is it isn't 1981 and computers aren't toys or
| cloistered academic devices anymore. Mass market
| platforms need to be more secure than 90s era tech
| allowed.
| [deleted]
| Steko wrote:
| > If a person decides to give up control of their device
| to another person or organization (like the device
| manufacturer
|
| Exactly but what you're missing is that with iOS this
| decision is made when you buy the phone.
| rur77r7r7 wrote:
| Doesn't track at all. If a person wants a device with
| that sort of freedom they can buy one or fund one. The
| only reason there aren't devices famous for empowering
| users is because users don't want to have to deal with
| that. It's only techbros and people they scare with
| racist China imagery that care. This 'Must Not' mentality
| is just entitlement.
| mschuster91 wrote:
| > The only issue I can think of with a law like that is
| that it'd make DRM significantly less effective, though
| IMO that's not necessarily a bad thing.
|
| I wonder why movie companies these days _still_ insist on
| shipping DRM garbage. HDCP is broken on a fundamental
| level, you can grab strippers for about 90EUR on ebay,
| and BD+ is similarly broken.
|
| It literally has no purpose other than annoying customers
| who have rooted their Android phones (Netflix refuses to
| go above 480p) or want legitimate backups of their bought
| content.
| npteljes wrote:
| Jailbreaking is a bug, not a feature. These people need to
| realize the abusive relationship they have with their phone
| company and need to decide which way to go forward. Apple never
| promised to support jailbroken phones, they heavily and openly
| police modifications from the get-go.
| wallacoloo wrote:
| > These people need to realize the abusive relationship they
| have with their phone company and need to decide which way to
| go forward.
|
| _What's the alternative_? I've got a Pinephone coming in the
| mail -- which I ordered precisely because of these sort of
| disagreements between me and Apple /Google -- but I really
| doubt it'll be useful for anything away from home (GPS,
| photos, etc).
| npteljes wrote:
| No real alternative currently, as I see it. The main ones
| track the hell out of you, dark pattern galore, Pine and
| the other Linux phones are simply not 1.0 yet, and I count
| AOSP derivatives as aftermarket solutions, because they
| don't have the engineering power to continue developing the
| fork, either the AOSP or the hardware, should it come to
| that. There isn't really a best choice.
|
| I personally opted for an older Samsung flagship, LineageOS
| without G services, and my own cloud at home. And I'm not
| counting on this being sustainable to be honest. I might go
| more Stallman later, buy dumber devices with lots of
| tradeoffs or just give in to the zeitgeist, and buy the
| shiniest tracking chip.
|
| Edit: Kudos for getting the Pine - putting the money where
| the mouth is something that has at least the potential to
| change.
| isodev wrote:
| I can't fully grasp the argument about jail breaking. The
| device was never intended to be used this way in the first
| place. The process itself probably also relies on bugs that
| need to be reported, not harnessed.
|
| I own my device without the need to root it, every feature in
| the brochure is available to me as a user.
|
| I understand that around the 90s owning anything with an OS
| also implied the ability to mess with the box of bolts and
| circuits that run the OS but that's no longer the case. At
| least not when it comes to phones.
|
| I mean sure maybe you want a fancy device to play with ... get
| a PCB and do whatever you want with it while your phone is
| updating.
| _fat_santa wrote:
| I feel like Jailbreaking was much more of a thing about 10-12
| years ago when the iPhone 3G/3GS and 4 came out. Around that
| time iOS was still pretty limited in what you could do . So
| Jailbreaking gave you the ability to:
|
| - Set a background wallpaper - Reply to SMS in a quick reply
| window (I still miss BiteSMS) - Create albums in Photos. - An
| "Android Like" (back then) quick toggle.
|
| Nowdays all these features and more are part of iOS, but back
| then Jailbreaking let you do so many things that Apple hadn't
| gotten around to including in iOS.
| dpedu wrote:
| The primary point of jailbreaking is to be able to run
| native apps not approved by or banned by Apple and that is
| something you still cannot do.
| jsjohnst wrote:
| > that is something you still cannot do
|
| Factually wrong. You can run apps on iOS without
| jailbreaking that weren't approved by Apple, or even ones
| banned by Apple. This has been true for years. Yes, the
| required resigning of the app every seven days is a major
| hindrance, but it is still something you very much CAN
| do.
| isodev wrote:
| Yes, it's very unfortunate when an app is not available
| for some reason.
|
| In most cases it's a valid reason - the app is malicious,
| poorly made or somehow in conflict with local law. Also
| imagine if you are an app developer an suddenly your
| project (on which you've spent countless hours of hard
| work) is unexpectedly leaked as freely available for
| download and side-loading. I'm not talking big Corps like
| epic and blizzard ... but people like you and me.
|
| Open source apps can be loaded easily, so developers who
| really want to make their stuff available can still do so
| and users won't need to hack their phones to get such
| apps. But of course this can't happen en masse.
| dpedu wrote:
| The affect of piracy is generally overstated and commonly
| bundled with the (incorrect) belief that a pirate would
| instead be a paying customer if the piracy option was not
| available.
| draugadrotten wrote:
| The Steam model appears to be way better. I am buying 10x
| more things on Steam than I will ever have time to use,
| while I generally avoid Appstore as much as possible for
| Mac apps (and even for phone apps when there is an
| alternative) The psychology of the Steam store is very
| different from the Appstore.
| Dig1t wrote:
| As unpopular as I think this opinion is, I can't help but
| agree. If you want a hackable phone there are literally
| thousands of different Android phones that you can buy for a
| fraction of the price that you can tweak/hack to your heart's
| content.
| Stevvo wrote:
| The key difference is with Android you can take
| responsibility for your own security if you choose; it's a
| Linux not so different to any other.
|
| On iPhone you don't have that option, and you have no way
| of knowing if your phone was compromised.
| jonny_eh wrote:
| But none work with Apple Watches, nor do they work with
| iMessage.
| 14 wrote:
| I use my device to scratch my nose who is anyone to tell me
| how to use my device after I purchase it? A jailbroken iPhone
| has been useful in so many ways over the years. Currently I
| am not jailbroken but wish I was just to see all the cool
| mods I could have access too. There are so many useful tools
| it blew my mind all the missing features Apple left out. Hell
| when I bought the phone Rogers sold me a video messaging
| plan. Sure was surprised to learn the original iPhone didn't
| even have native video recording. I was however able to
| jailbreak and download Cycorder and suddenly I could use my
| device not as it was intended I guess but super useful to me.
| Your point of view seems so narrow minded to me.
| Bayart wrote:
| >The device was never intended to be used this way in the
| first place.
|
| The manufacturer has no say on the usage, simple as that.
| That there are better ways to tinker is _irrelevant_. It
| doesn 't preclude the right of people to tinker with anything
| they own at their own convenience, including an iPhone if
| that's what they got.
| planb wrote:
| You are absolutely right. The manufacturer and the law has
| no say on the usage of a device I own. And still I cannot
| expect them to support a way of usage that was never
| intended. So Apple shouldn't be (and isn't) able to sue
| jailbreakers, but they don't have to make it easy for them.
| shadowoflight wrote:
| You're free to tinker with an iPhone however you want, it
| just might require you to be smart enough to work around
| the built-in security measures.
| heavyset_go wrote:
| You're free to tinker with your John Deere equipment
| however you want, it just might require you to be smart
| enough to work around the built-in security measures.
| isodev wrote:
| I'm not disputing the right to do whatever you want with
| your phone.
|
| My comment was specifically targeting the fact that jail
| breaking somehow encourages people to develop means of
| circumventing the security of devices. This is when this
| becomes dangerous - suddenly it has the potential to hurt
| unsuspecting users. Saying that the responsibility is with
| Apple (or Google) to make this possible feels like a straw
| man argument - their job is to earn money (no illusions
| there) and keep users safe, even if it means making it
| harder to tinker (which also helps them earn money)
| wizzwizz4 wrote:
| That's why we need changes to the law.
| tarsinge wrote:
| Arbitrary separating the hardware from the OS is not the
| same thing as the manufacturer having a say on usage. Like
| I am free to use my car how I want, but that I may not be
| able to easily repair it or swap parts like the seats or
| the engine is another problem.
| JackGreyhat wrote:
| > I understand that around the 90s owning anything with an OS
| also implied the ability to mess with the box of bolts and
| circuits that run the OS but that's no longer the case. At
| least not when it comes to phones.
|
| Incorrect. It is still the case with nearly all Android
| phones. You can install any OS version, gain full
| permissions, mess with kernels, modules, frameworks,
| recoveries, ...
| acdha wrote:
| You mean all of the people I see complaining about locked
| bootloaders are mistaken?
| ValentineC wrote:
| > _I own my device without the need to root it, every feature
| in the brochure is available to me as a user._
|
| I'm not able to sideload iOS apps easily (apart from using
| AltStore), or downgrade apps _at all_. This becomes possible
| with a jailbreak.
|
| Also, with a jailbreak, I _own_ my data. iOS (Android too, I
| believe) actively prevents some data from being backed up or
| copied otherwise.
| isodev wrote:
| Sideloading apps is not a feature of iOS. It is also
| illegal unless the app explicitly allows it in their
| license. If you need to be able to side load apps, you need
| a device intended for this purpose.
|
| Regarding data, all user data on iOS is backed up either
| through iCloud and/or on your Mac.
| acdha wrote:
| > Also, with a jailbreak, I own my data. iOS (Android too,
| I believe) actively prevents some data from being backed up
| or copied otherwise.
|
| The primary area you see this is with applications which
| have flagged that data as sensitive so it won't be included
| on unecrypted backups (which includes iCloud). This is
| somewhat important for security -- for example, you
| reasonably do not want TOTP seeds floating around
| invalidating your second factor security model -- but it
| means you have a problem if an application you care about
| uses that feature in a way you don't anticipate.
| nojito wrote:
| So get another phone.
| wizzwizz4 wrote:
| How does this let you sideload iOS apps, or run older
| versions of them? That's like responding "just use Linux"
| to a Windows user's complaint about Office.
| varispeed wrote:
| What if the exploit has been used by governments? Surely they
| should give time or offer alternative way of gaining entry?
| throwaway4good wrote:
| A lot of people don't update or don't update immediately.
| eruleman wrote:
| that's what the emoji's are for.
| colejohnson66 wrote:
| By default, iOS automatically installs updates after a few
| days
| ubercow13 wrote:
| Not if you don't use wifi. In fact it is impossible to
| install security updates without wifi.
| criddell wrote:
| If you never connect your phone to the internet, you
| probably don't need to worry about security updates.
| ubercow13 wrote:
| I am constantly connected to cellular internet, so I
| probably do.
| jaywalk wrote:
| This is 100% incorrect. Updates can be installed via a
| wired connection to iTunes running on a PC or Mac or over
| 5G cellular data.
| dylan604 wrote:
| Right, but you're missing the point that you have to do
| that intentionally. You're not going to bed at night with
| iOS 14.x and wake up with iOS 14.x+ because your cable
| connected itself to the laptop and ran the update. It
| will however do this if you are on wifi. This is the
| point the GP felt was not necessary to expand.
| iaml wrote:
| Some of the updates can't be installed via cellular for
| some reason.
| [deleted]
| jaywalk wrote:
| Can you link to any proof of that? I haven't seen it.
| iaml wrote:
| I just had to connect to wifi for the update to start,
| the button was greyed out. If you don't trust me on this,
| I can send you a screenshot when this happens.
| jaywalk wrote:
| Do you have the "Allow More Data on 5G" option selected?
| iOS updates will not be allowed otherwise.
| ubercow13 wrote:
| Thank you for the correction, my PC isn't supported by
| iTunes and my iPhone doesn't support 5G so I never knew
| this. I guess I have to buy a new $1000 phone to get this
| artibrary restriction lifted.
| imoverclocked wrote:
| iOS updates are generally pretty well adopted in comparison
| to other platforms. [1] [2] For reference, iOS 13 was
| released Sept 19, 2019 [3]
|
| [1] https://9to5mac.com/2020/06/19/apple-says-ios-13-is-now-
| runn...
|
| [2] https://developer.apple.com/support/app-store/
|
| [3] https://en.wikipedia.org/wiki/IOS_version_history#iOS_13_
| /_i...
| allenrb wrote:
| How hard is it to understand that Apple is offering a closed
| ecosystem, with all of the pluses and minuses that implies? If
| that isn't what you want, just don't buy it. Vote with your
| $CURRENCY.
|
| Personally, the last thing I've got time to worry about is what's
| going on in my phone. So I've got an iPhone and use basic common
| sense when choosing what to run on it.
|
| Yes, this is HN but it sure does get old seeing the inevitable
| complaints about Apple. I've been around long enough to know what
| happens to Apple when they aren't selling what people want. That
| isn't the case today. Maybe get over it?
| ralusek wrote:
| When you try to be currency-neutral by using a variable, but
| the variable naming forces you to use $.
| fouc wrote:
| TIL: $? is the "generic currency sign" Vote with your
| $?CURRENCY!
| koolba wrote:
| Probably should be " _Vote with your ${CURRENCY:-USD}_ ".
| Eriks wrote:
| Also macOS Big Sur 11.5.1 https://support.apple.com/en-
| us/HT212622
| Rolcol wrote:
| I don't like the update system introduced in Big Sur. An update
| that is only around 124MB on iOS is 2.20 GB on Big Sur.
| carlosrg wrote:
| I'd love to know why people are downvoting you. You're
| completely right - a minor update that would take 2 minutes
| on Windows or previous macOS versions now requires a 2 GB
| download and a 15-20 minutes install process.
| dangus wrote:
| If you think about the amount of TV in hours people watch on
| a daily basis via streaming services, it's weird to me that a
| 2 GB OS patch could be considered a problem.
|
| Data transfer isn't a finite resource like oil or gas.
| murph-almighty wrote:
| >Data transfer isn't a finite resource like oil or gas.
|
| Clearly you haven't seen those crappy limited data ISP
| contracts floating around. It's an issue for some people.
| [deleted]
| oarsinsync wrote:
| > Data transfer isn't a finite resource like oil or gas.
|
| It absolutely is for many people. Not everyone has
| unlimited services. Even on fixed line services many are
| limited.
| [deleted]
| andrewzah wrote:
| That doesn't mean that we should just ignore efficiency.
| Smaller downloads means less bandwidth required on apple's
| side as well.
|
| This also ignores that not everyone has stellar connection
| speeds, and that some people -do- have bandwidth caps
| (also, let's ignore that people are often mobile).
| Developers really need to stop making assumptions about
| people's hardware or internet speeds... and just do their
| jobs and make efficient designs. Maybe one day everyone
| will have super beefy machines on fiber optic networks with
| 10gb nics, but that's not the reality as of now.
|
| If a patch needs to be 2gb, then so be it. But if it could
| be 100mb, then that's certainly better and something to
| strive for.
| [deleted]
| eurasiantiger wrote:
| Fortunately, Apple Coal is rumoured to be just around the
| corner, to be launched with Apple iSteam product family.
| mtoddsmith wrote:
| An exploit like Pegasus could just fill up the storage on the
| device which would prevent updates from working. Why does this
| 14.7.1 fix require almost 2gb of storage?
| AlphaWeaver wrote:
| I heard something about updates for the new M1 Macs requiring
| users to download the entire updated image due to some signing
| issue? Maybe something similar is happening here.
| drexlspivey wrote:
| Could this be patching the Pegasus exploit?
| arkadiyt wrote:
| Possibly. If anyone would like to check if their iPhone was
| infected by Pegasus I wrote up some step-by-step instructions
| here:
|
| https://arkadiyt.com/2021/07/25/scanning-your-iphone-for-nso...
| m0dest wrote:
| Thanks for the write-up. One issue, though:
|
| >You might have also noticed the "Encrypt local backup"
| checkbox. MVT only operates on decrypted backups, so there's
| no point in encrypting your backup here and immediately
| decrypting it to scan it - just create an unencrypted backup
| and delete it after you're done.
|
| You should still do an encrypted backup even if you're going
| to immediately decrypt it for MVT. An encrypted backup
| contains more complete data; it's closer to a filesystem
| dump. The MVT docs actually explicitly recommend this, too:
|
| >If you want to have a more accurate detection, ensure that
| the encrypted backup option is activated and choose a secure
| password for the backup.
| xvector wrote:
| It's my understanding that Pegasus is a collection of zero
| days, not a single exploit
| fortuna86 wrote:
| Is there a way to enable instant over the air updates for 0-day
| fixes, etc? I see my phone has "automatic updates" on but it
| still requires me to download and install manually.
| wil421 wrote:
| Usually the automatic updates run at night when it's plugged in
| and on WiFi. I've never seen my phone ask to do it during the
| day unless I ignored the update for a few days.
|
| I also believe Apple is doing some kind of rate limiting.
| Whenever I've upgraded iOS or MacOS on day one the download is
| painfully slow on my gigabit connection.
| infofarmer wrote:
| No extra rate limiting required. With ~1.7 billion active iOS
| devices, the infra must be under a bit of a strain to deliver
| even a relatively tiny 50 Mb delta.
|
| For this particular update, my iPhone downloaded over 100 Mb
| and MacBook over 1 Gb.
| rudian wrote:
| My iPhone 11 Pro downloaded over 900 Mb and it was up to
| date until now.
| slownews45 wrote:
| The scale of data involved in this crazy.
|
| 1GB/update * 1B devices potentially?
|
| We are in exabyte range.
|
| I've also noticed somewhat slower downloads on new
| updates on my 1GB connection.
|
| Ideally their caching network really is everywhere. I
| wish they'd do the Microsoft thing of letting you update
| based on others local downloads. For campus networks some
| of these updates can really load things up.
|
| I'm also at 900MB+
| djrogers wrote:
| Apple's been doing this for years with Content Cache on
| macOS - it used to be an osx server capability, but they
| rolled it into the regular macOS release a while back.
| You just turn it on for one of your Macs, and everyone on
| your subnet (or multiple subnets with a little extra
| work) can now use a local cache of updates.
|
| [1] https://support.apple.com/guide/mac-help/what-is-
| content-cac...
| marcellus23 wrote:
| > letting you update based on others local downloads
|
| They do, you can set up a Mac as a content cache for
| system updates for other Macs on the same network.
| ev1 wrote:
| I really hate that they demand Wifi - I never have Wifi, but
| I have an unlimited data plan that is well good for multiple
| terabytes.
| gorgoiler wrote:
| How's your battery usage though, with the cell radio on
| (compared to wifi)?
|
| Battery crapping out is still a major taboo with iOS
| updates, I believe.
| ubercow13 wrote:
| The battery can be checked before updating, after any
| downloading, so it's irrelevant.
| benhalllondon wrote:
| Whoa! Where do you live?
| Turing_Machine wrote:
| Yeah, that needs to change.
|
| It should probably have to be turned on explicitly, because
| a lot of people are still on spendy OTA plans, but it
| should be an option.
| closeparen wrote:
| Not when there's an alarm clock set.
| ThePowerOfFuet wrote:
| Your device will check for updates once a week by default. No,
| there is no way to do what you're describing; if every iPhone,
| iPad, and Mac sold in the last five years simultaneously
| reached out for a 2 GB update, the entire internet would
| probably fall over.
| floatingatoll wrote:
| Not as a simple end-user with no other Apple infrastructure
| available to you. If you're using MDM, you have additional
| options available to you to create such a model on your own,
| but for Apple's consumer offerings, Apple defines the check-in
| schedule for each update, and it sounds like they've selected
| "install overnight" for this update.
| solarkraft wrote:
| Wonderful! This means there's a chance iOS users will be able to
| get root access on their devices.
| hindsightbias wrote:
| Only 952.5 MB?
| nonninz wrote:
| According to my phone is 139.8 MB
| signal11 wrote:
| 126 MB for me.
| thekrendal wrote:
| I think it depends on which version you're updating from.
|
| I'm still on 14.5.1 and it shows as a 922.4MB download.
| 2OEH8eoCRo0 wrote:
| I thought the walled garden provided impenetrable security?
| ThePowerOfFuet wrote:
| Nothing provides "impenetrable security".
|
| Don't be a dick.
| aaomidi wrote:
| Hmm, is this not a bug in iOS 15? I understand it's in beta but
| it seems irresponsible for not having the fix out there.
| SigmundA wrote:
| Another day another 2 gig MacOS update to fix unsafe language
| memory corruption...
| ummonk wrote:
| This isn't remote-exploitable, right? I.e. the exploit happens if
| you have a trojanware app installed, correct?
|
| If it's a remote exploit I'm going to be telling everyone I know
| to update ASAP, but otherwise seems alright to let the regular
| auto-update schedule do it for them.
| shitloadofbooks wrote:
| If it is the NOS Group/Pegasus exploit, then it was a "zero-
| click" exploit which could be exploited by sending someone an
| iMessage.
|
| I'm updating right now just to be sure.
| mrunseen wrote:
| Related tweet (POC):
|
| https://twitter.com/b1n4r1b01/status/1419734027565617165
|
| Also (writeup):
|
| https://twitter.com/AmarSaar/status/1419770084780875779?s=20
___________________________________________________________________
(page generated 2021-07-26 23:00 UTC)