Kernel buffer overflow exposes iPhone 11 Pro to radio based attacks

[H. S. Teoh]

On Wed, Dec 02, 2020 at 12:31:28PM +0000, Paulo Pinto via Digitalmars-d wrote:
> On Wednesday, 2 December 2020 at 11:19:08 UTC, M.M. wrote:
> > On Wednesday, 2 December 2020 at 11:07:54 UTC, Paulo Pinto wrote:
> > > Yet another proof why system languages like D are required to take
> > > over OS development.
> > > 
> > > https://googleprojectzero.blogspot.com/2020/12/an-ios-zero-click-radio-proximity.html
> > 
> > Why do you think that D is better than C++ in that respect?
> 
> Bounds checking enabled by default.

And also arrays are fat pointers.

It seems like a minor detail, but it makes a huge difference when the
length of the array is always kept together with the pointer to the
array contents, and is supported by the language.  I work with C code
daily, and I cannot tell you how many times I've seen absolutely
terrifying code that simply passes a bare pointer around willy-nilly,
making implicit assumptions about array size that, almost inevitably,
some user code somewhere violates.  Or the number of times I've fixed
bugs involving checking the wrong size against the wrong pointer,
because when you have to manually pass them around, it's easy to make
mistakes.

The worst is C strings.  The number of bugs I've caught involving
(potentially) unterminated strings is absolutely scary.  The worst ones
come from unsanitized input, where the code simply *assumes* that some
random data read from a file is null-terminated.  Just as bad is code
that looks like it was written in the 80's, freely calling strcpy on
char* arguments passed in from who knows where, without a care in the
world.  And yes, such code is still around. And no, it was not written
in the 80's, people still write that garbage *today*, believe it or not.
*This* is why such things must be enforced *in the language*, because
when people are free to do whatever they want, they inevitably gravitate
to the pessimal option.

An equally bad thing about C strings is that utterly evil function known
as strncpy.  Why is it evil?  Because it comes with the warning that the
result may not be terminated if the target buffer is not large enough to
contain the entire string.  And guess how many people gloss over or
simply forget that detail?  Yep, I've fixed a whole bunch of bugs caused
by that.

And don't get me started with casting void* to all sorts of things
willy-nilly. (And in non-trivial code you cannot avoid this, because
that's the only way you can write polymorphic code in C.)

C is just a landmine of memory corruption bugs waiting to happen. The
incentives are just all wrong.  You have to work hard to make your
program memory-safe, and you don't have to lift a finger to incur all
sorts of nasty memory bugs.  All it takes is *one* slip-up somewhere in
some obscure corner in the code, and you have a memory corruption
waiting to happen.

D made a bunch of seemingly-minor, but actually game-changing decisions
that eliminate 95% of the above-mentioned problems.  The single biggest
one is probably the D array aka fat pointer, as far as memory bugs are
concerned.  There are a bunch of others, which others have mentioned.
The general design in D is to make the simplest, most naïve code
memory-safe, and you have to work at it if you want to bypass that
safety net for systems programming reasons.  Which means you'll be
thinking harder about your code, and hopefully more aware of potential
issues and catch yourself before making slip-ups.  That's the way the
incentives should be, not the other way round as it is in C.


T

-- 
Give a man a fish, and he eats once. Teach a man to fish, and he will sit forever.