Android libstagefright still exploitable

Post by eropple » Thu, Aug 13, 2015, 6:09 PM UTC

ocdtrekkie wrote: post #38

lumpygravy wrote: post #33

Earlier quoted context omitted.

Indeed. Even the supposedly quickly updated Moto X did not receive a patch yet two weeks after the fact [1]. I feel sorry for all those people who are still stuck on Kit Kat or even worse Jelly Bean. https://www.reddit.com/r/MotoX/comments/3gugxa/anyone_got_th...

And for those of us who don't want Lollipop, we'll never be offered the update. We have to either accept a bad system "upgrade" or stay insecure.

Post by oconnor663 » Thu, Aug 13, 2015, 6:09 PM UTC

ocdtrekkie wrote: post #26

matthewmacleod wrote: post #22

Earlier quoted context omitted.

I shouldn't be required to do to get security releases. Why should you not be required to do that?

Because withholding security updates over accepting horrifically invasive UI and branding changes is unacceptable. Similar to Microsoft still patching Vista nearly ten years later, Google should be obligated to deliver security patches to all versions of Android within a reasonable timeframe.

Post by tossera » Thu, Aug 13, 2015, 6:10 PM UTC

josh2600 wrote: post #15

jimrandomh wrote: post #10

Earlier quoted context omitted.

It isn't a new bug; what they're reporting is that the patch which was supposed to fix an already-publicly-disclosed bug doesn't fully fix it.

Can you help me understand this? They're complaining about a bug in the patch implementation and the patch implementation did not exist prior to the patch; ergo, if Google didn't patch the code, they wouldn't be able to write the article. Is that not a new bug almost definitionally? Please help me understand if I am incorrect. I understand the underlying issue which was first reported did not get patched properly, bu…

Post by captainmuon » Thu, Aug 13, 2015, 6:14 PM UTC

CUViper wrote: post #35

captainmuon wrote: post #27

And I was wondering at the beginning of the article why they were doing if (SIZE_MAX - chunk_size and not the more readable if (size + chunk_size >= SIZE_MAX) Of course, C integer overflow. The real WTF is that this is possible in C. What would be more sensible than integer overflow would be to automatically promote integers to a larger type in the context of a comparison, so that they don't overflow. I wonder if you…

You seem to be asking for quite some magic in that __no_overflow idea. It might be possible with a trivial expression like this, but what if there are function calls in that expression, or even library calls? There are lots of places overflow could happen, and the site of your __no_overflow may not have code-gen control over it at all. As for __checked, gcc has some builtins like this: https://gcc.gnu.org/onlinedocs/…

    int32_t plus(int32_t left, int32_t right);

    int64_t plus(int32_t left, int32_t right);

    int32_t a = 2000000000;
    int32_t b = 2000000000;
    int64_t c = __no_overflow(a+b);
    // now c is 4000000000;

Post by x0x0 » Thu, Aug 13, 2015, 6:15 PM UTC

oconnor663 wrote: post #43

ocdtrekkie wrote: post #26

Earlier quoted context omitted.

Because withholding security updates over accepting horrifically invasive UI and branding changes is unacceptable. Similar to Microsoft still patching Vista nearly ten years later, Google should be obligated to deliver security patches to all versions of Android within a reasonable timeframe.

I think it's more difficult to patch old versions of Android than you're suggesting. You can't just backport a few lines of code and hope for the best. You have to maintain all the testing infrastructure that you had in place back when that version was supported, to avoid introducing new bugs with your change. And if you're releasing a security fix, you now have to coordinate that release across all versions that wer…