Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Compiler-based security mitigations in Android P (googleblog.com)
37 points by ingve on June 27, 2018 | hide | past | favorite | 6 comments


> 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.


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.



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.


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.


> 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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: