Due to complexity and limited auditing a number of vulnerabilites have slipped through again & again, like zero-click exploits for example. Take a look at the sear volume of CVEs and more importantly what they entail.
While they do eventually get found & patched, its not ideal compared to other messaging apps like signal that are very much security first, features 2nd.
A lot of people(normies), especially Apple users tend to think it’s super secure virtually impenetrable technology.
The sheer volume of cves is not necessarily an indicator for insecurity. The CVE system is pretty bad and rulings are mostly arbitrary. For example, there was a recent curl “CVE”, where an overflow happened in some part of the app which was not relevant to security. I don’t remember the details, but the only solution to this apperent mess was that the main contributor of curl is becoming one of the guys that evaluate CVEs.
CVE is a measure for the US government, and always assumes the worst in any case.
I know what curl CVE you’re referring too.
Yeah, that was pretty stupid, they marked it high severity when 1 It was already patched like a year prior and 2 it was a complete non-issue in the first place.
Then some fuckin AI put forth another bogus CVE based on the one you’re referring.
The curl dev was pissed, and rightfully so.
And You’re right, it’s more so the details of the CVEs that’s important then the actual CVEs themselves.
My man everyone and their favourite state sponsored hacking group is trying to break iMessage, of course there’s going to be a shed load of CVEs compared to other less popular tools.
The main problem with iMessage is the limited audits. It’s a very complex application and with that complexity comes higher risk for vulnerabilities to slip through. It’d be way less of an issue if it was at least source available so more people could audit it, instead of just whomever gets permission from Apple.
Like Apple’s bounty system is great and all, but it’s not as effective as for example being able to directly scrutinize signals open source codebase.
The problem with Apple’s approach is that even if someone finds and reports the vulnerability for the bounty money, that still means that vulnerability has made it into the production code and thus made it onto consumer devices. Unlike an open codebase where the vulnerability is more likely to be caught before it reaches consumer devices.
You can argue that the code being openly available isn’t necessary indictive of being secure, which is true, but it’s certainly more favorable and for signal it’s worked out very well. Also there’s plenty of state sponsored hacking groups trying to break signal. Maybe not as many, sure. However it’s a lot less likely they’ll succeed in breaking signal then iMessage.
Infact, just recently signal had to dismiss a 0-day vulnerability report people were freaking out about because it turned out completely bogus. Thought, I suppose that’s beside the point.
“Security through obscurity is not security” - some guy idk.
Due to complexity and limited auditing a number of vulnerabilites have slipped through again & again, like zero-click exploits for example. Take a look at the sear volume of CVEs and more importantly what they entail. While they do eventually get found & patched, its not ideal compared to other messaging apps like signal that are very much security first, features 2nd.
A lot of people(normies), especially Apple users tend to think it’s super secure virtually impenetrable technology.
The sheer volume of cves is not necessarily an indicator for insecurity. The CVE system is pretty bad and rulings are mostly arbitrary. For example, there was a recent curl “CVE”, where an overflow happened in some part of the app which was not relevant to security. I don’t remember the details, but the only solution to this apperent mess was that the main contributor of curl is becoming one of the guys that evaluate CVEs.
CVE is a measure for the US government, and always assumes the worst in any case.
That being said, I agree with you.
I know what curl CVE you’re referring too.
Yeah, that was pretty stupid, they marked it high severity when 1 It was already patched like a year prior and 2 it was a complete non-issue in the first place.
Then some fuckin AI put forth another bogus CVE based on the one you’re referring.
The curl dev was pissed, and rightfully so.
And You’re right, it’s more so the details of the CVEs that’s important then the actual CVEs themselves.
My man everyone and their favourite state sponsored hacking group is trying to break iMessage, of course there’s going to be a shed load of CVEs compared to other less popular tools.
The main problem with iMessage is the limited audits. It’s a very complex application and with that complexity comes higher risk for vulnerabilities to slip through. It’d be way less of an issue if it was at least source available so more people could audit it, instead of just whomever gets permission from Apple.
Like Apple’s bounty system is great and all, but it’s not as effective as for example being able to directly scrutinize signals open source codebase.
The problem with Apple’s approach is that even if someone finds and reports the vulnerability for the bounty money, that still means that vulnerability has made it into the production code and thus made it onto consumer devices. Unlike an open codebase where the vulnerability is more likely to be caught before it reaches consumer devices.
You can argue that the code being openly available isn’t necessary indictive of being secure, which is true, but it’s certainly more favorable and for signal it’s worked out very well. Also there’s plenty of state sponsored hacking groups trying to break signal. Maybe not as many, sure. However it’s a lot less likely they’ll succeed in breaking signal then iMessage.
Infact, just recently signal had to dismiss a 0-day vulnerability report people were freaking out about because it turned out completely bogus. Thought, I suppose that’s beside the point.
“Security through obscurity is not security” - some guy idk.