
XNU kernel heap overflow due to bad bounds checking in MPTCP - QUFB
https://bugs.chromium.org/p/project-zero/issues/detail?id=1558
======
WalterBright
I don't see how C will ever be free of buffer overflow bugs without language
changes. Probably the simplest and most effective would be to not have arrays
decay to pointers when passing to a function.

[https://www.digitalmars.com/articles/b44.html](https://www.digitalmars.com/articles/b44.html)

~~~
himom
Rust-style lifetimes. The work by deallocing when the lifetime goes out of
scope. No more memory leaks from non-reference-counted stack pointers (heap
allocs).

Or: use Rust.

~~~
charliesome
Rust lifetimes prevent use-after-frees, but they're totally orthogonal to
buffer overflows. Rust mitigates buffer overflows by automatically inserting
bounds checks and panicking on out-of-bounds access. Your program still
crashes, but you don't potentially open yourself to RCE.

Ultimately Rust's automatic bounds checks rely on higher level facilities in
the language for dealing with slices that C just doesn't have.

~~~
TheDong
Rust has more than just bounds-checks.

Rust heavily encourages the use of iterators and functional-programming both
of which prevent buffer overflows by making code that could overflow less
idiomatic.

~~~
stochastic_monk
This can also be provided by C++ by .at() or iteration through containers.

~~~
bluejekyll
If we’re talking about switching to a new language from C, why only go almost
safe with “modern” C++ and not all the way to fully safe Rust?

I’m not trying to be snarky, but the thread was about Rust as an improvement
to C and you just threw C++ into the mix... which isn’t as safe.

~~~
blub
Actually the thread was about C and someone threw Rust into the mix, as is
typical.

One could go to almost safe C++ because C code compiles with a minimum amount
of changes and turning on compiler warnings, using vector, string and smart
pointers already gives a massive saftety improvement, without a complete
rewrite in a language that's quite different from C, like Rust is.

Smaller costs and still significant benefits in other words.

~~~
bluejekyll
> Actually the thread was about C and someone threw Rust into the mix, as is
> typical.

I was referring to the thread that started a conversation about pointers and
safety in Rust, not to the general post.

You are correct that C and Rust require some more bridging between the
languages, but C++ also requires this when going from objects to C datatypes
and vice versa. Mostly you save a little bit on the header definitions, but
even there, the headers are generally #ifdef'ed to almost illegibility. With
Rust's bindgen tool, getting C headers into Rust is actually quite easy:
[https://rust-lang-nursery.github.io/rust-bindgen/](https://rust-lang-
nursery.github.io/rust-bindgen/)

~~~
blub
Ok, so then we could agree that the more general general topic is safety, so
different options could be discussed: D, Ada, Rust, C++, etc.

The bindgen tool allows integrating C code with Rust code, which means than an
existing C code base can be replaced with Rust step by step.

A C code base can be compiled with some modifications as C++ and then it can
be slowly refactored to use safer C++ idioms. In this case the safety
improvements will be available much faster, even if the resulting code base
won't be as safe as a Rust code base. The culture shock will also not be as
large for the C programmers.

These are non-negligible benefits, and a big reason why C code bases are
moving to C++.

~~~
bluejekyll
Staying a little more focused, I have reasons for none of the languages you
mention, but in terms of ease of integration of C and Rust, here’s one real
world example: [https://people.gnome.org/~federico/blog/librsvg-build-
infras...](https://people.gnome.org/~federico/blog/librsvg-build-
infrastructure.html)

Which recently passed a milestone of having less C than Rust:
[https://www.reddit.com/r/rust/comments/8ofa0w/librsvg_has_no...](https://www.reddit.com/r/rust/comments/8ofa0w/librsvg_has_now_more_rust_code_than_c_code/?st=JI35DG9U&sh=2e2ab3ec)

At this point I personally find it much easier to move C to Rust than C++, and
end up with a much safer codebase.

------
phs318u
FYI this was fixed in both macOS and iOS last updates:
[https://bugs.chromium.org/p/project-
zero/issues/detail?id=15...](https://bugs.chromium.org/p/project-
zero/issues/detail?id=1558#c2)

------
tsomctl
> Note that the MPTCP code does seem to be quite buggy

> ...but is indicative of untested code

That's not encouraging.

~~~
favorited
I'm definitely guilty of not unit testing my error paths robustly. Line-by-
line code coverage reports showed pretty consistent gaps, especially when
operations become no-ops by returning early in case of certain errors.

Kind of surprising that other kinds of testing didn't reveal that bad log
line, since it will always KP...

~~~
candiodari
Unit tests are just example-based tests. They cannot test the code does
nothing wrong in any case, they just test that in 1 specific case, it works.

Only proof-based methods can prove code works under every case.

If you're interested, see Coq [1] (including the first guaranteed-correct C
compiler) or Isabelle.

[1] [https://en.wikipedia.org/wiki/Coq](https://en.wikipedia.org/wiki/Coq)

------
axilmar
This would be caughtable at compile time if the C programming language
supported unions in a better way than it currently does.

Ada, for example, has discriminants, which allows binding of a specific view
of a byte buffer to a specific constant.

There are also other solutions, for example making values to be types.

------
saagarjha
For those unaware, this is not the bug most jailbreakers will use for iOS
11.3.1, because I believe it requires a developer certificate. There is
another, hard to exploit bug that does not.

~~~
pedro84
[https://twitter.com/i41nbeer/status/1004130737174515712](https://twitter.com/i41nbeer/status/1004130737174515712)

""" The trigger is here: [https://bugs.chromium.org/p/project-
zero/issues/detail?id=15...](https://bugs.chromium.org/p/project-
zero/issues/detail?id=1564) … If you're in to iOS exploit dev take a go at it
and blog about it! I'll publish what I have soon, hopefully this week. """

~~~
exikyut
Wow, the thread seems to have attracted a bunch of people that think all that
needs to happen is for someone to sneeze the right way on the exploit and
it'll promptly turn into a perfectly-polished jailbreak app.

Kind of depressing :(

