An iOS zero-click radio proximity exploit odyssey

Re:An iOS zero-click radio proximity exploit odyssey by tptacek on Tuesday December 01, 2020 @06:40PM (#25271543)

We have 30 years of experience showing that ordinary heap overflows are not in fact easy to spot in code review, security review, security audits, and fuzzing. Each of those modalities eliminates a slice of the problem, and some of them --- manual review modalities --- will remove different slices every time they're applied; different test team, different bugs.

To me, this strongly suggests that the problem is in fact memory-unsafe languages, and not general engineering practices.

Apple, by the way, has all the things you're talking about in place, and in spades.

[ Parent | on HN ]

Re:An iOS zero-click radio proximity exploit odyssey by thenewwazoo on Tuesday December 01, 2020 @07:00PM (#25271715)

I agree that the problem is memory-unsafe languages.

You can improve the tools, or you can improve the human, and nobody has managed to improve the human despite decades of trying.

[ Parent | on HN ]

Re:An iOS zero-click radio proximity exploit odyssey by gok on Wednesday December 02, 2020 @01:29AM (#25273777)

OTOH, we don't really have evidence to show that memory safety is effective in kernels/drivers because no memory safe language has ever been deployed at scale for that purpose.

[ Parent | on HN ]

Re:An iOS zero-click radio proximity exploit odyssey by Cyph0n on Tuesday December 01, 2020 @07:16PM (#25271805)

The way I look at it is that relying exclusively on manual review is at best the same as relying on both manual review and a memory safe language.

In practice, the best case and average case rarely line up.

[ Parent | on HN ]

Re:An iOS zero-click radio proximity exploit odyssey by tptacek on Tuesday December 01, 2020 @07:22PM (#25271848)

You don't have to manually review for classes of vulnerability that your programming environment forecloses on.

[ Parent | on HN ]

Re:An iOS zero-click radio proximity exploit odyssey by Cyph0n on Tuesday December 01, 2020 @07:28PM (#25271909)

Good point - all the more reason to use a memory safe language!

[ Parent | on HN ]

Re:An iOS zero-click radio proximity exploit odyssey by scoutt on Wednesday December 02, 2020 @04:09AM (#25274681)

> the problem is in fact memory-unsafe languages, and not general engineering practices.

Languages don't introduce bugs by themselves. Engineers produced those bugs.

I always thought that bugs are the programmers' fault, and not to blame the language. It's like blaming the English language because it allows you to misuse it and manufacture very offensive racial slurs, or to be rude and cruel, and thus we should replace it with another language that doesn't allow to exploit these weaknesses. We won't be able to express ourselves with beautifully (low-level) crafted poems anymore, but that's the price to pay.

[ Parent | on HN ]

Re:An iOS zero-click radio proximity exploit odyssey by tiborsaas on Wednesday December 02, 2020 @06:04AM (#25275317)

There are inherent features of human languages that force you into weird issues. English for example has gender pronouns and that's why you see in profiles how you should approach someone. It's not like they want to add it, it's that they have to if it bothers them when people misuse them.

In Hungarian we don't have this problem at all, there's no concept of gender specific pronouns.

[ Parent | on HN ]