Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Likely this was a hackable route for many many many many years.

Just goes to show — just because Google & Apple say their phones are secure — doesn’t mean they are. It just means that they aren’t aware of an existing vulnerability
Fair point. It wasn't until my ex started paying hackers to break into my stuff in a vengeful way that I took this stuff seriously. When the will is there, IMO it's pretty scary what people can get into.

IMO there's lotsa holes just sitting there that hackers know how to exploit. My assumption with most content is that if it's sitting on a server somewhere then somebody's probably got a backdoor method of accessing it. They just need a reason to do so.
 
Last edited:
  • Like
Reactions: MacHeritage
The point is there are vulnerabilities and then there are vulnerabilities. Saying there is a vulnerability in a vacuum without supporting information is pointless. Zero day zero clicks are obviously the worse.

iOS has had its share. But when I look at the CVE list imo android has more red flags, imo.
True. There's a big gap between the kind where researchers have identified a theoretical vulnerability requiring highly specific circumstances and a gaping hole that's been widely exploited.
 
Likely this was a hackable route for many many many many years.

Just goes to show — just because Google & Apple say their phones are secure — doesn’t mean they are. It just means that they aren’t aware of an existing vulnerability
Google already confirmed it was never exploited.

Users here still don't understand that this app comes deactivated, in order to make it do something you need full device access to activate it.
It's like having a small window that's closed sealed(aka it would be difficult even for the owner to open it)and in order to open in you need full and unrestricted access inside the house which is the purpose in the first place(to have access inside the house) , so that small window is irrelevant.
 
Last edited:
  • Like
Reactions: ToyoCorollaGR
Getting popcorn ready for when EU users come onto these forums crying about how they got hacked by the non-Apple app stores that they begged for
 
Unless the iVerify report shows something more substantial, I'd just suggest people don't put their phones into store demo mode until the patch arrives.
The app is deactivated even for somebody that owns the phone, it needs elevated privileges to activated it, so run ADB comands and things like that, in order to turn the app on.
 
The point is there are vulnerabilities and then there are vulnerabilities. Saying there is a vulnerability in a vacuum without supporting information is pointless. Zero day zero clicks are obviously the worse.

iOS has had its share. But when I look at the CVE list imo android has more red flags, imo.

Humm, it seams that the point keeps on moving has we dig deeper.

I also think that iOS devices are generally technically more secured than Android devices in the context of technical exploits.

But that does not mean one should feel safer, considering that the #1 reason people get in trouble either way is user behaviour. This is true for any system.

Practice safe online behavior.

Fanboyism is in itself a bad behavior when it comes to security.
 
Last edited:
Getting popcorn ready for when EU users come onto these forums crying about how they got hacked by the non-Apple app stores that they begged for

This topic was bound to come considering Apple education of their most hard working users.

The DMA simply enforces regulations allowing people to equally and freely choose their online suppliers for goods and services regardless of Internet connected device of choice. Steering measures on the back of devices for such purpose will not be allowed on certain classes of devices and platforms.

This simply means that with the DMA in place if iOS device owners prefer having the Apple App Store has their sole supplier because they consider safer or any other reasons they can and will regardless of the regulation.

The only difference for gatekeeping devices such as iOS devices is that people will not be forced to make and will not make that choice when buying their internet connected device and licensing its underlying platform.

It’s that simple.

Users aren’t necessarily more or less secured from a technical stand point.

From a soft stand point in fact, it can be argued that user properties, either end-users or businesses are more secured with the regulations in place. All because, that there is a legal hard limit to how OEMs can exploit user properties to their benefit at users expense, for certain kinds of devices relying on the Internet to function. Such actions become explicit rather transparent to users.

Cheers.
 
Last edited:
It will be, when Apple has to expose same internals. Crowdstrike messed up and Microsoft said those apis shouldn’t have been exposed to crowdstrike if not for EU mandate.
This is nonsense. The reason the CrowdStrike incident happened is because they deployed a code change impacting kernel software (among some other institutional failures). Third-party kernel code had been allowed by Apple for macOS and Microsoft for Windows for years and years but fell out of favor due to security and reliability concerns, alongside performance improvements for userland (non-kernel) alternatives.

