Any competent malware developer must have already figured out how to exploit this the first time around. Now that every single one of those malware developers has learned it is still exploitable, the payload they've spent the past month perfecting can now be deployed in the wild.
So, can someone explain why a disastrous worm hasn't already swept the globe and infected 99% of Android devices on the planet within ten minutes of being released in the wild?
1. Text payload to victim
2. Payload executes on victim's phone and texts itself to all of the victim's contacts
3. Repeat
Assuming the average Android phone owner has 20 contacts who also have Android phones, and assuming also that texting the payload to those 20 people would take two minutes to complete, the infection would spread exponentially and only take ten minutes for the initial text to result in the infection of 10 billion devices worldwide.
Why am I not currently being bombarded with MMS video texts from infected devices? It frankly seems a bit miraculous. Did Google set up an emergency arrangement with all of the carriers to block suspicious video texts so this wouldn't happen?
It's not often that Android's fragmentation is touted as a benefit, but the fact that Android isn't a monoculture is certainly one of the hurdles to developing a worm capable of mass deployment. Supposedly the varying implementations of the Android media services mean a libstragefright exploit may or may not end up with root access.
Now, if this were an iOS zero-day exploit...
[Actually, it'd be trivial for the carriers to filter the payload, so I don't reckon SMS/MMS is ever going to be a viable transmission vector.]
1. A worm would be highly visible and easily blocked by carriers
2. There's no easy way to make more money from a mass worm than you could make from lower-profile, more-targeted attacks. You could ask a billion people to send you a dollar but that'd leave a paper trail anyone could follow.
3. The more widespread it is, the more pressure there is on vendors & carriers to ship patches for old devices
>So, can someone explain why a disastrous worm hasn't already swept the globe and infected 99% of Android devices on the planet within ten minutes of being released in the wild?
There are a couple of reasons:
1) Just because you have an exploit it doesn't guarantee you'll be able to execute code because you still need to bypass ASLR. The PoC's released do not do this.
2) Infecting phones with malware is very rare. The "tech pundits" like to scare the public, but the reality is that smartphones are rarely infected. Besides, the people that write and distribute malware are too busy infecting Windows machines.
From what I've read, and could be wrong, is you could be infected and not even know it. The attacker has the opportunity to "clean up" the MMS so you never even get a notification because the bug is before any of that kicks in.
Summary: A little over two weeks ago, it was publicly disclosed that MMS messages can cause Android phones to decode video with libstagefright, which is a C++ library with vulnerabilities and insufficient sandboxing, leading to remote code execution without user interaction. Today, Exodus Intelligence is reporting that the patch to fix one of these vulnerabilities does not, in fact, fix it. Thus, all Android phones are still vulnerable.
You can partially mitigate the risk by disabling auto-downloading of MMS messages in whichever app you have set to handle text messages, such as Messaging or Hangouts. If you have not done so already, this is urgent. Furthermore, you should assume that auto-downloading of MMS messages will not ever be safe, no matter how many individual security fixes are applied, until this component of Android is significantly re-architected.
I'm still unclear on the sandboxing assertion. The mediaserver in current versions is, in fact, pretty well isolated. I've had to work around and defeat lots of this protection for debugging purposes in my professional life, so I know it's there. IIRC you can't read system or app data outside the sdcard area, you can't write anywhere persistent. You can open network sockets and make binder requests, which is not trivial but again rather different from a remote root.
That this is an exploitable bug in libstagefright seems to be uncontested. But AFAICT there are no assertions of an actual sandbox breakout or a practical payload that does something more than e.g. send spam. Are there? Link?
This specific exploit can be initiated whenever metadata for an MP4 file is processed. Disabling auto-download of MMS is an important first step workaround. Be cautious with any untrusted media files on your Android device. Simply creating the thumbnail preview image is enough to silently trigger privileged code execution.
July 31st - Author noticed patch was not sufficient but could not test (did not notify google)
August 6th - Patch released
August 7th - Author notified google that patch was not adequate
August 13th - Author went public?!?!
They are counting the original date of exploitation as the start date for notification. I would think a more responsible and friendly date would be August 7th. Just me.
I sympathise with your point, but one complicating factor is that when big security vulnerabilities like Stagefright are found a lot of people then turn their attention to that code. Either finding other issues in the same code, or that the patch isn't fully effective. It was similar with Shellshock, where there was a series of patches as more issues were found because suddenly people were looking at this bit of code that had previously been uninteresting.
I'm not sure keeping it secret for long serves much purpose in this kind of situation; the eye of Sauron is already gazing on the code in question. I doubt these people were the only ones to notice that the patch didn't completely fix the problem.
OTOH, it's highly likely that other people already found this. So by disclosing now, they are still helping users by making sure they don't think this bug was fixed.
But they shouldn't try to justify it based on the timelines. Especially if they noticed a bug in the original patch, but held off on saying anything.
At the same time.... It's business. They didn't act maliciously (exploiting or selling the exploit to bad actors). If the way to build a career is to rack up CVEs, well then that's what people will do, right?
August 13th - Still no response from google(!), disclosing publicly.
Basically that's integer type overflow, the moment I saw the four line patch, I knew what it was going to be. Everyone else would see that too cause it's a classic and can modify whatever exploit code they already have in a matter of minutes to work again.
I have a nit too. I don't like the term "responsible" used in this context. I prefer coordinated if anything. The responsible as in responsible disclosure is such a loaded term.
By the severity and simplicity here as well as the attention from the recent talk, this was a fine course of events in my personal opinion.
What I wish would have happened is someone at google would have done a better code review and caught the bug, it's pretty glaring as these things go, but still it happens all the time so considering that the patches were simply applied the next option I wish would have happened otherwise is that someone at google would have responded. In a case like this I would have liked to see a day or two at the most.
But none of that happened and considering the other concerns laid-out in the post, releasing the info publicly after almost a week is pretty responsible.
I sympathize, but there weren't enough details for Joe Random to build an exploit. This was an attempt to apply pressure, and it did it in the right way, by telling people how they can defend themselves.
Unlike Shellshock which was all over the freaking place, neither I nor my colleagues have gotten any suspicious MMS messages.
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.
This was one of the big motivating factors for me getting a nexus 6 (aside from the size) and putting it on the fi network. I got 2 updates in the period of a week.
I think the problem is vendors and carriers wanting to modify and inject their crapware and custom UIs into Android. Google is happy to provide upgrades to the OS in a timely fashion (and are going to start monthly updates), it's the vendors/carriers that delay these updates or don't even bother to port them over to devices.
Google is moving much of the core Android functionality over to specific apps that they can update as needed from the play store, instead of integrating them directly into the OS. This is good, because it allows them to push the updates quicker. They run the risk that carriers will get sick of the lack of control over the "experience" they can provide, and fork android, but it's a necessary step in many ways to ensure things like this MMS exploit can be patched on some devices at all, as vendors abandon some phones quickly, leaving users vulnerable.
If every vendor and carrier used stock nexus android without modification, the updates could be pushed out in days. The linked article blames google for these problems, but that is, in my opinion, misguided.
> Even if Google patches this, there's an incredible delay in getting the patch to users.
I don't think delay is the problem - not being able to get or apply the patch yourself is the problem. Ignoring the somewhat ridiculous requirements to compile Android (200GB of HD space and 16GB of RAM [1]) - you couldn't put it on your Android device due to proprietary drivers for wireless and/or video.
Assuming you can get an updated version - I have noticed that after getting root on my Nexus 6 it won't install new versions of Android. I don't know if it's a by-product of getting root/installing a new recovery or if they have an actual check. I have a legitimate reason for root because I use FreeOTP and it does not have an export feature - so I use Titanium backup to backup and restore the app. Getting the OTP QR codes for: dropbox, gmail, Microsoft account, facebook, srchub, github, paypal etc would take a very long time and considerable effort to recover (hint gitlab).
There is a major issue, not sure if in the rest of the world, but in Canada, the service provider has to request, and commonly pay for, the patch to which the manufacturer completes and then the service provider then pushes out to their devices. At least that is how it was when the E911 issue happened, it may be better now, but knowing Telecoms in Canada, I wouldn't be surprised if it wasn't.
Did I read that right? They reported the bug to Google on August 7th and disclosed it publicly on August 13th?
Is this still responsible disclosure if they give Google basically 6 days to respond and use the original notification date as justification? I'm not learned enough in the practice of responsible disclosure to know if this is common, but I've not seen that before.
Doesn't seem very responsible behavior by the reporter. Google accepted the suggested patches, fixed the original cases. Now some other cases are discovered for these larger numbers, OK, that seems like a new thing to fix next. Not sure why I have to read paragraphs of hate when the company put the suggested patches in already. Seems like just an excuse so they can ride the page view wave.
And I was wondering at the beginning of the article why they were doing
if (SIZE_MAX - chunk_size <= 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 could add that to the language in a backwards-compatible way? Maybe add a new builtin (compiler-specific, but shared by popular implementations?) like
if __no_overflow(x + y > z)
that would make the addition of two ints become long, two shorts become int32, and so on. (Two long longs would internally become BigNums, but that wouldn't be exposed.)
And while we're at it, add a __checked(a+b) construct, that sets a flag if overflow occurs (or maybe raises an assertion - or maybe we should have both options).
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.
>Deadline exceeded – automatically derestricting
>The flaw was initially reported over 120 days ago to Google, which exceeds even their own 90-day disclosure deadline.
It always seemed likely that Google's hubris[1] would come back to haunt them. I guess this is that day.
It would be funny if it wasn't remote code execution affecting 950 million phones, with no official patch in sight.
They have become a bit more flexible[0] after the Windows issue. They are still living by the 90 day policy, but baked in some flexibility if the vendor is communicating with them.
Why are arithmetic overflows and underflows not exceptions/crashes by default, like divison by 0?
Aren't the cases where you actually want an over/underflow the exception? Why not resort to special instructions/macros/operators for these operations?
You could actually have runtime checks by default (in a hypothetical language), and have a smart compiler elide them whenever possible.
int32 a, b = ...;
a+b; // there is a check
// implicitly:
// if (MAX_INT32 - a <= b) throw OverflowException;
// a+b;
but
int32 a = ...;
// after here: typeof(a) = int32
int32 b = rand_int(0, 1000);
// after here: typeof(b) = int32[x|where x >=0 and x < 1000]
if (a < 500) {
// in here: typeof(a) = int32[x|where x < 500]
a+b; // the overflow check can be elided
}
So the compiler would be able to narrow down the type of a variable, and know what operations are safe to perform. This is probably impossible in the general case (halting problem and so on), but I believe it is very doable if you restrict yourselves to a limited number of subranges. This is like a kind of dependent types, but completely internal (you could expose them, if you wanted though).
The compiler can't only use this extra information to remove overflow checks, but you can also have a language that guarantees there is no overflow - add two int32 and the result is an int64, and so on. And if it can infer that the result fits in an int16, then it can put it in there. But most of the time you would just use int, which means: integer variable of enough length to store my data. int8, int16, int32, maybe a BigNum. Kind of like python does it, but with the ability to pick optimized native types if needed.
This is a common problem in C. Integer types are inherently type unsafe and are silently promoted with many different rules which are hard to remember and understand. As is seen in this case, even the ( borderline paranoid ) flag -Wconversion would not catch the bug.
I think this problem in C would be solved with a single flag: -Wwarn-if-using-integers-of-different-types-in-an-operation , forcing you to cast the integer if the types don't match in a arithmetic operation, or an assignment.
The bigger issue of libstagefright is that it there's a ton of code involved with media playback at the native level that has access to many system resources. This specific exploit was just looking at a small part of the MP4 handling -- one of the many parts within the library. It is very likely more severe exploits like this one will surface as a result of this huge library.
It's a bit surprising because so much of Android is written in Java. Given hardware decoding of the video itself I wonder why Stagefright needs to be written in C++ at all. Media processing code has been notorious for being exploit ridden for years, so it's not like this problem was unpredictable.
Can carriers (and by extension, the Hangouts backend itself) check messages and block "evil" ones? Wouldn't that be an easier way of fixing these things quickly?
At the very least, Google should block any Hangouts message that triggers the bug even on non-updated devices.
if (chunk_size >= SIZE_MAX - size) {
return ERROR_MALFORMED;
}
Due to size being a size_t and SIZE_MAX being well a maximum size_t, SIZE_MAX-size is properly calculated. The comparison with chunk_size is also properly done (due to the C promotion rules - as strange as they are, they do work "as expected" when your values are nonnegative, which they are here).
Also, I am slightly puzzled why one would use SIZE_MAX as a limit rather than some "small" number, like a few megabytes or whatever is a reasonable bound for this buffer. In this case the fix may be a bit more complex than this: if (chunk_size >= SIZE_MAX - size || size + chunk_size > the_limit) .
There was an Android update pushed to my phone recently. I wanted to know if it was an urgent security fix so I checked the diffs. It's hard to tell but it doesn't seem to be. It's a bunch of fixes to do with video out, SIP etc.
I thought maybe the patch fixed this security flaw. It wasn't clear what it was for from the phone. I had to do a fair bit of digging. Are there any change-logs or release notes for these system updates?
Things like this is why I trust an iPhone enough to handle two-factor auth for banking (in Sweden: "Mobil BankId"), but not an Android device.
I hope Google will raise the security level now that they have reached global dominance, in no small part through lax security (as a consequence to their liberal licensing models).
[+] [-] stevenh|10 years ago|reply
So, can someone explain why a disastrous worm hasn't already swept the globe and infected 99% of Android devices on the planet within ten minutes of being released in the wild?
1. Text payload to victim
2. Payload executes on victim's phone and texts itself to all of the victim's contacts
3. Repeat
Assuming the average Android phone owner has 20 contacts who also have Android phones, and assuming also that texting the payload to those 20 people would take two minutes to complete, the infection would spread exponentially and only take ten minutes for the initial text to result in the infection of 10 billion devices worldwide.
Why am I not currently being bombarded with MMS video texts from infected devices? It frankly seems a bit miraculous. Did Google set up an emergency arrangement with all of the carriers to block suspicious video texts so this wouldn't happen?
[+] [-] NateLawson|10 years ago|reply
https://twitter.com/jcase/status/628327791713517570
However, this only works in the US when you have 6 carriers. I have no idea what the situation is like elsewhere with massive carrier fragmentation.
[+] [-] ryandvm|10 years ago|reply
Now, if this were an iOS zero-day exploit...
[Actually, it'd be trivial for the carriers to filter the payload, so I don't reckon SMS/MMS is ever going to be a viable transmission vector.]
[+] [-] acdha|10 years ago|reply
1. A worm would be highly visible and easily blocked by carriers
2. There's no easy way to make more money from a mass worm than you could make from lower-profile, more-targeted attacks. You could ask a billion people to send you a dollar but that'd leave a paper trail anyone could follow.
3. The more widespread it is, the more pressure there is on vendors & carriers to ship patches for old devices
[+] [-] mike_hearn|10 years ago|reply
[+] [-] guelo|10 years ago|reply
[+] [-] bitmapbrother|10 years ago|reply
There are a couple of reasons:
1) Just because you have an exploit it doesn't guarantee you'll be able to execute code because you still need to bypass ASLR. The PoC's released do not do this.
2) Infecting phones with malware is very rare. The "tech pundits" like to scare the public, but the reality is that smartphones are rarely infected. Besides, the people that write and distribute malware are too busy infecting Windows machines.
[+] [-] danielweber|10 years ago|reply
2. The MMS system isn't as anonymous as the Internet and someone didn't want to burn an identity making this worm.
3. A combination of 1 and 2, where the people with technical skill to do this would only use it on specific targets.
[+] [-] djb_hackernews|10 years ago|reply
[+] [-] dmitrygr|10 years ago|reply
[+] [-] m3rc|10 years ago|reply
EDIT: I just checked and sure enough my texting app, QKSMS, updated to remove the Stagefright library
[+] [-] jimrandomh|10 years ago|reply
You can partially mitigate the risk by disabling auto-downloading of MMS messages in whichever app you have set to handle text messages, such as Messaging or Hangouts. If you have not done so already, this is urgent. Furthermore, you should assume that auto-downloading of MMS messages will not ever be safe, no matter how many individual security fixes are applied, until this component of Android is significantly re-architected.
[+] [-] ajross|10 years ago|reply
That this is an exploitable bug in libstagefright seems to be uncontested. But AFAICT there are no assertions of an actual sandbox breakout or a practical payload that does something more than e.g. send spam. Are there? Link?
[+] [-] pacquiao882|10 years ago|reply
[+] [-] hoopism|10 years ago|reply
April 2015 - Original stagefright exposed
July 31st - Author noticed patch was not sufficient but could not test (did not notify google)
August 6th - Patch released
August 7th - Author notified google that patch was not adequate
August 13th - Author went public?!?!
They are counting the original date of exploitation as the start date for notification. I would think a more responsible and friendly date would be August 7th. Just me.
[+] [-] anon1385|10 years ago|reply
I'm not sure keeping it secret for long serves much purpose in this kind of situation; the eye of Sauron is already gazing on the code in question. I doubt these people were the only ones to notice that the patch didn't completely fix the problem.
[+] [-] MichaelGG|10 years ago|reply
But they shouldn't try to justify it based on the timelines. Especially if they noticed a bug in the original patch, but held off on saying anything.
At the same time.... It's business. They didn't act maliciously (exploiting or selling the exploit to bad actors). If the way to build a career is to rack up CVEs, well then that's what people will do, right?
[+] [-] mzs|10 years ago|reply
August 13th - Still no response from google(!), disclosing publicly.
Basically that's integer type overflow, the moment I saw the four line patch, I knew what it was going to be. Everyone else would see that too cause it's a classic and can modify whatever exploit code they already have in a matter of minutes to work again.
I have a nit too. I don't like the term "responsible" used in this context. I prefer coordinated if anything. The responsible as in responsible disclosure is such a loaded term.
By the severity and simplicity here as well as the attention from the recent talk, this was a fine course of events in my personal opinion.
What I wish would have happened is someone at google would have done a better code review and caught the bug, it's pretty glaring as these things go, but still it happens all the time so considering that the patches were simply applied the next option I wish would have happened otherwise is that someone at google would have responded. In a case like this I would have liked to see a day or two at the most.
But none of that happened and considering the other concerns laid-out in the post, releasing the info publicly after almost a week is pretty responsible.
[+] [-] danielweber|10 years ago|reply
Unlike Shellshock which was all over the freaking place, neither I nor my colleagues have gotten any suspicious MMS messages.
[+] [-] archmikhail|10 years ago|reply
http://www.extremetech.com/mobile/197346-google-throws-nearl...
[+] [-] lumpygravy|10 years ago|reply
https://www.reddit.com/r/MotoX/comments/3gugxa/anyone_got_th...
[+] [-] AUmrysh|10 years ago|reply
I think the problem is vendors and carriers wanting to modify and inject their crapware and custom UIs into Android. Google is happy to provide upgrades to the OS in a timely fashion (and are going to start monthly updates), it's the vendors/carriers that delay these updates or don't even bother to port them over to devices.
Google is moving much of the core Android functionality over to specific apps that they can update as needed from the play store, instead of integrating them directly into the OS. This is good, because it allows them to push the updates quicker. They run the risk that carriers will get sick of the lack of control over the "experience" they can provide, and fork android, but it's a necessary step in many ways to ensure things like this MMS exploit can be patched on some devices at all, as vendors abandon some phones quickly, leaving users vulnerable.
If every vendor and carrier used stock nexus android without modification, the updates could be pushed out in days. The linked article blames google for these problems, but that is, in my opinion, misguided.
[+] [-] nadams|10 years ago|reply
I don't think delay is the problem - not being able to get or apply the patch yourself is the problem. Ignoring the somewhat ridiculous requirements to compile Android (200GB of HD space and 16GB of RAM [1]) - you couldn't put it on your Android device due to proprietary drivers for wireless and/or video.
Assuming you can get an updated version - I have noticed that after getting root on my Nexus 6 it won't install new versions of Android. I don't know if it's a by-product of getting root/installing a new recovery or if they have an actual check. I have a legitimate reason for root because I use FreeOTP and it does not have an export feature - so I use Titanium backup to backup and restore the app. Getting the OTP QR codes for: dropbox, gmail, Microsoft account, facebook, srchub, github, paypal etc would take a very long time and considerable effort to recover (hint gitlab).
[1] https://source.android.com/source/building.html
[+] [-] kreutzwj|10 years ago|reply
There is a major issue, not sure if in the rest of the world, but in Canada, the service provider has to request, and commonly pay for, the patch to which the manufacturer completes and then the service provider then pushes out to their devices. At least that is how it was when the E911 issue happened, it may be better now, but knowing Telecoms in Canada, I wouldn't be surprised if it wasn't.
[+] [-] josh2600|10 years ago|reply
Is this still responsible disclosure if they give Google basically 6 days to respond and use the original notification date as justification? I'm not learned enough in the practice of responsible disclosure to know if this is common, but I've not seen that before.
[+] [-] lnanek2|10 years ago|reply
[+] [-] captainmuon|10 years ago|reply
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 could add that to the language in a backwards-compatible way? Maybe add a new builtin (compiler-specific, but shared by popular implementations?) like
that would make the addition of two ints become long, two shorts become int32, and so on. (Two long longs would internally become BigNums, but that wouldn't be exposed.)And while we're at it, add a __checked(a+b) construct, that sets a flag if overflow occurs (or maybe raises an assertion - or maybe we should have both options).
[+] [-] CUViper|10 years ago|reply
As for __checked, gcc has some builtins like this: https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins...
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] autobahn|10 years ago|reply
Meaning that while the vulnerable is technically exploitable, the chance of system compromise is very low on modern android phones (I think post 4.0)
[+] [-] anon1385|10 years ago|reply
It always seemed likely that Google's hubris[1] would come back to haunt them. I guess this is that day.
It would be funny if it wasn't remote code execution affecting 950 million phones, with no official patch in sight.
[1] https://news.ycombinator.com/item?id=8896221
[+] [-] kyrra|10 years ago|reply
[0] http://googleprojectzero.blogspot.com/2015/02/feedback-and-d...
[+] [-] VMG|10 years ago|reply
Aren't the cases where you actually want an over/underflow the exception? Why not resort to special instructions/macros/operators for these operations?
[+] [-] captainmuon|10 years ago|reply
The compiler can't only use this extra information to remove overflow checks, but you can also have a language that guarantees there is no overflow - add two int32 and the result is an int64, and so on. And if it can infer that the result fits in an int16, then it can put it in there. But most of the time you would just use int, which means: integer variable of enough length to store my data. int8, int16, int32, maybe a BigNum. Kind of like python does it, but with the ability to pick optimized native types if needed.
[+] [-] CUViper|10 years ago|reply
https://github.com/rust-lang/rfcs/blob/master/text/0560-inte...
[+] [-] ploxiln|10 years ago|reply
[+] [-] cautious_int|10 years ago|reply
This is defined and perfectly normal.
However signed integers will cause undefined behavior on overflow and there is a common flag in most compilers to trap on overflow.
[+] [-] cautious_int|10 years ago|reply
I think this problem in C would be solved with a single flag: -Wwarn-if-using-integers-of-different-types-in-an-operation , forcing you to cast the integer if the types don't match in a arithmetic operation, or an assignment.
[+] [-] pacquiao882|10 years ago|reply
[+] [-] mike_hearn|10 years ago|reply
[+] [-] ikeboy|10 years ago|reply
At the very least, Google should block any Hangouts message that triggers the bug even on non-updated devices.
[+] [-] ambrop7|10 years ago|reply
// size_t size; // uint64_t chunk_size;
if (chunk_size >= SIZE_MAX - size) { return ERROR_MALFORMED; }
Due to size being a size_t and SIZE_MAX being well a maximum size_t, SIZE_MAX-size is properly calculated. The comparison with chunk_size is also properly done (due to the C promotion rules - as strange as they are, they do work "as expected" when your values are nonnegative, which they are here).
Also, I am slightly puzzled why one would use SIZE_MAX as a limit rather than some "small" number, like a few megabytes or whatever is a reasonable bound for this buffer. In this case the fix may be a bit more complex than this: if (chunk_size >= SIZE_MAX - size || size + chunk_size > the_limit) .
[+] [-] jsingleton|10 years ago|reply
I thought maybe the patch fixed this security flaw. It wasn't clear what it was for from the phone. I had to do a fair bit of digging. Are there any change-logs or release notes for these system updates?
[+] [-] RexRollman|10 years ago|reply
[+] [-] mondoshawan|10 years ago|reply
Looks like Cyanogenmod has patched this toot-sweet.
[+] [-] gionn|10 years ago|reply
[+] [-] johansch|10 years ago|reply
I hope Google will raise the security level now that they have reached global dominance, in no small part through lax security (as a consequence to their liberal licensing models).