ANDROID flaw - Build-in spyware?

[Bob]

Now why would Google give away the Android operating system to so many manufacturers who would then "profit" from the "gift" ?

Could it be, an oversight allowed for millions of phones to at the simple sending of a TEXT MESSAGE to the phone number allow it to be turned into an "android drone" supplying the phone's data, live video and audio to the "hacker" (read spy).. or?

(http://www.bloomberg.com/bw/articles...-all-the-money)

The Spy's best Friend - ANDROID

http://www.npr.org/sections/alltechc...th-just-a-text

Android is the most popular mobile operating system on Earth: About 80 percent of smartphones run on it. And, according to mobile security experts at the firm Zimperium, there's a gaping hole in the software — one that would let hackers break into someone's phone and take over, just by knowing the phone's number.

In this attack, the target would not need to goof up — open an attachment or download a file that's corrupt. The malicious code would take over instantly, the moment you receive a text message.

"This happens even before the sound that you've received a message has even occurred," says Joshua Drake, security researcher with Zimperium and co-author of Android Hacker's Handbook. "That's what makes it so dangerous. [It] could be absolutely silent. You may not even see anything."

Here's how the attack would work: The bad guy creates a short video, hides the malware inside it and texts it to your number. As soon as it's received by the phone, Drake says, "it does its initial processing, which triggers the vulnerability."

The messaging app Hangouts instantly processes videos, to keep them ready in the phone's gallery. That way the user doesn't have to waste time looking. But, Drake says, this setup invites the malware right in.

NPR has asked leading phone makers and wireless service providers whether they'll fix the bug. We're waiting for responses and will post them to this page.

According to security firm F-Secure, 99 percent of mobile malware threats in the first quarter of 2014 were designed to run on Android devices.

[Citizen No2]

THE best protection?

Don't have one.

My mobile is 16 years old. Makes calls just as well. Texts too.

I'm just not plugged into the Net 24/7.


Regards.

[Bob]

Is Google the only giver who keeps on "giving" ? Apparently not.

A manufacturer in China has also felt that spyware backdoors are a GREAT thing to have it's smartphone buyers have, so as to "keep in touch" with a few simple keystrokes.

The hidden malware allows for Coolpad, the third-largest smartphone maker in China and sixth-largest worldwide, to perform unsolicited tasks such as download any Android application without user consent or notification, clear user data, notify users of fake over-the-air software updates that install unwanted applications, upload device information to a Coolpad server and more.

The backdoor has been installed on devices despite objections from customers and complaints about unwanted applications and push-notifications.

CoolPad's backdoor allows for:

• Download, install, or activate any Android application without user consent or notification
• Clear user data, uninstall existing applications, or disable system applications
• Notify users of a fake over-the-air (OTA) update that doesn’t update the device, but installs unwanted applications
• Send or insert arbitrary SMS or MMS messages into the phone.
• Dial arbitrary phone numbers
• Upload information about device, its location, application usage, calling and SMS history to a Coolpad server

Combine that with the "TEXT MESSAGE" flaw, and one's Android OS based phone provides the spy with the best snooping tools ever. And the "customer" paid for it ! What a deal ?!!

(Source)

[wnlight]

What makes you think it's a flaw? Most likely, it is a red herring so to disguise more deeply placed doors into your security.

[Citizen No2]

Do you remember the death of Gareth Williams?

From Wiki:

Gareth Williams (26 September 1978 – c. 16 August 2010) was a Welsh mathematician and employee of GCHQ seconded to the Secret Intelligence Service (SIS or MI6) who was found dead in suspicious circumstances at a Security Service safe house flat in Pimlico, London, on 23 August 2010. The inquest found that his death was "unnatural and likely to have been criminally mediated." A subsequent Metropolitan Police re-investigation concluded that Williams's death was "probably an accident."

This little snippet is of interest:

Soon after the investigation started, the heads of the Secret Intelligence Service and Metropolitan Police met to discuss how the police would handle the investigation in light of the top secret nature of Williams's work, and who would lead the investigation. Williams had recently qualified for operational deployment, and had worked with US National Security Agency and FBI agents. The US State Department asked that no details of Williams's work should emerge at the inquest. The Foreign Secretary, William Hague, signed a Public-interest immunity certificate authorising the withholding from the inquest of details of Williams's work and US joint operations.[

I have it on very good authority that Williams had been working on a piece of tech/equipment that would allow the user to 'suck' all the data from any computerised device. This was a small piece of tech exploiting a back-door in all devices with an operating system and did not require a standard wifi/bluetooth connection.



Regards.

[Bob]

It is called StageFright - the "flaw"..

(From Zimperium, the group who found the "flaw")

Zimperium zLabs VP of Platform Research and Exploitation, Joshua J. Drake (@jduck), dived into the deepest corners of Android code and discovered what we believe to be the worst Android vulnerabilities discovered to date.

These issues in Stagefright code critically expose 95% of Android devices, an estimated 950 million devices. Drake’s research, to be presented at Black Hat USA on August 5 and DEF CON 23 on August 7

Remember that little license agreement which holds Google (and the sub-licensors) invulnerable to legal consequences for such "flaws" ? (oops)..

From the blog page at Zimperium zLabs

"Attackers only need your mobile number, using which they can remotely execute code via a specially crafted media file delivered via MMS. A fully weaponized successful attack could even delete the message before you see it. You will only see the notification.

"These vulnerabilities are extremely dangerous because they do not require that the victim take any action to be exploited.

"Unlike spear-phishing, where the victim needs to open a PDF file or a link sent by the attacker, this vulnerability can be triggered while you sleep.

"Before you wake up, the attacker will remove any signs of the device being compromised and you will continue your day as usual – with a trojaned phone. "

Android and derivative devices after and including version 2.2 are vulnerable. Devices running Android versions prior to Jelly Bean (roughly 11% of devices) are at the worst risk due to inadequate exploit mitigations. If ‘Heartbleed’ from the PC era sends chill down your spine, this is much worse.

In this unique scenario, Zimperium not only reported the vulnerability to the Google teams, but also submitted patches. Considering severity of the problem, Google acted promptly and applied the patches to internal code branches within 48 hours, but unfortunately that’s only the beginning of what will be a very lengthy process of update deployment.

Blog also said this:

Remediation:

Fixes for these issues require an OTA firmware update for all affected devices. Such updates for Android devices have traditionally taken a long time to reach users. Devices older than 18 months are unlikely to receive an update at all. We hope that members of the Android ecosystem will recognize the severity of these issues and take immediate action. In addition to fixing these individual issues, we hope they will also fix any business processes that prevent or slow the uptake of such fixes.

That said, two groups of users are already protected against all reported issues. Users of SilentCircle’s Blackphone have been protected against these issues as of the release of PrivatOS version 1.1.7. Mozilla’s Firefox, which is also affected, has included fixes for these issues since version 38. We applaud these vendors for prioritizing security and releasing patches for these issues quickly.

(The security Company website that discovered the "flaw": https://www.zimperium.com/company )

[Koyaanisqatsi]

Apple propaganda i bet. Someone at ziperiums pockets got lined to write this article i bet.......coming from apple who intentionally adds shortcuts for surveillance into the firmware. Android>iphone

[Bob]

In the OP post 1 Zimperium's chief researcher noted that the messaging APP called "Hangouts" is where the "flaw" was located - https://support.google.com/hangouts/.../3441321?hl=en

From Google's support webpage on HangOuts:

Text messages & Hangouts on Android devices
Send text messages (SMS & MMS) with Hangouts on Android

"When you turn on SMS for your device, all of your existing text messages are imported into the Hangouts app. Text messages sent through your carrier (not Google Voice) are accessible from the Android phone from which they were sent, but not from any other Hangouts on the web, iOS device, or your tablet. You can also view text and Hangouts messages from the same person as one merged conversation."

If you have a Nexus 5, Hangouts is your default text-messaging app and you can't uninstall the app.

To use Hangouts as the default app for text messages for other devices with Android 4.4 or lower, you'll need to turn on SMS for Hangouts. If you need to find out which version you have, go to Settings and choose About phone.

(emphasis added)

"Turn off Hangouts as the default text-messaging app"

• Open Hangouts on your Android device.
• Go to Settings.
• Touch SMS.
• Uncheck "Turn on SMS."

"For versions Android 4.3 and lower, you'll be notified twice if you have another text message app besides Hangouts. You'll need to choose your default text-messaging app to ensure that you receive notifications only once for text messages. If you need to find out which version you have, go to Settings and choose About phone."

(the above is from https://support.google.com/hangouts/.../3441321?hl=en)

==Post Update==

It appears that the PREFERRED solution UNTIL the hardware's firmware coding is changes is to perform the TURN OFF AUTO UPDATE: Hangouts: Settings : SMS : Advanced Settings, unset autoretrieve MMS

See Josh Drake's twitter feed: @jduck for continuing details.

Zimperium says at Black Hat, they will be releasing a video AND the exploit code:

ZIMPERIUM ‏@ZIMPERIUM 7h7 hours ago
[StageFright UPDATE] We will release a video demonstrating the attack later this week and an exploit code right after @jduck's Blackhat talk

[Bob]

WHO was ANDROID before they got eaten by Google?

https://www.android.com/intl/en_us/history/

The Android Story
Android is the operating system that powers more than one billion smartphones and tablets.

Since these devices make our lives so sweet, each Android version is named after a dessert.

Whether it's getting directions or even slicing virtual fruit, each Android release makes something new possible.

mmmmmm cookies, ice cream, yummy, buy the android.. interesting strategy.. refer to the OP.

From website ARS TECHNICA:

In November 2007, two years after Google acquired Android and five months after the launch of the iPhone, Android was announced, and the first emulator was released. Back then, the OS was still getting its feet under it. It was easily dismissed as "just a BlackBerry clone." The emulator used a qwerty-bar skin with a 320x240 display, replicating an actual prototype device. The device was built by HTC, and it seems to be the device that was codenamed "Sooner" according to many early Android accounts. But the Sooner was never released to market.

According to accounts of the early development days of Android, when Apple finally showed off its revolutionary smartphone in January 2007, Google had to "start over" with Android—including scrapping the Sooner. Considering the Milestone 3 emulator came out almost a year after Apple's iPhone unveiling, it's surprising to see the device interface still closely mimicked the Blackberry model instead. While work had no doubt been done on the underlying system during that year of post-iPhone development, the emulator still launched with what was perceived as an "old school" interface. It didn't make a good first impression.

(Source)

Android started as a separate company in 2003. It was run by Andy Rubin and a few other big names in the early world of mobile tech. They were trying to build software for phones and digital cameras. (Business Insider report)

Andy Rubin pix:

Google bought Android in 2005. Andy Rubin and his team quietly worked on what would become the Android mobile operating system.

In 2008, Google partnered with T-Mobile to launch the first-ever Android smartphone, the G1.

Android's true rise began in November 2009 with the launch of the Motorola Droid. This phone ran a new version of Android, version 2.0. It was also a Verizon exclusive, a big win since Verizon didn't offer the iPhone at the time.

Google launched its first-ever smartphone, the Nexus One, in January 2010. This was Google's attempt to shake up the way we buy smartphones. Google sold the unlocked phone exclusively online for $529. T-Mobile customers could get it for $179 with a contract.

2010 was still a huge year for Android. It's when Samsung introduced its first Galaxy S smartphone. It launched in several variants and would eventually grow into the most popular brand of Android devices. To date, Samsung has sold more than 100 million Galaxy phones running on Android operating system.

Google attempted to make a tablet-only version of Android called Honeycomb in early 2011. The operating system launched on a tablet from Motorola called the Xoom. Unfortunately, the Xoom and other Honeycomb tablets didn't sell very well.

November 2011 was also when Samsung launched a massive marketing campaign attacking Apple and the iPhone. Since then, it's spent tens of billions in marketing and has become the biggest smartphone maker in the world. Its Android devices are the most popular.

Strategy
Google took a wildly different approach with Android than Apple did with iOS. Any hardware maker can use Android free of charge. Since Android is packed with excellent Google services like Gmail, Google Now, and Google Maps, most of the hard work was already done for manufacturers like Samsung and HTC.

As a result, manufacturers have been able to flood the market with devices. They've also been able to attack the low-end of the market with cheaper phones.

And apparently have built-in agency loving features - win win win for all the $$$ except for the end user.

[Bob]

Scary stuff here:

ZIMPERIUM ‏@ZIMPERIUM 7h7 hours ago
[StageFright UPDATE] We will release a video demonstrating the attack later this week and an exploit code right after @jduck's Blackhat talk


Did you catch that - the firm that discovered the "flaw" is presenting at the largest hacker conference, how to exploit the code to target any android phone. The firm Zimperium in a marketing strategy says they have the patches, the solutions, and it appears to be an "arms race" to see if the phone manufacturers using ANDROID will patch their phones IN TIME before the "NUKE" is released..

Joshua J. Drake retweeted
ZIMPERIUM ‏@ZIMPERIUM 22h22 hours ago
ZIMPERIUM Customers are protected from the Stagefright vulnerability

NOW WHAT ABOUT THE PEOPLE WHO AREN'T ABLE TO LET THEIR PHONE HAVE UPDATES?

[Bob]

Obtaining the phone numbers one would think is an unsurmountable task because of the encryption, thereby people assuming that they are safe from the StageFright "flaw".

Thing is there is a group - http://www.ntop.org/nprobe/monitorin...-using-nprobe/ who have advanced monitoring tools able to decrypt, record, and provide an amazing amount of information about cellphone traffic.

From the ntop.org website:

the conclusion is that mobile terminals are pretty open thanks to Android, but the network is still very close. This has been the driving force for adding to nProbe the ability to analyse mobile traffic.

Our goal has been the monitoring of mobile network traffic, similar to what happens on standard IP networks in order to answer with some extras. In mobile networks, there is a protocol called GTP (GPRS Tunnelling Protocol) that is decomposed in two separate protocols, GTP-U and GTP-C. Those protocols keep the phone "in-touch" with the cell tower.

With the probe operating, the collector immediately knows the mobile user that has generated the traffic - ALL the details of that cellphone are made available to the recording software.

[LivioRazlo]

I'll actually be attending Blackhat 2015 this year. I'll let you know what comes about of this "vulnerability"; I use the quotations around the word because as a computer scientist, these vulnerabilities are merely poorly written code.

[Bob]

I would only hope it is "poorly written code".. After having dealt now with Google for a half a year, my thoughts are otherwise.

FIREFOX - do you think by switching to monzilla you are safe? Guess what Monzilla did - used the code in StageFright to make video's so easy to play.. (hmmm) One has to have version 38 or later to bypass the "flaw"..

Interestingly, the Stagefright vulnerability also affects Firefox on all platforms except Linux, and that includes the Firefox OS. Firefox developers have patched the vulnerability in versions 38 and up.

"If you install Firefox 38, you can no longer get exploited directly via Firefox," Drake told Ars.

"However, if I make your Firefox download the malicious video instead of trying to play it with a <video width="300" height="150"> tag, it will still reach the vulnerable Android code."

What about Android boxes that don't use the "HangOuts" app?

Josh mentions, all one needs to do is OPEN the other default app, and at that point, the deed is done..

He also mentions that Google feels it has designed in a safety feature (which they probably will tout as a way to downplay the seriousness of the "flaw")

Android is designed with a security sandbox that prevents most apps from being able to access data used by other apps.

He added:

"Successful exploits at the very least provide direct access to a phone's audio and camera feeds and to the external storage. Worse still, many older phones grant elevated system privileges to Stagefright code, a design that could allow attackers access to many more device resources.

"The attacker would have remote arbitrary code execution and thus escaping the sandbox is only a small step away," Drake said. He said existing root exploits, including those known PingPongRoot, Towelroot, and put_user, would likely help an attacker break free of the sandbox and gain much wider control over a vulnerable device.

Source - Ars Technica

[Bob]

Joshua J. Drake, twitter ‏@jduck (Zimperium security researcher)

refers to appearing @_defcon_ BlackHat on August 5th at 3PM, and DEF CON on August 7th at 11AM - https://www.blackhat.com/us-15/brief...art-of-android

The exploit code will be discussed about the ANDROID "flaw" - the conference has more presenters discussing ANDROID issues and holes in the operating system.

He mentions in his twitter feed, that TRENDMICRO (a software antiviral security company) is looking at creating something for phone security.

(reference: https://www.blackhat.com/us-15/brief...l#Joshua-Drake) <<<--- reading this page about what is to be presented IS extremely revealing

DefCon: https://www.defcon.org/html/defcon-2...ers.html#Drake

Josh's bio: Sr. Director of Platform Research and Exploitation at Zimperium and lead author of the Android Hacker's Handbook. Joshua focuses on original research such as reverse engineering and the analysis, discovery, and exploitation of security vulnerabilities. He has over 10 years of experience auditing and exploiting a wide range of application and operating system software with a focus on Android since early 2012. In prior roles, he served at Metasploit and VeriSign’s iDefense Labs. Joshua previously spoke at BlackHat, RSA, CanSecWest, REcon, Ruxcon/Breakpoint, Toorcon, and DerbyCon. Other notable accomplishments include exploiting Oracle's JVM for a win at Pwn2Own 2013, successfully compromising the Android browser via NFC with Georg Wicherski at BlackHat USA 2012, and winning the DEF CON 18 CTF with the ACME Pharm team in 2010.

background: http://blog.zimperium.com/

[ThePythonicCow]

From Stagefright not causing butterflies anymore (PC Perspective):

===========

The Stagefright media player vulnerability on Android powered Nexus devices which allowed the possibility of running remotely execute code via an MMS containing a specially crafted media file. It made headlines everywhere even though it is incredibly unlikely the bug was ever used in an attack. Regardless, you no longer need to worry as Google has crafted a patch and has released it to the carriers. You should keep an eye out this week and next for the update and if you do not see it apply you should reach out to your carrier. More at The Inquirer.

===========

Looks like a good outcome to me ... apparently no one harmed, and the fixes are being rapidly distributed.

[Bob]

BlackHat came, Josh made his presentation, Zimperium released the exploit into the wild, and showed a video of using the attack:

Source: https://youtube.com/watch?v=PxQc5gOHnKs

AND the mention of OLD DEVICES (phones and TABLETS) most likely will NEVER EVER receive that set of patches.

HOW many is that, maybe 80% of the total OLDER devices out there WON'T get patched, leaving them vulnerable.

New phones, new vendor products to be patched. OLD phones dohh..

(Source)

NEW DEVICES with the LATEST google OS that have been patched:

[Bob]

The Patch doesn't work ! (oops..)
Stagefright is still exploitable on 950+ million Android devices.

Well, that is disappointing.. AND has GooGLE (switching to Alphabet), done anything - nope.. not one breath, but to continue to release the OLD patch with the FLAW within it..

(sounds interesting.. just wondering.. that in GooGLE presenting a researcher with a token $ "reward" for his hard work, maybe he would not give it "all" to GooGLE, ('oops'...) and funny GooGLE didn't find the error in the 'fix' - with GooGLE not working with that researcher, why would he continue to 'give' them 'freebies' for his hard work?)

Well here is what has been posted in security researchers who found the bug in the "fix" - http://blog.exodusintel.com/2015/08/...-accomplished/

---------------------

STAGEFRIGHT: MISSION ACCOMPLISHED? (not really...)

Update (2015-08-13 1:16pm CST): We’ve been in contact with Zimperium and are working with them to provide coverage for detection of this flaw through their Stagefright Detector app.

They have been very responsive (more so than the affected vendor) and we plan to alert them of similar flaws we’ve recently discovered.



“Given enough eyeballs, all bugs are shallow”


That famous quote, from Eric S. Raymond’s book The Cathedral and the Bazaar, has inspired us to release new details on the recent Stagefright vulnerability affecting an estimated 950 million Android devices.


The Stagefright vulnerability was initially reported to Google in April 2015 and then publicly in July, just prior to the widely hyped talk at the Black Hat security conference in Las Vegas.

News of the flaw was covered by major media outlets and touted as one of the single worst vulnerabilities to affect the platform.


Along with the initial bug report, a set of patches to stagefright flaws were supplied and accepted by Google. One of these patches, addressing CVE-2015-3824 (aka Google Stagefright ‘tx3g’ MP4 Atom Integer Overflow) was quite simple, consisting of merely 4 lines of changed code, as show below:



1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Fix integer overflow when handling MPEG4 tx3g atom

When the sum of the 'size' and 'chunk_size' variables is larger than 2^32, an integer overflow occurs. Using the result value to allocate memory leads to an undersized buffer allocation and later a potentially exploitable heap corruption condition. Ensure that integer overflow doesnot occur.

Bug: 20923261
Change-Id: Id050a36b33196864bdd98b5ea24241f95a0b5d1f
diff --git a/media/libstagefright/MPEG4Extractor.cpp b/media/libstagefright/MPEG4Extractor.cpp
index 8e47fda..ab1dade 100644
--- a/media/libstagefright/MPEG4Extractor.cpp
+++ b/media/libstagefright/MPEG4Extractor.cpp
@@ -1897,6 +1897,10 @@
size = 0;
}
+ if (SIZE_MAX - chunk_size <= size) {
+ return ERROR_MALFORMED;
+ }
+
uint8_t *buffer = new (std::nothrow) uint8_t[size + chunk_size];
if (buffer == NULL) {
return ERROR_MALFORMED;

According to the original discoverer of the vulnerability, “Basically, within 48 hours I had an email telling me that they had accepted all of the patches I sent them, which was great…You know, that’s a very good feeling.”

Around July 31st, Exodus Intelligence security researcher Jordan Gruskovnjak noticed that there seemed to be a severe problem with the proposed patch. As the code was not yet shipped to Android devices, we had no ability to verify this authoritatively.

In the following week, hackers converged in Las Vegas for the annual Black Hat conference during which the Stagefright vulnerability received much attention, both during the talk and at the various parties and events.

After the festivities concluded and the supposedly patched firmware was released to the public, Jordan proceeded to investigate whether his assumptions regarding its fallibility were well founded. They were.

With the updated firmware flashed to a Nexus 5 device, Jordan crafted an MP4 to bypass the patch and was greeted with the following crash upon testing:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Build fingerprint: 'google/hammerhead/hammerhead:5.1.1/LMY48I/2074855:user/release-keys'
Revision: '11'
ABI: 'arm'
pid: 9614, tid: 9751, name: NuCachedSource2 >>> /system/bin/mediaserver <<<;
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'frameworks/av/media/libstagefright/NuCachedSource2.cpp:580 CHECK_LE( size,(size_t)mHighwaterThresholdBytes) failed: 4294967292 vs. 20971520'

backtrace:
#00 pc 00039f4c /system/lib/libc.so (tgkill+12)
#01 pc 000173c1 /system/lib/libc.so (pthread_kill+52)
#02 pc 00017fd3 /system/lib/libc.so (raise+10)
#03 pc 00014795 /system/lib/libc.so (__libc_android_abort+36)
#04 pc 00012f44 /system/lib/libc.so (abort+4)
#05 pc 00007b51 /system/lib/libcutils.so (__android_log_assert+88)
#06 pc 0008ac89 /system/lib/libstagefright.so (android::NuCachedSource2::readInternal(long long, void*, unsigned int)+80)
#07 pc 0008ade3 /system/lib/libstagefright.so (android::NuCachedSource2::onRead(android::sp const&)+122)
...




Deadline exceeded – automatically derestricting


We notified Google of the issue on August 7th but have not had a reply to our query regarding their release of an updated fix.


Due to this, as well as the following facts, we have decided to notify the public of our findings here on the Exodus Intelligence blog.



The flaw was initially reported over 120 days ago to Google, which exceeds even their own 90-day disclosure deadline.

The patch is 4 lines of code and was (presumably) reviewed by Google engineers prior to shipping.

The public at large believes the current patch protects them when it in fact does not.

The flaw affects an estimated 950 million Google customers.

Despite our notification (and their confirmation), Google is still currently distributing the faulty patch to Android devices via OTA updates.

There has been an inordinate amount of attention drawn to the bug–we believe we are likely not the only ones to have noticed it is flawed. Others may have malicious intentions.
Google has not given us any indication of a timeline for correcting the faulty patch, despite our queries.

The Stagefright Detector application released by Zimperium (the company behind the initial discovery) reports “Congratulations! Your device is not affected by vulnerabilities in Stagefright!” when in fact it is, leading to a false sense of security among users.

Without further preamble, the technical details follow:

As stated above, the fix is as follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
index 8e47fda..ab1dade 100644
--- a/media/libstagefright/MPEG4Extractor.cpp
+++ b/media/libstagefright/MPEG4Extractor.cpp
@@ -1897,6 +1897,10 @@
size = 0;
}
+ if (SIZE_MAX - chunk_size <= size) {
+ return ERROR_MALFORMED;
+ }
+
uint8_t *buffer = new (std::nothrow) uint8_t[size + chunk_size];
if (buffer == NULL) {
return ERROR_MALFORMED;


The patch prevents the undersized allocation of the buffer variable due to the size + chunk_size integer overflow. Thus chunk_size is enforced against SIZE_MAX (0xFFFFFFFF) in order to prevent this behavior.

Even if everything seems right, the elegance of this bug is that it is hiding in plain sight. The one important aspect that is overlooked is the data types of chunk_size and size. Looking at the variable definitions, size is of size_t type which is an unsigned int. However, the flaw manifests due to the type of chunk_size, which is uint64_t.

As chunk_size is a 64 bit variable it may hold values > SIZE_MAX, which can be accomplished thanks to the following code:

762
763
764
765
766
767
768
769
770
771
772
773
774
775
status_t MPEG4Extractor::parseChunk(off64_t *offset, int depth) {
ALOGV("entering parseChunk %lld/%d", *offset, depth);
uint32_t hdr[2];
if (mDataSource->readAt(*offset, hdr, 8) < 8) {
return ERROR_IO;
}
uint64_t chunk_size = ntohl(hdr[0]);
int32_t chunk_type = ntohl(hdr[1]);
off64_t data_offset = *offset + 8;
if (chunk_size == 1) {
if (mDataSource->readAt(*offset + 8, &chunk_size, 8) < 8) {
return ERROR_IO;
}
chunk_size = ntoh64(chunk_size);
In the above, chunk_size is set to a 32-bit value by the ntohl() function, which is sourcing the input from the MP4 metadata. However, if chunk_size is set to 0x01, the if condition (on line 771 above) evaluates as true. Then, a 64-bit value is read from the input MP4 and stored as the chunk_size instead.

For example, if a malicious MP4 is crafted with a chunk_size of 0x1ffffffff (notice this is larger than a 32-bit value) the faulty overflow check will be bypassed because chunk_size > SIZE_MAX. Next, chunk_size is added to size. If size is any value greater than 0, an integer overflow will occur. If, for instance, size is 1, the addition will result in a value of 0x200000000, which is larger than a 32-bit value. The following call to the new operator will truncate that value down to fit into a 32-bit integer, thus allocating an undersized buffer.

1960
uint8_t *buffer = new (std::nothrow) uint8_t[size + chunk_size];
Subsequently, chunk_size worth of data is read into this undersized buffer. Even if the value is truncated to 32-bits, the function will still read 0xFFFFFFFF bytes into the buffer, leading to a heap overflow:

1969
if ((size_t)(mDataSource->readAt(*offset, buffer + size, chunk_size))
As shown above, the issue is still exploitable, despite the patches currently being shipped to Android devices. As of this morning, Google has notified us they have allocated the CVE identifier CVE-2015-3864 to our report.

In summary, the Stagefright disclosure process was an interesting one to observe. The (un)surprising outcome being that given all the exposure this vulnerability received combined with essentially infinite resources on the vendor side, effective security mitigations were still not deployed.

Google employs a tremendously large security staff, so much so that many members dedicate time to audit other vendor’s software and hold them accountable to provide a code fix within a deadline period.

If Google cannot demonstrate the ability to successfully remedy a disclosed vulnerability affecting their own customers then what hope do the rest of us have?

[Bob]

Source: https://youtube.com/watch?v=71YP65UANP0

StargeFright video - Joshua Drake's Black Hat presentation - apx 56 minutes