Today, Apple chooses not to allow third-party kernel extensions on macOS anymore, but Microsoft, through its own interest in undying backward compatibility, hasn’t made that decision yet. As far as I know, the EU has never specifically mandated that Microsoft allow third-party access to the Windows kernel. You’re welcome to post a source indicating otherwise.

ETA re: institutional failures above: CrowdStrike clearly doesn’t have sufficient testing infrastructure in place, since it seemed like this push hosed just about any Windows machine it touched. Plus, seemingly they don’t allow customers to delay or phase in upgrades to help mitigate massive incidents like this. Having a glorified red button that can instantly break millions of devices if misused and not treating that button with the respect (fear) that deserves is just incredible.
 
Last edited:
  • Like
Reactions: Nuno Lopes
This is nonsense. The reason the CrowdStrike incident happened is because they deployed a code change impacting kernel software (among some other institutional failures). Third-party kernel code had been allowed by Apple for macOS and Microsoft for Windows for years and years but fell out of favor due to security and reliability concerns, alongside performance improvements for userland (non-kernel) alternatives.

Today, Apple chooses not to allow third-party kernel extensions on macOS anymore, but Microsoft, through its own interest in undying backward compatibility, hasn’t made that decision yet. As far as I know, the EU has never specifically mandated that Microsoft allow third-party access to the Windows kernel. You’re welcome to post a source indicating otherwise.

ETA re: institutional failures above: CrowdStrike clearly doesn’t have sufficient testing infrastructure in place, since it seemed like this push hosed just about any Windows machine it touched. Plus, seemingly they don’t allow customers to delay or phase in upgrades to help mitigate massive incidents like this. Having a glorified red button that can instantly break millions of devices if misused and not treating that button with the respect (fear) that deserves is just incredible.

I don’t think it’s good for software to run at kernel level because … well this. It can crash systems unnecessarily. Modern OSs even for security purposes don’t have such a need.

The problem of MS is one of Windows architecture. Some stuff that should be able to do with not kernel previleges, a
simply can’t at a upper layer.
 
This is nonsense. The reason the CrowdStrike incident happened is because they deployed a code change impacting kernel software (among some other institutional failures). Third-party kernel code had been allowed by Apple for macOS and Microsoft for Windows for years and years but fell out of favor due to security and reliability concerns, alongside performance improvements for userland (non-kernel) alternatives.

Today, Apple chooses not to allow third-party kernel extensions on macOS anymore, but Microsoft, through its own interest in undying backward compatibility, hasn’t made that decision yet. As far as I know, the EU has never specifically mandated that Microsoft allow third-party access to the Windows kernel. You’re welcome to post a source indicating otherwise.

ETA re: institutional failures above: CrowdStrike clearly doesn’t have sufficient testing infrastructure in place, since it seemed like this push hosed just about any Windows machine it touched. Plus, seemingly they don’t allow customers to delay or phase in upgrades to help mitigate massive incidents like this. Having a glorified red button that can instantly break millions of devices if misused and not treating that button with the respect (fear) that deserves is just incredible.
Actually, Microsoft itself mentioned that they are required to be complaint (2009 a deal with European Commission) in allowing third party security software developers with the same access level that Microsoft has. I understand that this is not a Microsoft issue but this is available all over the internet.
 
Actually, Microsoft itself mentioned that they are required to be complaint (2009 a deal with European Commission) in allowing third party security software developers with the same access level that Microsoft has. I understand that this is not a Microsoft issue but this is available all over the internet.
Sure, I’m aware of that. Absolutely nothing over the past 15 years has stopped them from working on a userland alternative and discontinuing kernel access once they’re no longer using it for security purposes.
 
The company has ceased the use of Android phones for their employees as a result.

Ok, but putting all your eggs in one technology basket isn’t necessarily great for security either. It might reduce your “attack surface”, but it’s potentially more catastrophic if something goes wrong with your chosen platform and there’s no alternatives available. Businesses that were highly dependent on Windows PCs found that out with the CrowdStrike incident a few weeks ago!

iOS has security flaws too. Just ask our friends at NSO Group!
 
Today, Apple chooses not to allow third-party kernel extensions on macOS anymore, but Microsoft, through its own interest in undying backward compatibility, hasn’t made that decision yet.

