
Compiler-based security mitigations in Android P - ingve
https://android-developers.googleblog.com/2018/06/compiler-based-security-mitigations-in.html
======
wyldfire
> The UndefinedBehaviorSanitizer's (UBSan) signed and unsigned integer
> overflow sanitization was first utilized when hardening the media stack ...
> we've expanded usage of these sanitizers in the media framework with each
> release.

It's a great step but for anyone else looking to capitalize on UBSan make sure
you couple it with fuzzing or some other testing strategy that will go beyond
just coverage. UBSan won't find latent code that overflows if you don't give
it inputs that actually cause overflows.

~~~
pslam
If this is deployed in release builds — in production — then it is effective
in mitigating anything which isn't covered in fuzzing. Your
application/process gets terminated, which is perfectly acceptable behavior.

------
8bitsrule
As I see it, the main 'security' problems faced by Android are caused by lack
of control and transparency for the user.

Until security threats created by the blinkered users - and by the lack of
timely updates - are made obvious to them, such 'mitigations' are weak tea
indeed.

~~~
pjmlp
The meager adoption of Oreo, barely 10% after one year, with most OEM only now
adopting Nougat for their mid-ranges has finally done it.

In one of IO 2018's keynotes they briefly mentioned that update processes will
be part of future Play Services certification.

------
zokier
> The UndefinedBehaviorSanitizer's (UBSan) signed and _unsigned_ integer
> overflow sanitization

.. but unsigned overflow is not UB? Sure it might not be desirable always, but
that is completely different type of problem

