Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
I was hoping the iOS 15.2.1 update would resolve the issue that I can no longer make calls from my contacts prefixed with an international dialling code.

Following the 15.2 update I had two Apple genius appointments + Apple store manager conversation! - undertook the following tests:

Turned on and off dial assist

Reset network settings

Reset all settings

Total phone wipe & reinstall as new phone (not using icloud backup)

All failed to resolve the issue.

I was advised to edit each of all my +300 contacts by removing either the international dialling code or leaving that and removing the domestic (0)……Great

Apple genius seemed uninterested but I was assured the issue would be resolved in a future update! Helpful! Obviously not until 15.3…..
 
500,000 gnomes typing could eventually… It’s like Pi or Infinity. It’s there but it’s approaching astrophysics in discovery and implimentation.
 
Idk, should we thank Apple for fixing this bug or should we blame Apple for fixing this bug after a whole year?
Update: Oh so this is a more "permanent" fix while iOS 15.1 addresses this issue already? Well then.
Well, let’s first consider the severity of this bug. It requires the entry of at least 500,000 characters as a device name to work. How’s that even going to happen unless the bad actor has possession of your gear? Second, did this bug ever get through to the real world as an exploit?

To me, security issues that require physical possession of the device are nothing burgers. Nice that it’s fixed but a nothing burger none the less.
 
This issue was found months ago by an independent researcher. They reported to Apple, and after Apple mot fixing the issue, they went public. Now less than a month after going public, the issue has been patched by Apple.

Makes me wonder how many other issues Apple currently knows about but are sitting on instead of patching.

It's not as simple as that. Software development happens in branches. Scheduling when those branches get merged into the "release" branch is a coordinated effort, and can happen around different priorities. If Apple shoved every small change at the front of the line, we'd never see any new features.
 
  • Like
Reactions: Stryder541
It's not as simple as that. Software development happens in branches. Scheduling when those branches get merged into the "release" branch is a coordinated effort, and can happen around different priorities. If Apple shoved every small change at the front of the line, we'd never see any new features.
Defensive coding would have kept this from happening. This is XKCD’s “Little Bobby Tables” cartoon about sanitizing inputs writ large.

Here’s Aleph One talking about this type of buffer overrun in the 90s. This is not a new issue. https://inst.eecs.berkeley.edu/~cs161/fa08/papers/stack_smashing.pdf
 
Last edited:
Who really would have created a HomeKit device with a name over 500,000 characters? While it's possible, it's INCREDIBLY unlikely.
The point is not that you will do this at home by mistake; the point is that someone trying to attack your system can do this and transfer the problematic name into your system.
 
  • Like
Reactions: centauratlas
The problem isn’t that someone could name an object with >500K characters. The problem is Apple code is willing to accept inputs of this length, even when the field has not had the memory allocated to handle a 500K length string.
One of those border cases that did not get tested. What happens when you attempt to assign a string that is longer then its allocated storage location. It took a string of 500K to get the bug to show. Certainly got missed on a code review. I have seen too many cases like this in ny software career.
 
The point is not that you will do this at home by mistake; the point is that someone trying to attack your system can do this and transfer the problematic name into your system.
This is what I love about all those folks who try to play the "Who would do that?" and "Impossible!" cards… they, through their very responses, show how ignorant they are. Also they're inevitably the ones who scream the loudest when an attack happens to them. @name99 is spot on.
It's simple: when an engineer tells you the bridge could fall down, you should listen. The world is littered with smug politicians and ignored engineers… and unfortunate folks whose lives were up-ended while going about their day crossing a bridge.
 
  • Like
Reactions: centauratlas
This vulnerability would never manifest in someone’s home.
Yeah, I'm still waiting for someone to explain how this hack would ever actually get exploited. Seems like it would require someone who *already* has access rights to add HomeKit devices to your HomeKit network wanting to screw you over. If I'm missing something, someone please explain.

FWIW, I'm a software developer who had to work overtime right before the holidays patching an app of ours for the log4j issue where the issue could have never actually been exploited in a real-world scenario (the app was not a web-facing app).
 
  • Like
Reactions: xpxp2002
Does this fix the Snapshots not updating on the cameras?

I just updated my snapshots still arn't working =(. I really don't want to reinstall all my cameras as they are all different brands and I have automations tied to them.

My guess is since HomeKit requires a hub, such as an Apple TV or HomePod, it will require a software update to these devices to fix the camera screenshot issue. Again, just a guess as I’m no where close to being a software developer/engineer.

Hopefully a fix comes sooner than later. When my non-techie wife notices and gets annoyed by bugs in the Apple ecosystem such as this one, it‘s a good indication this needs to be prioritized just below security fixes.
 
The point is not that you will do this at home by mistake; the point is that someone trying to attack your system can do this and transfer the problematic name into your system.
There's no mechanism for outside apps to change your device names. HomeKit doesn't allow such through the API. So short of allowing someone access to your phone and then allowing them to paste a +500,000 character string in there, how do you propose this would be exploited?
 
The problem isn’t that someone could name an object with >500K characters. The problem is Apple code is willing to accept inputs of this length, even when the field has not had the memory allocated to handle a 500K length string.
Very sound reasoning that Apple should over all their code in any entry naming fields.
Seriously, people accept home invitations from randos? Haha.
Lol, don’t laugh too hard BlackBerry users that did jumó ship early enough would get thousands of PIN messages from randos and engage them lol.
 
I had a weird bug on 15.2 with my HomeKit set up and I wonder if it was related. No responses/stuck on updating for all of my non Apple devices on just my iPhone, but everywhere else it was showing/working just fine - my wife's iPhone, my iPad, my Mac. I went through multiple steps to try and troubleshoot, but Apple had no fix in mind. I ultimately had to remove my home and start from scratch, but this was after I set up my phone as brand new. Either way, frustrating that these issues keep popping up with HomeKit after all these years. I have invested heavily and I am hoping for major back end improvements.
 
Yeah, I'm still waiting for someone to explain how this hack would ever actually get exploited. Seems like it would require someone who *already* has access rights to add HomeKit devices to your HomeKit network wanting to screw you over. If I'm missing something, someone please explain.

FWIW, I'm a software developer who had to work overtime right before the holidays patching an app of ours for the log4j issue where the issue could have never actually been exploited in a real-world scenario (the app was not a web-facing app).
The way it can get exploited (from the release) is that person A could create a HomeKit device on their network with a > 500K name through the API. Then A could send an invitation to a home that has this device to anyone they want, persons B through Z etc.

Too many people will click accept it thinking, oh, it is an Apple HomeKit invitation it is safe. Then boom, their iphone/iPad is in a persistent DOS state where the only option is to restore from a non iCloud backup.

Do3s that help?

and the log4j issue seemed to be everywhere. ?



see https://trevorspiniolas.com/doorlock/doorlock.html
 
There's no mechanism for outside apps to change your device names. HomeKit doesn't allow such through the API. So short of allowing someone access to your phone and then allowing them to paste a +500,000 character string in there, how do you propose this would be exploited?
There's *is*, depending on how you define "outside". The mechanism is Home Sharing.
Home Sharing is described here: https://support.apple.com/en-us/HT208709
This is not a zero-click vulnerability, but it is the sort of thing that might be clicked by the foolish and ignorant, or simply by mistake when you're trying to tap something else.

More details are given here:
 
Serious question...how are things like this discovered?
Security researchers will typically test a lot of edge cases to find vulnerabilities and bugs that can be exploited, since those tend to be the ones most likely to be missed during development. Long strings, integer overflows etc. can be some of the most common.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.