Microsoft had tried/planned to do this years ago, when the 64-bit Windows kernel was first introduced in 2006.

But they backed down when security companies filed a complaint with the EU demanding kernel access.

As far as I know, the EU has never specifically mandated that Microsoft allow third-party access to the Windows kernel. You’re welcome to post a source indicating otherwise.

https://arstechnica.com/information-technology/2006/10/7998/
 
Microsoft had tried/planned to do this years ago, when the 64-bit Windows kernel was first introduced in 2006.

But they backed down when security companies filed a complaint with the EU demanding kernel access.



https://arstechnica.com/information-technology/2006/10/7998/
The agreement that came of that is publicly available, and the Windows kernel isn't mentioned at all. Rather, Microsoft agreed to provide equal footing to third-party security software — to give others the same access that they themselves use for security purposes by providing "interoperability information" which would be kept updated over time.

At the time that was written, yes, that did implicitly include granting access to the Windows kernel. But as I mentioned above, absolutely nothing has stopped Microsoft over the past 15 years from implementing userland alternatives for themselves and then (maybe after some grace period) discontinuing third parties' kernel access.
 
  • Like
Reactions: Bungaree.Chubbins
Likely this was a hackable route for many many many many years.

Just goes to show — just because Google & Apple say their phones are secure — doesn’t mean they are. It just means that they aren’t aware of an existing vulnerability
that the government (NSA, CIA etc.) hasn't told them to keep silent about via FISA court etc. There is always that possibility lurking in the background.
 
Likely this was a hackable route for many many many many years.

Just goes to show — just because Google & Apple say their phones are secure — doesn’t mean they are. It just means that they aren’t aware of an existing vulnerability
And in this example the vulnerability is that the owner (the retail store) can install what ever apps they want on the device they own.
 
Tim Cook has been a pretty good CEO overall but one of the dumbest things he ever did was call a truce over Android. It was a stolen product and Steve Jobs was willing and able to go full thermonuclear war for justice, but Tim Cook thought the fight was too expensive and made Steve roll over in his grave.

Today every Android user is paying the price. Too bad they didn't steal the security model of iPhone along with the UI?
 
Google already confirmed it was never exploited.

Users here still don't understand that this app comes deactivated, in order to make it do something you need full device access to activate it.
It's like having a small window that's closed sealed(aka it would be difficult even for the owner to open it)and in order to open in you need full and unrestricted access inside the house which is the purpose in the first place(to have access inside the house) , so that small window is irrelevant.
Because Google, they will not believe it no matter the proof.
 
  • Like
Reactions: robvalentine
https://grapheneos.social/@GrapheneOS/112967309987371034

"Wired was manipulated into spreading misinformation to market Palantir and iVerify by misrepresenting a vulnerability in a disabled demo app as being a serious problem which could be exploited in the real world. They should retract the article but won't."

"iVerify are scammers and anyone paying them money should rapidly stop doing it and remove their malware from their devices. The real security risk is giving remote code execution on your devices to one of these sketchy EDR companies lying about their capabilities and discoveries."


Not much more to say about it.
Given there were a good handful of researchers already commenting on the shady Wired article, i'm surprised MacRumors/@Hartley either didn't do the research or decided to omit the the fact a third-party would need Debug Bridge and device access and user details of the target, rather than punt an article that gives the impression this is a free-fall-all RCE vuln.

Perhaps MacRumors and/or @Hartley can add an update to the article and include those facts?
 
They don’t have to.

This is a demo retail mode app with elevated privileges.

Having such apps with special privileges around (and in this case walking them from dormancy) is the real danger.
Security by obscurity as in “Apple has it but only thy knows about things” does not remedy that at all.
Bear in mind people on here like to bash android without actually paying attention to facts or details.
 
Google already confirmed it was never exploited.

Users here still don't understand that this app comes deactivated, in order to make it do something you need full device access to activate it.
It's like having a small window that's closed sealed(aka it would be difficult even for the owner to open it)and in order to open in you need full and unrestricted access inside the house which is the purpose in the first place(to have access inside the house) , so that small window is irrelevant.
And there is your spin...
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.