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.
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.
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.
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 apples approach is that even if someone finds and reports the vulnerability for the bounty, 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 vulnerable is more likely to be caught before it reaches consumer devices.
You can argue that the 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.
Rustmilian@lemmy.world 10 months ago
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. 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.
PlexSheep@feddit.de 10 months ago
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.
Rustmilian@lemmy.world 10 months ago
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.
8ender@lemmy.world 10 months ago
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.
Rustmilian@lemmy.world 10 months ago
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 apples approach is that even if someone finds and reports the vulnerability for the bounty, 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 vulnerable is more likely to be caught before it reaches consumer devices.
You can argue that the 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.