About the security content of iOS 14.7.1 and iPadOS 14.7.1
support.apple.com
support.apple.com
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.
Still you have options, load windows in a vm (hint: ms releases a fully functioning vm image every month that works for all major hypervisors). Install iTunes and you’re all set.
1) it's really annoying to have your crap moved around without being asked
2) it's often the only way to retain control of your device.
[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...
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.
Both are vulnerabilities in the sandboxing.
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.
If we're quibbling, they likely meant plurality as opposed to majority. It's close to an outright majority though.
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?
https://enterprise.verizon.com/resources/reports/2019-data-b...
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.
https://www.verizon.com/business/dam/img/resources/reports/2...
https://www.verizon.com/business/dam/img/resources/reports/2...
This is a very widely discussed trend in the industry and has been for literally almost a decade. It has lead to the tired trope of the number one hardening recommendation being "get rid of the users" as well as the much more helpful "users can't be expected to participate in their own security, it needs to be done for them transparently".
Those are not the same figures on the PDF listed. The PDF presented seems to be from 2019, and I can't tell because your images are presented out of context, but it looks like hey might be from a newer report?
The PDF linked has a summary of findings that shows in figure 4 that 52% of breaches included hacking, and that 33% included social attacks.
Assuming I've found the document you're using as a source[1] (it's nice to have a newer version, but I hardly think it's fitting to ask me to reexamine a summary of findings chart that I was not originally presented with), it does go into more recent information.
That said, figures 20[2] and 21 in the new report do shed some more light on what we're actually talking about, and brings up the difference between "incidents" and "breaches" in this report, and what they mean. They define an incident as something that compromised the integrity, confidentiality or availability of an asset, while a breach is something that results in a confirmed disclosure of information. While phishing (social) is top in breaches as a bit less than 40% and pretexting (social) also makes a good showing in the breach chart (figure 20[2]), the much more expansive category of incidents (figure 21[3]) is overwhelmingly dominated by DoS (hacking) at almost 60%.
While that may seem like splitting hairs, especially since the original comment mentioned breaches, it was in response to and in the context of iPhone users, which is end user security. These reports are about businesses, and note they're following the NAICS standard to categorize victim organizations. They source their data from paid external forensic investigations, direct recording by partners using VERIS, and converting partners existing schema of data into VERIS (paraphrasing Appendix A). I think this discussion is about people and security in general, and I don't think this data is about that, I think it's about companies and organizations.
Now, to be clear, on thinking about this more closely I fully believe that social engineering attacks likely could be the majority of attacks when taking into account end users, and I imagine quite a lot of end user malware and ransomware that is likely installed from email, but I'm not sure, and I'm not sure how much browser exploits account for that, or how much phones change the picture. If we were just considering home systems, the majority I assume are firewalled at this point, I would definitely assume social engineering, but with phones out hopping public ranges through data plans and sharing wifi at many businesses, I'm not sure how that may be changed.
In any case, I think it's completely valid to call out someone that makes a general factual statement such as "Most security breaches these days are social-engineered." without providing that evidence. It's not self evident, and there's a lot of data to look at, as we've seen.
1: https://enterprise.verizon.com/resources/reports/2021-data-b...
2: https://www.verizon.com/business/dam/img/resources/reports/2...
3: https://www.verizon.com/business/dam/img/resources/reports/2...
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.
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.
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.
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.
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.
What if _you_ didn’t? I outlined scenarios which are real risks for millions of people and a fair fraction of those either involve no or limited user consent. Maybe it’d be possible to have a secure factory reset – this is harder than it might seem with firmware in so many places – but that only helps if you even know that you need to. Anything which allows undetectable rootkits means that a large number of people will never even realize that because phones are general purpose devices and most people are not security experts. Worse, how many of them are actively being betrayed by trusted experts - abusive partners, unethical technicians, etc. - who will say it’s fine?
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.
Really? How have you defined common? Where is that data from? I can't imagine anything more than a tiny fraction of car owners are doing this. Most people are not hacking their cars, building Raspberry Pi controllers for their toilets, or have any desire whatsoever to side load an app on their iPhone. The HN community is not representative of the overall population.
But no one says the car manufacturers are required to make a car where you can flash the ECU. There’s just no reason for them to block it. If someone came up with a way to steal your car by tricking your into running an app that flashed your ECU then you can bet Ford would disable it pretty quickly.
Sure there is… if they are providing warranty on the vehicle then they should definitely block ECU mods, as a customer could flash original firmware back after causing damage.
And I imagine you can easily make an engine over-rev or overheat with a modded ECU, perhaps to the point of causing a fire or other catastrophe.
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.
Are you sure about that? I pulled an old, cheap Android phone out of storage box to do some debugging. I needed a quick file manager app, installed one of the top results on Google Play that was baked with some malware that may have bricked the device (didn't bother to try to fix it, it's in the bootloader). Granted this was an old version of Android, but that's still a bit egregious. I can't recall anything like that happening on iOS.
https://blog.zimperium.com/new-advanced-android-malware-posi...
-> "Upon installation (from a third party store, not Google Play Store), the device gets registered with the Firebase Command and Control (C&C) with details such as the presence or absence of WhatsApp, battery percentage, storage stats, the token received from the Firebase messaging service, and the type of internet connection. "
It isn't hard to find similar reports, there are enough of them.
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.
Exactly but what you’re missing is that with iOS this decision is made when you buy the phone.
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.
Eventually also google, Amazon, anyone under the sun will do the same, just in case some aspect of your privacy is not captured.
Technical solutions (like preventing side-loading) cannot possibly eliminate the thing driving the behavior; profit motive for stealthily gathering data to build "better" user profiles to lease to advertisers.
A much better solution would be to create better permissions models (capability-based) for mobile devices.
As an example, one could build a granular permissions model which forced apps to be composed of multiple modules. Each module would have their own sets of mutually exclusive permissions.
An app that allowed the user to apply filters to photos/videos could be composed of two modules:
One which had read and create permissions for files the photo library along with read-only access to an app-local storage directory
A module which had the network communications permissions (exclusively by OS APIs that performed all the crypto[1]) and write-only access to the app-local storage directory (for downloading new filters)
By forcing apps to be broken up into separate modules and ensuring that all network communication is done from a carefully constrained sandbox (which can only read/transmit a tiny subset of data generated/available to the app), users could see exactly what the app transmitted without having to install their own self-signed root certificate (and maybe also jailbreak their devices if the app that they're interested in is using certificate pinning or ignoring the OS certificates).
The best way to technically combat a lot of this sort of data-slurping nonsense would be to force apps to have near[1] total transparency for all network communication for any user that wanted to see.
[1] The OS crypto API would have to provide a few authentication routines which blanked passwords, secret keys, etc. after use to prevent the unintentional leaking of secrets. Those APIs would obviously have to be designed to be resistant to malicious use by Facebook, etc.
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.
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."
If Facebook is willing to fool kids into giving up their privacy via side-loading, you can imagine why Apple is nervous about how things would go if anyone could easily do so.
While there are people who make this argument purely on ideological grounds (similar to arguments you hear about individual freedoms vs collective rights), it's essential to recognize that _completely_ removing the ability of independent developers to write and run software if the manufacturer has decided they don't like that developer will slowly destroy the competition, creativity and freedom that created most of the technologies that are used today.
It's reasonable to make the argument that the manufacturer needs to secure the devices that they sell, even for users with low technical literacy.
Advocating for the manufacturers to be given total control over everything that every user can do with their device won't guarantee increased security, but it certainly would result in manufacturers being able to disable any software they chose to, regardless of legitimacy, without reason or recourse.
That's a prospect that is (IMO) far more terrifying than what it could prevent (some users falling for certain types of phishing attacks that install spyware).
We've been in this argument before and the most secure platform today is still the web, an open platform where the code is designed to run on demand.
There's a reason everybody asks to install their native app, there's much more data to gather there than in the web.
I'm not suggesting that the manufacturer should be creating closed platforms to "secure" things for the user; I'm saying that closed platforms can't guarantee an increase in security but will guarantee the slow erosion of openness in all other platforms.
I'm well aware of how native apps are heavily marketed over their web-app equivalents because companies want to gather more data, get access to push notifications (on iOS at least), etc.
I disagree with that conclusion (the latter scenario happens frequently and has lead to significant consequences, including death) but completely agree that it's not a good situation that the alternative is giving a couple of companies control over who gets to ship software. That's why I described it as a market failure — as a user you're left picking which set of drawbacks is less of a problem for you.
What I'd like is basically opening up the App Store walls: allow users to enable third-party stores but everyone runs their apps inside the same sandbox, and the OS vendor retains some global kill switch for malware but with some level of public oversight.
One edge case for this would be the apps which need special permissions: for example, some cell carriers have special entitlements on iOS which allow their apps to talk to their networks in ways which normally are blocked. Reconciling edge cases like that with multiple stores would require care.
We know exactly what happens when you do this. Less savvy users will be tricked into installing malware.
For instance, a couple of months ago:
>FlixOnline App Spreads Android Malware by Promising Free Netflix
https://www.thequint.com/tech-and-auto/flixonline-app-spread...
Nah, thats a win2k era cop-out. The hard part is balancing secure by default and granting privs only when absolutely necessary (and authenticated)
I think a better angle is pushing for relaxing software distribution: keep the trust chain but let people run apps in the normal sandbox even if those haven’t gone through the current process. Exploits are still possible, of course, but the normal controls allowing user awareness of the device’s status would be intact.
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 90€ 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.
Some of the worst DRM has been because Apple has a vested interest in restricting your ability to use your computer freely.
Just a shame it won’t be in iOS 15.
Once the patch is publicly available, an exploit has much less commercial value. (Attackers don’t like having to call their target and tell them not to apply the patch.)
It therefore makes sense to donate such exploits for a jailbreak.
All tall people are human. Not all humans are tall.
- 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
It's very possible Apple doesn't want to verify that Messages was compromised, particularly if they can blame everything on something obscure.
Whether something is a Messages vulnerability or “something obscure” is just marketing spin.
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.
On iPhone you don't have that option, and you have no way of knowing if your phone was compromised.
Again, there are other options for both. Android wear devices are still a thing, and there are multiple options that aren’t SMS that are available to the Android ecosystem.
If you want to live in the Apple ecosystem, that comes with some tradeoffs. Can’t have it both ways.
The entire point of the saying that you can't have your cake and eat it too is that, well, it can't be both in your hands and in your stomach. But it's perfectly possible for me to be able to call Apple and get a bootloader unlock code, without any other change to anything.
That's essentially what the parent comment is trying to do. When offered the Android ecosystem as an alternative, the counterpoint was to lament the lack of Apple Watch and iMessage support in the Android ecosystem.
This is textbook "I want it both ways".
This is the definition of wanting it both ways.
I don’t think anyone would argue that it’s technically impossible, but that should not be mistaken with “practically impossible” given Apple’s business model.
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.
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)
It’s all a “think of the children” race-to-the-bottum where rent-seekers abuse fear and sycophanty to monopolize critical infrastructure.
But Apple's security measures definitely help against virtually anything else. Over-zealous police and border patrol. Script kiddies. General spyware and malware.
I think you're forgetting how bad mobile security was before both Apple and Google started adding these hardening measures to their flagship devices. You really couldn't trust your phone at all. Now, you somewhat can.
Where does this end? Should all devices that have computers attached be capable of being 'rooted'?
You would not have the expectation if for example you purchased an MRI machine, that it should be able to emulate a Game Boy. A phone is also a special purpose computer; and the phone's software is designed to guarantee that those special purposes always work.
In my opinion this is the main thing that this root crowd does not understand; the iPhone is not a general purpose computing device. You should not have bought one if that's what you wanted. The market is full of general purpose computers that can make phone calls.
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, ...
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.
Regarding data, all user data on iOS is backed up either through iCloud and/or on your Mac.
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.
Also with a jailbreak, other people own your data too. A jailbreak is an exploit. A hammer can be used to drive in a nail (jailbreak) or it can be used to smash windows (malware.) Same tool in the end.
The very act of jailbreaking is what keeps your system vulnerable to the same exploits used by malicious actors.
- 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.
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.
Interesting, I do the opposite. When something is available in the Mac App Store or through other means, I will generally buy it in the App Store. Why? Application sandboxing is mandatory for Mac App Store apps and I strongly prefer that applications are sandboxed by default.
The second, less important, reason is that I can just install the applications with just one click and don't have to download them from different places, look up their serial numbers, etc.
That said, I‘m struggling with the constraints Apple puts on the business models of developers, for example when it comes to upgrade pricing. While I have a fair amount of software Mac/iOS subscriptions running (8 by my current count) there‘s definitely software I passed on because it moved to a subscription model.
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.
Pure anecdata, but the vast majority of folks I see talking about AltStore outside HN are not developers. YMMV!
It is a kludge designed to make the process as unpleasant as possible but just so enough that Apple can claim they don't block sideloading.
It's disingenuous.
You don’t need an Apple system to codesign. Two results on first page of search results:
https://github.com/zhlynn/zsign
https://weisser-zwerg.dev/posts/ios-app-without-mac/
> make the process as unpleasant as possible but just so enough that Apple can claim they don't block sideloading
Apple doesn’t claim they don’t block side-loading. Actually I believe they claim the opposite in the Epic case (even though it is possible via a supported process) because it was “necessary to ensure the safety of their user base” or something like that.
> It's disingenuous
Shifting goal posts from “you can’t” to “you can’t without X” once someone points out the first was factually incorrect is considered disingenuous by many too.
(Edit for formatting and provide links)
First off, you're making a huge assumption here.
Second, the only goalpost shifting here is your attempt to pass off complex and temporary workarounds intended for developers as resulting in a device that is somehow the same as jailbroken devices. This is incorrect for the obvious reasons pointed out already.
Perhaps you are unfamiliar with jailbreak and didn't know apps installed via jailbreak don't need to be constantly renewed and resigned? Installing apps long term is still something you can't do, as I originally said.
Attempting to pass off a lesser solution that doesn't come close to matching what I originally mentioned and pretending it is the same is dishonest and disingenuous.
I'd argue it still is.
I can't install a third party web browser that doesn't use WebKit.
I can't select alternative default apps to most apps bundled with the OS.
I still can't unlock the bootloader.
I still can't browse the entire filesystem.
People who espouse the virtues of jailbreaking on iOS tend to forget one big thing... the exploits that are used to jailbreak are also exploits used by malware creators to compromise the system.
The items you just listed matter only to people like the posters here. We have philosophical differences with the limitations in place today, but back in the heyday, those limitations were just fundamental gaps in functionality available to users.
With the many major new APIs available to devs over the years and with the maturation of the App Store, those original drivers behind jailbreaking just aren’t there for the most part.
I don't know too may users who care only about a specific aspect of their phone when backing up. I do have non-technical friends who do iTunes/local backups because they "don't trust the cloud", but I've never encountered a person trying to do this piecemeal.
For what it's worth, there are decent 3rd party tools like iMazing that are easy to use and do give you more granular control.
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).
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.
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.
Apple provides APIs now on stock iOS to allow an app to use a “VPN profile” to implement a firewall blocking outbound connections, but without requiring a remote server (aka the app applies rules locally to outbound connections). The downside is you have to trust Apple to pass their own traffic through the app’s firewall unlike with a JB, but at least that covers the other examples you gave.
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
And frankly I think they’re being generous to you; writing a frame buffer is even more complicated than their estimation.
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.
I don't care how complex the vulnerability is. The consequences I do.
Pretty much every operating system has some fun places near its core that are a steady stream of problems.
However I have written a more in-depth reply about why counting CVEs is meaningless here:
Also the software in question is a complicated subsystem to write on a platform that’s guaranteed to get many eyeballs on. So the fact that those CVEs span roughly once per year might also be a demonstration that there are relatively few bugs (if we knew the number of people and time spent researching vs CVEs published then maybe we’d have a more meaningful statistic).
CVEs do also demonstrate that active research is happening. There are plenty of common libraries out there that never get audited. Does fewer CVEs mean they’re more secure? Or does it just mean that nobody has checked?
Thus on its own, that data is pretty meaningless in terms of deriving a trend.
The reason the LoC comparison was made is because measuring lines of code doesn’t tell you how long a developer has spent debugging, reading documentation, or doing other research required. It doesn’t tell you how secure, performant, or even buggy the code is. All it tells you is the number of lines written and literally nothing more can be derived from that figure. Likewise with CVEs submitted.
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.
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.
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...
I think they are slowly going in that direction, e.g. by moving drivers to user space with DriverKit (which AFAIK unfortunately, still uses C++).
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 today so that the attack surface becomes progressively smaller, it's Apple.
It's not as if no-one knew about the dangers of writing security-sensitive systems in C or C++ in 2007 or as if the Internet was some new idea where no-one understood that bad people would try to remotely compromise your system using it. Apple might not yet have realised how important the iPhone was going to become back then but they were doing very well by a decade ago and they were huge by five years ago.
Multics had a DoD validated security profile higher than any UNIX, it was written in Acme Corporation PL/I.
The original Mac OS and Lisa were written in Fluffy Object Pascal.
Apparently many airplanes get to fly in a toy language created around 1983.
....
Maybe in 2007 it made sense to build iOS on an existing platform and use the normal systems programming languages. Why couldn't more recent development of potentially vulnerable components have been done using safer technologies though?
Take a look at the long list of security issues fixed by last week's iOS 14.7 update[1] and tell me how many of the vulnerable systems could have been written or rewritten to use more secure technologies. Look for terms like "use-after-free", "buffer overflow" and "out-of-bounds read".
Then there is the iOS 14.7.1 update we're discussing today. Yet again this seems to be about fixing a memory corruption issue in a kernel extension written in an unsafe language that has a track record of exposing vulnerabilities. When do we start learning from those mistakes?
[1] https://www.cybernewsgroup.co.uk/apple-issues-urgent-iphone-...
Now notice the companies behind all the major browsers and the companies behind most of the popular recent programming languages are basically the same set, and join the rest of us in wondering how this is still happening.
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.
It's important in the same way that phasing out ICE cars is important -- important for society, but unlikely to happen in a timely manner without regulation.
Here's a fun strawman: the EU or California could announce limits on the sale of products relative to the number of lines of memory-unsafe code used to build them, starting in a few years.
So iOS is very unlikely to be "hundreds of millions of lines of C and C++".
Display controllers are complicated (and Apple ones are especially so, with all their fancy features).
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?
Edit: https://en.wikipedia.org/wiki/Currency_sign_(typography)
See, even Groundhog Day-esque arguments about Apple can turn up hidden gems. Let’s do this every day!
For real?
If the only information I could ever get about products was positive marketing from the creators of said products I don't understand how I could possibly navigate purchasing decisions as a consumer. Open public discourse about the pros and cons of various products is crucial to a functioning market.
Obviously if you already own an Apple device maybe you read announcements on their support portal, but that doesn't really help (it is great that Apple announce this stuff though).
Unfortunately, all my friends and family use iMessage and Facetime, and Apple makes that impossible to access on an Android phone.
Also, Apple buys up huge amounts of the supply chain such that their screens, cameras, etc are better than basically anyone else's, and if I were to switch I'd loose access to every app I've bought over the past decade. (If not for Requiem and TunesKit, I'd loose access to all my movies and TV shows too.)
Care to provide a source? Last I heard, their screens are made by Samsung and LG, and the camera (sensors) by Sony and Omnivision. None of these companies are owned by Apple.
You get to choose your phone platform. The implications there include whether or not you get exclusive access to Apple specific features like iMessage and FaceTime. They also include the cost of your existing collection of purchased apps and some DRMed media. You also have to pick your phone from the choices and features of the chosen platform's available devices.
You still have to choose "what you want" and then "Vote with your $CURRENCY." Your "wants" obviously include not just the OS/ecosystem design choices, but your financial investment into your incumbent platform, the convenience of sticking with what you know, your desires/requirements around screens and cameras.
You can totally trade off some of those other requirement over "platform security" or any other differences between iOS and Android. But don't fool yourself that you consider privacy to be critically important, if you're willing to forego it in favour of keeping your hundred or so bucks worth of Android apps or video subscriptions...
Apple has never been known to have the fastest/best devices on a feature-comparison point by point. There are better screens, cameras, speakers in many many Android devices.
https://arstechnica.com/gadgets/2020/12/iphone-zero-click-wi...
https://arstechnica.com/information-technology/2020/12/zero-...
https://arstechnica.com/gadgets/2021/07/clickless-exploits-f...
etc., etc.
If thats a whataboutism then whataboutisms were always valid and accurate forms of introspection
Fragmentation of Android is a thing.
Sure, holes are found. Strong security is a long process of adding more and more boundaries (while giving the ecosystem some time to adapt to those boundaries) and fixing more and more logic/memory errors.
Regardless, macOS is probably the most secure desktop operating system out-of-the-box.
It kinda was, imo. https://www.youtube.com/watch?v=eF7habaTvAY
I'm required to use the devices Apple creates, because work. Once your product is required to be in the hands of many people the idea of "Vote with Money!" is objectively, demonstrably, false. You might as well tell working class people to just walk to work. It affects me. So when someone supports a company like Apple, against all evidence, I'm inclined to further critisize Apple and its users whom advocate against themselves. I'm even more open to harsher regulations on Apple, even. Similiar to how regulations on Gambling are a necessity to prevent heavily negative socioeconomic effects.
This doesn't mean much. Other companies go through tough periods too, Windows Me, AMD *dozer, etc..
https://twitter.com/b1n4r1b01/status/1419734027565617165
Also (writeup):
https://twitter.com/AmarSaar/status/1419770084780875779?s=20
As a former pentester, that's precisely the opposite of the correct thing to do. tptacek could phrase this more eloquently, but pentesters do not try to weaponize exploits. The whole point of exploiting is to demonstrate that a vuln exists. Once that demonstration is complete, weaponization serves no purpose.
(No purpose for protecting users, anyway, which is the whole point of pentesting.)
I'm surprised no one seems to care. Maybe times are changing.
I didn't realize that there might be a difference in the awarded bounty level. That's... unfortunate for them. As you can see here, he was sitting on this for some time.
Does it run code as root? Write kernel memory?
EDIT: source: https://saaramar.github.io/IOMobileFrameBuffer_LPE_POC/
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.
For this particular update, my iPhone downloaded over 100 Mb and MacBook over 1 Gb.
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+
They do, you can set up a Mac as a content cache for system updates for other Macs on the same network.
[1] https://support.apple.com/guide/mac-help/what-is-content-cac...
Apple does let you do this! It just takes a little more work to enable.
You need a macOS device on your local network. Then in Preferences -> Sharing, enable “Content Caching”. This will transparently cache OS and app updates for all Apple devices on your local network. If any device requests an update your caching server doesn’t have, the caching server downloads it first and then serves it to the client. This can minorly speed up updates even when they're not already cached. It also caches shared iCloud file contents as well. (But with E2EE, so the server can’t see the content).
I keep a caching server running and really see the speed up. It's great if you’re setting up a new phone and installing lots of apps, making it particularly useful for corporate IT.
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.
Battery crapping out is still a major taboo with iOS updates, I believe.
The person who buys the phone is one customer. Another customer is the cell phone networks, who don't much want to use their airtime to distribute OS patches, which use a lot of bandwidth but are almost entirely invisible to users.
Rather than, you know, a vulnerable device behind on updates that isn't backupable to iCloud in any way.
It could be done in a p2p way like windows updates. By default they will share update files to other devices on the local network and can also work with other devices over the internet.
A bunch of plugged in iphones on wifi would be perfectly capable of distributing update files.
I'm not suggesting the whole thing become p2p, but that the p2p network assist the dedicated distribution servers. For me, just the local p2p would halve the number of updates pulled from Apples servers because there are 2 of the same apple product on the same local network.
Obviously Apple doesn't need to do this because they are flawlessly pushing out updates every week but if they were struggling with distribution, this is a proven working system that windows uses.
Imagine all the iPhones that aren't on Wi-Fi when they get such an emergency update request: they'll melt the mobile networks trying to download 2 GB each.
The idea doesn't work.
This is why Apple devices check for updates once a week, staggered. The load is therefore mostly constant, other than the hardcore ones who manually check for an update once they hear one is available.
As a side note, upload rates seem to be somewhat constant at all hours. I assume it must all be IoT security cameras.
https://support.apple.com/guide/mac-help/what-is-content-cac...
All the devices after that will use the local copy of the update.
Data transfer isn’t a finite resource like oil or gas.
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.
It absolutely is for many people. Not everyone has unlimited services. Even on fixed line services many are limited.
Clearly you haven't seen those crappy limited data ISP contracts floating around. It's an issue for some people.
Apple is known for providing ZERO official guidance on the lifecycle of security updates for older versions. It really looks like they're trending towards an iOS model where there's no concept of support for anything but the latest version. (The one exception is that older iOS devices stuck on iOS 12 have still been receiving updates)
https://arkadiyt.com/2021/07/25/scanning-your-iphone-for-nso...
>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.
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.
I'm updating right now just to be sure.
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.
iOS: Never ending zero days but you get an update for every device in the last 7-10 years to fix it.
Android: A more secure OS especially as they integrate more components using rust. But if your device is older than 2 years, you won't receive any security fixes.
So depending on your security model it changes what you should pick. If you are a high target individual or someone who upgrades their phone every year, Android is the more secure option.
If you are the average person who is not being hit with state level attacks, iOS is the most secure option.
I don't have any actual proof but my gut feeling is the linux kernel is better tested and has better security hardening than the ios internals.
The old thought that open source is more secure doesn't seem to really hold as there are terrible bugs in nearly everything all the time.
It should also be noted that Apple is rewriting certain parts of iOS in safer languages as well (see blastdoor for messages as an example).
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.
I'm still on 14.5.1 and it shows as a 922.4MB download.
And iOS wants a Wi-Fi connection to download an OS update. Without Wi-Fi you couldn't update, even if you wanted to.
They seem to have forgotten to mention iPhone SE which also gets iOS 14