Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Operation Triangulation: What you get when attack iPhones of researchers

securelist.com

Post reply on HN
Print view View original

391–400 of 433 posts

Re: Operation Triangulation: What you get when attack iPhones of researchers

#391

Post by I_Am_Nous »

avidiax wrote: post #377
I_Am_Nous wrote: post #171

Earlier quoted context omitted.

In the face of this kind of threat, it's pretty obvious why Apple treated Beeper as a security risk and took appropriate measures to secure iMessage.

Beeper is the user's choice. And Apple is preventing other companies from providing a more secure iMessage alternative, e.g. one that doesn't even parse messages from people not in the contact list, or doesn't even parse anything without a click, etc. Apple has had so many zero-click exploits in iMessage, yet they insist that you have to use Lockdown mode to do anything about it, and then proceed to bundle Lockdown m…

>Beeper is the user's choice.

Me deciding to ride the subway to work for free is a user's choice, but that doesn't mean it's right. Using infrastructure for free because I feel like it is certainly my choice but I can't justify anger when someone makes me pay to use it since I should have paid in the first place. Currently Apple doesn't run iMessage as an open standard so it runs in "authorized riders only" mode.

>I don't think there's any way to claim that Apple is just doing whats in the customer's best security interest.

This isn't what I claimed. I claimed Apple treated unauthorized 3rd party access to their infrastructure as a security risk and worked to shore up that risk. As you pointed out, there have been plenty of zero-click exploits in iMessage. Limiting the devices sending iMessages increases security. I believe Apple doesn't allow iOS VMs in general for the same reason.

Re: Operation Triangulation: What you get when attack iPhones of researchers

#392

Post by gorkish »

codedokode wrote: post #369
supriyo-biswas wrote: post #333

Earlier quoted context omitted.

So much misinformation in this thread. It’s a Hamming ECC, as described here[1]. [1] https://social.treehouse.systems/@marcan/111655847458820583

Why do you need error-correction code for a debugging feature though? I would not protect debug registers with a hash.

Bc you are DMA-ing the raw bits into cache with the GPU, but the CPU is going to check those ECC codes on read as the caches on Apple SoC's are ECC-native. It's an integrity 'protection' not a security 'protection'

Re: Operation Triangulation: What you get when attack iPhones of researchers

#393

Post by londons_explore »

rst wrote: post #381
adrian_b wrote: post #363

Earlier quoted context omitted.

That the secret registers are in fact cache test registers, as explained at that link, is a very plausible explanation for their existence. Nevertheless, this does not explain at all the astonishing fact that they were mapped by default in the accessible memory space, unless listed and explicitly denied in the system configuration files. No amount of incompetence seems enough to explain such a default policy, so the…

Apple's mitigation was in fact to alter boot-configured memory mappings to deny access. (And as to the mappings... if they were in the middle of a range of documented registers, or close to one, sloppiness and poor internal communication are at least plausible...)

I would hope that all memory outside the known ranges is denied by default... Apple should know all the memory mapped hardware in the SoC, so why would they allow IO to something that doesn't exist?

It's just a few lines of code to parse the memory map and deny all undefined regions. As well as being good for security, it also helps find out-of-bounds write bugs, and ensures you can't accidentally ship an out of date memory map.

Re: Operation Triangulation: What you get when attack iPhones of researchers

#394

Post by runjake »

chatmasta wrote: post #61
sampa wrote: post #51

Earlier quoted context omitted.

or Apple just implemented this "API" for them, because they've asked nicely

Or they have assets working at Apple... or they hired an ex-Apple employee... etc. That's the problem with this sort of security through obscurity; it's only secure as long as the people who know about it can keep it secret.

Go onto LinkedIn, search for Apple Global Security staff and you’ll get an answer. The head of and much of the staff are ex-USIC people. Now perform those searches over time and do a little OSINT and observe a revolving door where they are not so ex-.

Re: Operation Triangulation: What you get when attack iPhones of researchers

#395

Post by cma »

lotsofpulp wrote: post #286
cma wrote: post #92

Earlier quoted context omitted.

The color is a big part of the problem, white on green is one of the hardest to read because of the distribution of color cone cells in our retinas. Only maybe white on yellow would be worse.

Dark mode is the way to go anyway.

