[HN Gopher] About the security content of iOS 16.2 and iPadOS 16.2
___________________________________________________________________
About the security content of iOS 16.2 and iPadOS 16.2
Author : tosh
Score : 70 points
Date : 2022-12-13 20:57 UTC (2 hours ago)
(HTM) web link (support.apple.com)
(TXT) w3m dump (support.apple.com)
| hgo wrote:
| As another poster said: ouch. Out of caution, may some of these
| vulnerabilities be at all relevant to macOS?
| takoid wrote:
| Anyone else having issues creating a recovery key for their
| device? I have tried several times to do so since updating to
| 16.2 but I can't get the code to verify.
| coder543 wrote:
| I created a recovery key no problem.
|
| I'm confused about the Security Key for 2FA situation, since I
| can't find that anywhere on iOS. On the AppleID website, it
| mentions it, but the "learn more" link 404s[0], and the
| "continue on device" button errors out.
|
| I guess they're working on rolling this feature out on the
| backend still.
|
| [0]: https://support.apple.com/en-us/HT213154
| bombcar wrote:
| I made one seemingly fine on a iPhone X - but I updated via a
| cable to my Mac instead of doing it on device.
| radicaldreamer wrote:
| Their servers are getting hammered, I think some of these
| features will be unreliable to enable temporarily.
| byproxy wrote:
| Likewise, on an iPhone XS.. if that matters.
| takoid wrote:
| Are you also having issues? I'm troubleshooting the issue
| with Apple Support right now but not having any luck. They
| said they are going to open a ticket with the engineering
| team.
| nequo wrote:
| Interesting how all of these "security content" documents frame
| the bug fixes as "improvements." For example, in this one:
| This issue was addressed with improved data protection. An
| out-of-bounds write issue was addressed with improved input
| validation. A logic issue was addressed with improved
| checks. The issue was addressed with improved memory
| handling.
|
| Makes it sound like data protection, input validation, checks,
| and memory handling were fine. But now they are better. Whereas
| the truth is that they were bad and led to data leaks and remote
| code execution.
|
| As it goes with improvements, they keep coming.
|
| Wouldn't it be better for Apple to own up to the fact that these
| defects are indeed defects, and be transparent about what
| measures they are implementing that _prevent_ such defects from
| being added to the code base or from being exploited?
|
| Google wrote about the former a couple weeks ago[1] and Apple
| itself is not doing badly in the latter department.[2]
|
| [1] https://security.googleblog.com/2022/12/memory-safe-
| language...
|
| [2] See Luca Todesco's talk from October:
| https://www.youtube.com/watch?v=8mQAYeozl5I
| kube-system wrote:
| It's a matter of perspective. When you run a business, all of
| your public communication is marketing communication. That's
| why they're phrased in the positive, and they're not
| necessarily highlighting the shortcomings they're aware of.
| GavCo wrote:
| Includes an 'actively exploited' zero-day affecting most iPhones:
| https://news.ycombinator.com/item?id=33974923
| arijun wrote:
| From your article, looks like that was fixed in 16.1.2, not
| 16.2
| [deleted]
| uvesten wrote:
| Ouch!
|
| That felt like a longer-than usual list of bugs, especially the
| memory mgmt bugs leading to arbitrary code execution. And a
| sizeable number of remotes (if you include webkit in that
| category.)
|
| I honestly don't know what to feel; "great that they fixed so
| many!" or "yikes, there are probably millions more like this :("
| pjmlp wrote:
| That is great, because it is what is causing the business
| support for safer languages.
|
| The amount of hours * salary rate per hour, burned with those
| security fixes.
| twawaaay wrote:
| For some types of apps, sure. But if you look at the list,
| the ones that sting the most are kernel or video parsing
| errors or similar. I am just not seeing these being
| implemented with anything else than an efficient, low level
| programming language. At least not for the foreseeable
| future.
|
| But what it may do, hopefully, is getting rid of all that
| audio/video/photo stuff from the kernel. One has to ask _why_
| a video encoder can leak kernel memory in the first place.
| (This was rhetoric question, we all know why. It is just not
| sustainable to put more and more stuff into monolithic kernel
| as you add more silicon to solve some CPU /GPU intensive
| problems because it is just easy.)
| Gigachad wrote:
| What is Apple doing about these non stop memory safety bugs?
| Google has put out a post about how they now write the majority
| of Android code in memory safe languages including 1.3 million
| lines of production Rust. While Apple hasn't said anything as far
| as I'm aware.
|
| https://security.googleblog.com/2022/12/memory-safe-language...
| saagarjha wrote:
| Majority of _new_ Android code. Apple also has been writing
| parts of their operating system in a memory safe language,
| Swift.
| [deleted]
| bri3d wrote:
| In the kernel: https://security.apple.com/blog/towards-the-
| next-generation-...
|
| In bootloaders:
| https://support.apple.com/guide/security/memory-safe-iboot-i...
| olliej wrote:
| No, google wrote a blog post about how they're moving their new
| code to safe languages. The vast majority of Google's code is
| in C/C++, and will be for the foreseeable future. The same is
| true for Apple - there's a huge amount of existing C/C++, and
| new code is increasingly being written in Swift.
___________________________________________________________________
(page generated 2022-12-13 23:00 UTC)