An Apple HomeKit Bug Can Send iOS Devices Into a Death Spiral (theverge.com) 22
Security researcher Trevor Spiniolas has discovered a vulnerability "capable of locking iOS devices into a spiral of freezing, crashing, and rebooting if a user connects to a sabotaged Apple Home device," reports The Verge. From the report: The vulnerability [...] can be exploited through Apple's HomeKit API, the software interface that allows an iOS app to control compatible smart home devices. If an attacker creates a HomeKit device with an extremely long name -- around 500,000 characters -- then an iOS device that connects to it will become unresponsive once it reads the device name and enter a cycle of freezing and rebooting that can only be ended by wiping and restoring the iOS device. What's more, since HomeKit device names are backed up to iCloud, signing in to the same iCloud account with a restored device will trigger the crash again, with the cycle continuing until the device owner switches off the option to sync Home devices from iCloud.
Though it's possible that an attacker could compromise a user's existing HomeKit-enabled device, the most likely way the exploit would be triggered is if the attacker created a spoof Home network and tricked a user into joining via a phishing email. To guard against the attack, the main precaution for iOS users is to instantly reject any invitations to join an unfamiliar Home network. Additionally, iOS users who currently use smart home devices can protect themselves by entering the Control Center and disabling the setting "Show Home Controls." (This won't prevent Home devices from being used but limits which information is accessible through the Control Center.)
Though it's possible that an attacker could compromise a user's existing HomeKit-enabled device, the most likely way the exploit would be triggered is if the attacker created a spoof Home network and tricked a user into joining via a phishing email. To guard against the attack, the main precaution for iOS users is to instantly reject any invitations to join an unfamiliar Home network. Additionally, iOS users who currently use smart home devices can protect themselves by entering the Control Center and disabling the setting "Show Home Controls." (This won't prevent Home devices from being used but limits which information is accessible through the Control Center.)
Re: (Score:1)
It's not quick. It forces people into a line...
Cheaping out on programmers (Score:2)
A field overrun? In this day and age? Who wrote this code?
JFC, Apple, hire some competent programmers. This is coding 101. You NEVER say "I'll provide a 'big' variable, it'll be fine" and don't actually limit and check the data before you allow it into the system.
still cant bounds check strings (Score:2)
it's 2022 and developers sting cant escape and bounds check inputs ?
honestly I like apple homekit but name lengths is pretty basic Quality Assurance test....
Re: (Score:2)
It is telling that iOS has such bugs more than Android does. Perhaps Objective-C/Swift make such mistakes easier than Java/Kotlin. (Or perhaps their bugs are just considered more news-worthy; for whichever reason you prefer.)
Apple should really implement something to prevent an app from causing a reboot loop, though.
Re: (Score:3)
It seems odd how many of these bugs result in iOS devices ending up bricked or very nearly. Like the SMS bugs and so forth.
Normally the apps which handle these things would be low privilege, sandboxed and completely unable to crash the OS or prevent it booting. Android has a "safe mode" for boot issues too. Somehow normal apps can take down iOS though.
Re:still cant bounds check strings (Score:4, Insightful)
Its because the security model promised by micro kernels and sandboxing was never really viable in the modern era. At least not in terms reducing the blast radius to the point where the system can mostly carry on. Sure when the UI was a 'borne shell' on a TTY it worked but not now.
What happens in practice now is. Some component like say a networking daemon gets bugged, it stores some SSID or similar thing it can't handle. It crashes every-time it starts, does not matter if the system is restarted or just running and daemon is being killed and restarted over and over.
Now the UI has some status indicator that needs to query the network deamon, which it can't do because that thing is dead. So it hangs. The systems is up the display server is up, but you can't do anything because the shell is hung up.
Now on something like a PC or server you could probably SSH in or switch consoles or use some other interface and maybe fix things. Certainly good because maybe it means other services like filesystems and the like can get shutdown cleanly. Trouble is on your mobile phone you don't have these options - because Apple doesn't want you too -
Re:still cant bounds check strings (Score:4, Interesting)
Less bounds checks, and more like enforcing reasonable limits.
500K characters is probably handled just fine by the code - no buffer overflows or anything. It just results in a crash because you're probably making copies of the string and consuming gobs of memory. 500K is half a megabyte, and probably stored as Unicode, so that could easily be a couple of megabytes. Do it a few times and you'll explode the stack and heap with extremely large objects.
The device crashes because the application exhausts the RAM of the device. I mean, if it was a bounds problem, it would be an instant crash. Instead, it's probably stored as an unbounded safe string object that can handle basically unlimited sized strings. Problem is, the code is written to assume the strings will stay small and you're now dealing with tens to hundreds of copies of the strings and RAM runs out, the app crashes, and likely also takes down some other service in the OS.
So it just goes to show, even if you use "safe" string objects, you can still have bad things happen, because even though you can handle an unlimited size string safely on input, you might not have the RAM available to handle multiple copies of it.
The only mistake is Apple didn't impose some sort of limit to how long the string can be, which can be tricky with Unicode strings. And likely it happens because Apple used safe string constructs that ensured there was enough buffer space to hold even ridiculous amounts of data without overflow. So no security problems here because you can't overflow the buffer. However, the stability of the application was compromised because the strings multiplied in memory until the application ran out of memory. Since it's a 64-bit OS, the physical memory would run out long before the heap and stack limits would be reached.
Everything else just happens because a system application got taken down.
Re:still cant bounds check strings (Score:4, Interesting)
Do it a few times and you'll explode the stack and heap with extremely large objects.
Na. One doesn't dynamically allocate onto the stack, and these are devices with multiple gigabytes of RAM, so heap exhaustion is going to take more than a few hundred copies of a 0.5MB string (UTF-8 or otherwise)
if it was a bounds problem, it would be an instant crash
Incorrect.
A failure to check bounds merely results in you writing past the variable in the stack. This can mean you can potentially overwrite other stack variables, overrun your stack frame (harmless), or completely fill the stack (segmentation fault)
Insta-crashing on overwriting a buffer in stack or heap would have saved me about a trillion hours of my life in debugging.
So it just goes to show, even if you use "safe" string objects, you can still have bad things happen, because even though you can handle an unlimited size string safely on input, you might not have the RAM available to handle multiple copies of it.
Memory exhaustion is definitely a real attack vector.
with Unicode strings.
You mean UTF-8. Unicode can be represented in a wide char format (16-bit) where string length is merely bytes >> 1.
So no security problems here because you can't overflow the buffer.
The only people who think automatic bounds checking implies safety are likely writing code at such a high level that they can skate by with no knowledge what-so-fucking ever about the architecture of an actual CPU.
Since it's a 64-bit OS, the physical memory would run out long before the heap and stack limits would be reached.
Nope. Stack is limited to 1MB for the main thread on iOS, and 512KB per additional thread.
Heap is limited to 2GB per process.
Re: (Score:3)
Oh you poor, nave thing. Let me introduce you you to surrogate pairs [datacadamia.com]. You need to go bigger than 16-bit if you want the number of bytes to be a simple multiple of the number of codepoints. But even when you get past that, there are combining characters, modifier characters, and other horrors.
Re: (Score:2)
Re: (Score:2)
Chinese isn't bad. Chinese is pretty much always one character per codepoint, characters correspond to a single glyph (not context-sensitive), most characters are the same width, and the line break rules are very simple. Even Latin scripts are more complex when you need to deal with combining accents, joining punctuation, language-sensitive hyphenation rules, context-sensitive forms (e.g. ligatures), kerning, and more. The real killers are Indian languages, Thai, Arabic, and other scripts where everythin
Does nobody do input validation anymore? (Score:2)
Software creation seems to be riddled with incompetents. A truly pathetic state of affairs.
Explanation for non-Apple users (Score:4, Informative)
I have registered my "smart-devices" to my Apple-Home installation, which in turn is registered to my AppeID. That means I can control my lights (*1) etc. from each Apple devices menu bar (actually: Control Center) or I can use Siri to control them, whether at home or remotely (*2).
I can invite other peoples AppleID to control (aspects of) my Apple-Home installation, so guests or the cleaner can switch the lights / blinders. They then get an email with an invitation-link they can accept and my Apple-Home is added to their set of places they can control.
It seems that one can setup an Apple-Home with a maliciously named device and then ask people to join that Apple-Home. They would have to accept the invitation, though, but I can see some people failing for this.
(1) in my case the brain of it all is "homeassistant" on Linux exporting some components to Apple-Home.
(2) It's quite an ingenuous architecture: The router responsible to control devices is automatically elected from all Apple-Devices registered to the AppleID and can be reassigned dynamically. So if any one Apple device is at home and in reach of the "smart" devices, they can be controlled. Of course, if you have an AppleTV or HomePod, that will usually be the router, but it could be an iPad, too. The database is distributed to all devices using Apple's CloudKit and Communication is done E2E encrypted by (basically) iMessage. Very special but very nice system, it really "just works" in most cases.
Use cases (Score:3)
I forgot to mention: I didn't find a use-case for sharing access, yet. Guests or the cleaner usually don't need to operate the more eclectic aspects of my house and the rest is either automated or has switches that at least look normal.
But I think it's good that it's there.
Re: (Score:1)
yeah! (Score:1)
Situs Agen18 (Score:1)
Ada banyak sekali Agen Situs Slot Online [128.199.196.0] judi slot online yang bisa dipilih. Memilih yang terbaik untuk Anda akan tergantung pada apa yang Anda cari. Sebagian unsur yang perlu dipertimbangkan saat memilih Agen judi slot online termasuk lisensi casino, kebijakan privasi, dan syarat dan ketentuan. Memiliki lebih banyak isu membuat Anda merasa lebih nyaman. Tercantum di bawah ini yakni sebagian kiat yang bisa menolong Anda memilih alternatif terbaik untuk Anda. Semoga tips ini akan membantu Anda membuat keputu