The Fully Remote Attack Surface of the iPhone
googleprojectzero.blogspot.com
googleprojectzero.blogspot.com
While they found some exploitable bugs on the iPhone here, they also found (and reported) that quite a few systems did not seem currently exploitable. It seems clear this is not a hit job, at least to me.
When P0 recruits two prominent Chrome hackers (Ned Williamson & Samuel Gross) and make them work directly on iOS, it look like a hit team to me.
Apple gets attention from them because a lot of people have apple hardware and software. That means problems there have a higher impact than on some less used product.
Apple is more than welcome to respond with its own researchers finding Android and other software bugs, and we'd all be better off if they did.
The better term is "coordinated" (or "uncoordinated") disclosure.
It's not clear at all that this is reasonable, and IMO, this seems to highlight the lack of incentive (or even perverse incentive) for vendors to secure their systems.
Out of personal curiosity, how is "coordinated" mitigating the issue you mentioned? It eliminates the vagueness of "responsible" but seems a lot more strict for the researchers:
> The primary tenet of coordinated disclosure is that nobody should be informed about a vulnerability until the software vendor gives their permission
Those words all focus on the fact that 'bad guys' also get notified and ignore that users get notified.
Telling users that their device or software is vulnerable is not really useful to them unless it comes with a patch. Very few users have the knowledge, skill, or access to directly alter their technology to secure it, based on a vulnerability report. Most don't even know how to be aware of such reports, or even that they should be.
"Cyber bad guys" are more likely to be aware of and able to act upon a vulnerability report, as they have more knowledge than most users, and their entire mode of operation is that they don't wait for access or permission.
This is why "coordinated" disclosure is sometimes better. By announcing the vulnerability with the patch, the asymmetry between users and bad guys is better balanced. Users can be reasonably expected to install patches when notified to do so.
Of course there are all sorts of exceptions, such as when data is actively being leaked or exfiltrated, which users could delete or remove. Or when the security vulnerability affects systems managed by people sophisticated enough to take direct mitigating action, like changing server configuration or cycling keys.
If people really can't be bothered to follow through with what's going on, then they'll offload that responsibility to someone else if it's important enough. We already do that with IT for companies, and Anti-virus for a lot of people at home (as much as I think most those companies focus on the wrong thing)[1]. Adding information to the system allows that market to be more efficient and useful.
1: I would love to live in a world where most the protection was a combination of the OS and application vendors patching their own software, and protection consultant/anti-virus companies that knew what software you ran giving you good information on what you should and should not do on a regular basis of for short periods until something is fixed, etc. I think that's a much more valuable service than "we scan all your incoming and outgoing mail and make your computer so slow and unresponsive you think you need to buy a new one".
You're making the assumption that the disclosure in question is the first discovery of the vulnerability.
Doing something "responsibly" isn't just the prerogative or duty of security researchers. It's a general term which means "putting thought into it".
EDIT: breach, not beach
The low hanging fruit has definitely been thoroughly picked these days, at least in software like iOS. But yet with pretty much near certainty, exploits find a way.
Perhaps even more fascinating, is that closing off one class of exploits always seems be followed by new kinds of exploits, like clockwork. You’d think eventually this would stop happening, but so far it hasn’t. CPU side channel attacks may not be completely new, but they’ve emerged as one of the new big targets as of late.
I really know little about security personally and obviously the amount of work that goes into serious security research should never be underestimated but I’m impressed at the inevitability of security bugs. Very few large programs escape a regular cycle of bugs. Maybe OpenBSD is the best example of Pretty Secure software.
The problem is that vendors aren't in the business of perfecting existing software. They're in the business of pushing out big, bold, feature-rich changes and additions.
There's always new low hanging fruit.
We can hypothesize that better languages and better mitigations (e.g. ASLR) can improve the situation across the board, and I don't doubt that that's the case, but I haven't yet seen the evidence. (Maybe I missed it?) It's probably too early as it's difficult to make apples-to-apples comparisons across those aspects.
Your generalization seems a bit broad.
It's pretty clear from the economic incentives of the companies producing the software, the sheer quantity of exploits found, and the surprisingly low amount of QA that would be needed to catch most bugs that the aforementioned view is correct.
It's still plain that OS vendors continue to make big compromises, by eg continuing to use C/C++ to handle untrusted data for decades after the risks became obvious, and we're constantly seeing C-caused vulnerabilities like Windows RDP server remote root, WhatsApp remote root, Broadcomm and Qualcomm Wlan RCEs, etc.
The memory safety laissez faire attitude has also held back the state of the art in other fronts besides memory safety, because it's not so interesting to eliminate other classes of bugs while the elephant remains loose in the room.
I wrote @ronomon/mime [1] for this purpose, to protect downstream user email clients from MIME bombs [2], invalid charsets which can crash Apple Mail, multiple From headers which can exploit Gmail [3], attachment directory traversals, malicious continuation indices, truncated MIME messages, stack overflows etc.
[1] https://github.com/ronomon/mime
[2] https://snyk.io/blog/how-to-crash-an-email-server-with-a-sin...
[3] https://blog.cotten.io/ghost-emails-hacking-gmails-ux-to-hid...
Visual voicemail is just IMAP and SMS? Wow, for some reason I assumed there would be some distinct protocol for that. It's pretty interesting that it's implemented using the existing software the phone already runs on.
Otherwise I love VMM, and it really should be a standard on all iPhone and Carriers.
1. sign up with a voip provider that either terminates on your own pbx (e.g. asterisk/freepbx) or provides voicemail with emailed audio files. setup said service with voicemail.
2. setup your favorite container system and let systemd manage the service
3. create a container that watches for new audio voicemails , when it finds a new voicemail push it to your favorite cloud provider (s3, gcp bucket, azure etc) then trigger that providers speech-to-text function on the audio file in the related cloud storage. store the resulting text message and metadata in a db.
4. create another container that simply watches that db for new messages and push out alerts however you see fit. you have many paths here. i went with a web-based ui that pulled the data ala google voice.
3 years ago mozilla dropped deepspeech which changed everything - https://github.com/mozilla/DeepSpeech i have since replaced step 3 with my own deepspeech server. none of my data goes to any of the major privacy violators with this setup.
The excuse the carriers used for charging for it was always bullshit. But like hotel WiFi, if you had one of these smartphones you didn’t care because work was paying for it.
This is done for privacy reasons, AFAIK: it prevents “read receipt” links like you might find in emails. It does however allow for the sender to attach a misleading thumbnail, though.
https://github.com/googleprojectzero/iOS-messaging-tools
Just went to the talk. TL;DR: iMessage uses old serialization libraries, they are terrible.
Asking the HN audience: Is there a set of design principles that the iMessage team can follow to make these more resilient to such attacks while retaining their usability? As a non-Apple employee whose globally dispersed family relies on iMessage to stay in touch, I have a vested interest in the security of my family’s iPhones. I know it’s rare for Apple employees to comment, but it would be great if someone from Apple can comment on whether these libraries are being re-architected in some way. This will cut through any FUD that arises from this disclosure / discussion.
Google's motivation for fixing these bugs is certainly not directly financial.
If I am not wrong, Android has been exploited multitude of times.
No? https://www.cvedetails.com/vulnerability-list/vendor_id-49/p...
I phrase it a bit unnuanced, but it does leave me a bit puzzled. I suppose companies can be nice and not nice at the same time, but I'd rather look at the level of incentives first before looking at the level of being nice.
That was their stated motivation behind things like Chrome - increase the speed and utility of webapps so that more things could be online. It works in this case because they are improving security and therefore user trust in online services in general..
The cynic in me is sure that that's not the only reason, but it's part of the picture.