What color combo does plain sms get there?

Re: Operation Triangulation: What you get when attack iPhones of researchers

#396

Post by pas »

kornhole wrote: post #260
pas wrote: post #231

Earlier quoted context omitted.

the dollar as the reserve currency already has a serious impact on the US (ie. the big upside is that it allows the US to borrow for very cheap, but the nasty downside is keeping the purchasing power of the USD artificially high, which is not great for the non-finance sectors of the US, not great for people who work in those sectors, and double-plus-not-great for US exports [which are not the dollar itself]), basical…

A weak dollar is good if you own a company that relies on exports. For the rest of us who are paid in dollars and need to buy imports, a weaker dollar hurts. That is one opinion. We can already see China and Japan selling off their US bonds and the BRICS countries are working on solutions to get off the dollar with high priority.

Have you read the article? :)

Maybe this one will be more interesting https://www.noahpinion.blog/p/brics-is-fake

Re: Operation Triangulation: What you get when attack iPhones of researchers

#397

Post by Veserv »

mike_hearn wrote: post #361
Veserv wrote: post #246

Earlier quoted context omitted.

It should be very easy to add one without somebody noticing. This is the same Apple which shipped a version of macOS for months that added the ability to login to root with any password only a few years ago. Their review processes are so incompetent even one of the most security critical components, root login, let a totally basic “fail your security 101 class” bug through. It is absolutely inexcusable to have a proc…

Mistakes happen but Apple's reputation for strong security is well deserved. They invest heavily and the complexity of this exploit chain is evidence of that. Linux has had its fair share of trivial root login exploits that somehow got through code review.

No, that is a level of error similar to delivering cars with no airbag in them for months. In any other industry that would indicate a unimaginable level of process failure. Only in commercial software are egregious, basic mistakes swept under the rug as “mistakes happen”.

Just to list a few process failures off the top of my head.

No proofs of specification conformance. No specification conformance tests. No specification. No regression testing. No regression testing of common failure modes. No testing of common failure modes. No enhanced review for critical components. No design conforming to criticality requirements. No criticality requirements. No intention to establish criticality requirements.

In actual safety and security critical software development you do all of those except maybe the first. Doing none of them is rank incompetence and clear evidence you do not know the first thing about actual security that can protect against real professionals. And fancy that, Apple can not and never has against attackers with minimal resources like small teams with only a few million dollars.

We can talk about a reputation for “strong” security when they can protect against the standard, commonplace 10M dollar attacks we see every day.

Re: Operation Triangulation: What you get when attack iPhones of researchers

#398

Post by lotsofpulp »

cma wrote: post #395
lotsofpulp wrote: post #286

Earlier quoted context omitted.

Dark mode is the way to go anyway.

What color combo does plain sms get there?

Other person is white text on black background. Yours is white text on green background. The app's background is also black.

Re: Operation Triangulation: What you get when attack iPhones of researchers

#399

Post by fsflover »

throwaway81523 wrote: post #328

Philip Zimmermann a while back was working on a secure phone product called the Black Phone. I tried to convince him that a secure phone should not contain any microphones of any kind. That sounds a bit weird for a phone, but it's ok, if you want to make a voice call, just plug a headset into it for the duration of the call. He wasn't convinced, but this iphone exploit makes me believe it more than ever.

My phone has a hardware kill switch for mic/camera.

Re: Operation Triangulation: What you get when attack iPhones of researchers

#400

Post by duskwuff »

adrian_b wrote: post #363
duskwuff wrote: post #325

Earlier quoted context omitted.

As explained by marcan: it's not "hashing", it's an error-correcting code. Much more understandable in that light. https://social.treehouse.systems/@marcan/111655847458820583

That the secret registers are in fact cache test registers, as explained at that link, is a very plausible explanation for their existence. Nevertheless, this does not explain at all the astonishing fact that they were mapped by default in the accessible memory space, unless listed and explicitly denied in the system configuration files. No amount of incompetence seems enough to explain such a default policy, so the…

> No amount of incompetence seems enough to explain such a default policy, so the supposition of an intentional backdoor still seems more likely.

I think you're overestimating how granular the memory mappings are (or how isolated the debug registers are). They're usually used to control access on a peripheral level, not to individual registers within a peripheral.

Post reply on HN