How a nightmare wormable, wireless, automatic hijack-a-nearby-iPhone security flaw was found and fixed A Google security guru has published details of a critical hole in Apple's iOS that can be exploited by miscreants to hijack strangers' iPhones over the air without any user interaction. All a hacker would need to do is transmit carefully crafted, malicious AWDL packets to a victim's handheld to gain control of it. AWDL is …
I vaguely wonder how many people haven't yet updated their iOS to the version that is patched. Apple has good form in this, and they support relatively old devices.
I'd say this is another cautionary tale about proprietary systems, but then again Heartbleed was in OpenSSL. And by the way, I've always found suspicious that such a vulnerability happened to be submitted on December 31, when everybody was too drunk to notice.
> Google bod spends ages showing how crap non-Google tech is.
Was, not is. Big was fixed before public disclosure. Google bloke reports bug to Apple and receives bounty. Apple fix bug, roll out update.
I don't think any Googler thinks Apple's security is crap compared to Android.
"B[u]g was fixed before public disclosure. Google bloke reports bug to Apple and receives bounty. Apple fix bug, roll out update."
In that case, the real shock is that Google bloke didn't go public while the fix was being tested with a seven day deadline to boot...
When a Zero day is being actively exploited people are actively being exploited. Warning them NOW is the way to ensure that they are able to protect themselves. When a vendor has a long history of sitting on bugs for a year or more until prodded--I'm on the side of warning the public immediately.
Posting the PoC at the same time is debatable. Warning the public of an active exploit is good citizenship.
> Apple should spend more time modernizing critical legacy code in iOS like vm_map.c, written in 1985 and still in use today.
I am not sure why the fact it was written in 1985 is a problem. I am also going to observe that this file was not the one with the bug if the claim the bug was in C++ code is correct.
So yes, there is some justification for saying Google are playing marketing games with this.
"why the fact it was written in 1985 is a problem"
There are whole classes of vulnerability (and indeed the CVE database itself) that didn't exist in 1985.
You really believe that a fuzzy-logic probe or chaos monkey approach wouldn't throw up some edge cases?
That the code hasn't moved or been replaced in 35 years does not say that there is nothing to fix, it's an indicateur that no one has looked...
vm_map.c line 644: map_addr = start_aligned;
vm_map.c line 645: for (map_addr = start_aligned;
Maybe they should assign start_aligned to map_addr a few more times, just to be safe. (Yes, this is not a vulnerability. It's a code smell.)
So, yeah, I think this could use some desk-checking, static analysis, and dynamic analysis (either under a test framework, or using a symbolic-evaluation-simulated-execution hybrid).
By the way, what's a "fuzzy-logic probe" in this context? Do you mean fuzzing? Fuzzing has nothing to do with fuzzy logic, and I'm not aware of any common application of fuzzy logic (which is more often found in control systems) to software vulnerability testing. I may well be unaware of some innovation in this area, though.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
