Transcriber’s note: this is copied mostly verbatim from the UFSC channel Discord chat on 2016-12-06. The commentary is mostly by Discord user Festercluck. I have trimmed away most intervening chat, but where another user’s question or comment seemed relevant for clarity I have maintained it < in angle brackets >.
I’ll lead with the exploit’s academic breakdown
https://www.vusec.net/projects/drammer/
On that page you will find a thorough explanation of the exploit. You will also find something called the drammer test app.
For those of you new here, I’m a software developer by trade. I will not send you dangerous shit. The worst thing that will happen in this process is that your browser will crash for a moment, and you may have to restart your phone.
Nothing permenant
The TL;DR version goes like this:
There are a series of exploits on Android devices that have to do with: the way Android parses MPEG-4 video (aka stagefright bug), and another that involves memory spraying (rowhammer).
Surprisingly, accomplishing the attack does NOT require you to play the video.
You can have it loaded on pause and it would be just as effective
You may have noted in previous conversations, or in your research, that UFSC videos contain an abundance of encoding errors.
Specifically, what we’re looking for are frames which change properties set earlier in the video. Things like setting the video size to 50x50, then later setting those values both to 0. The same can be done with the video length, and many other metadata type properties
A video containing these sort of strange changes are typically ignored by most players. Unfortunately Android’s implementation causes them to potentionally allow a buffer underrun attack.
By setting a previously large value to something small or 0 later in the video, then causing the parsing player to crash, a small window is opened where the underlying player can have the data that it loads swapped out from under it.
Or simply removed
When the player re-launches it has cached memory pointers which load whatever is in memory, giving the player access to memory it wasn’t intended to read.
The final step of the exploit we won’t be performing here, but that involves using something like javascript to read out these exploited bits and test for elevated access or secure data
This attack has already been proven and well documented.
Here is more in depth history
https://googleprojectzero.blogspot.com/2016/09/return-to-libstagefright-exploiting.html
So, the videos are not an attempt to hack your phones
If you read through the history, you’ll realize that this attack keeps creeping up over and over again
Much of this is because there are so many different types of MPEG-4 frames which can allow for this sort of exploit
In the penetration testing world these hacks are quite valuable.
Now, I don’t mean on the black market.
< so \(\) still? >
More like competition
With prize money
There’s also the possibility that someone is running this as simply an early warning system
They’re trying to flesh out these attacks as early as possible in a benign way
Here’s what you’ll need to do to see the results yourself.
https://www.vusec.net/projects/drammer/#app
Nah, this isn’t dangerous.
Set the sliding bar to somewhere between 20-30%.
Your phone’s optimal setting may vary.
The sliding bar basically changes how hard the software will work your phone’s memory at attempting to produce the bug
If you install the app, you’ll understand. There’s not a lot to it.
Please spend the time to read the article and do a little vetting of the group offering the download if you’re worried about it. I didn’t write this thing, but a very reputable academic security testing group did.
Anyway, run it for a while. The indication that it has been successful is if you see a line that starts with the word “FLIP”
So, run drammer, and pay attention to the number of flips you get.
Don’t need to count exactly, just be aware.
Next, stop drammer.
After stopping drammer, load up on of the videos in chrome
Youtube RETIO, CRIMP, and the CLEAN series have all be especially effective.
Remember, you don’t even have to play the video. However, I’ve found that playing the video does increase the effect.
You will need to get the player to load the video though. For some phones this means you’ll at least need to start and pause it.
Now, switch back to drammer and start it again
You will notice a significant increase in the number of FLIP lines
on my HTC m8, they came almost non-stop
On certain videos he has accomplished causing the crash.
You can witness this by switching immediately back over to the video after starting drammer.
The browser will crash, sometimes reloading.
Some other videos will suddenly become unplayable after being perfectly playable before.
Generally completely shutting down the browser or restarting the phone will fix that
Some of these exploits have been fixed, so what you are seeing is libstagefright and the Android kernel stepping in to prevent you from reading memory you’re not supposed to
Rather, that process from doing so
So, MPEG-4 is not just .mp4
Hell, the exploit isn’t necessarily just mpeg.
It’s a problem with the video parsing library in android.
the idea of metadata frames exists in just about every codec out there
MPEG-4 just seems to have the most ways for it to be exploited
Codecs like vp* use a very similar system
< to be fair there is still a lot of unexplained pieces >
Yup
For instance, the account got banned once
Came back
But it’s obvious it’s not employees
My guess goes back to an academic institution being allowed to continue with it’s research
And see, the series, I’m very curious about the series
Are they variations on the attack, or are they meant to crash and load the next video in the series?
The greater the change in the values, the more memory which could be exploited
But also, the greater the change in the values, the more likely you’d cause the player to crash, possibly too early.
Anyone know where I can grab the old videos in their native format?
Note: UFSC’s videos are typically offered on youtube in 2 formats
mp4 and 3gp
https://en.wikipedia.org/wiki/Stagefright_(bug)
https://www.exploit-db.com/docs/39527.pdf
There’s the article that I dissected this whole thing with
It’s explains why android as well
But tl;dr is that Android is the only one that wrote a poorly implemented parser
That and video is just so damn ubiquitous on phones
< I see, I suppose this may be what UFSC is doing but I don’t think that is the only thing. The whole presentation seems multi-layered. >
And this is where we all get to feel like dirty whores
Who the hell would continue to run these things if they knew that merely loading them was part one to an exploit?
part 2 can come from anywhere
I’m betting that there are some google analytics experiments out there running in the background checking for signs of the exploited videos
< stagefright targets android. and i’m not sure how audio plays into that
trying to read through it now… >
The primary target is video frames, not audio
Though if libstagefright parses it, and it has metadata which can be changed in a later frame, it’s a candidate
< By the way, do you still need a volunteer with an Android? >
YEah
I’m going to do it and video as well., I’ve already done it multiple times. But independent verification and all
I think the composites served 2 purposes
First, understand that fuzzing is, well, fuzzy.
You need to introduce logical but randomized patterns so you can look for discrepancies
Sending through a warped picture of yourself? Serves both the security purpose & the promotional purpose.
The more people trying to solve the puzzle, the better
Hmm
https://source.android.com/security/bulletin/2016-12-01.html
Looks like we’ll see plenty of new stuff for a while
Another large batch found & fixed
Er
Fixed and found
In that order
<Alright so what do I do?>
https://www.vusec.net/projects/drammer/#app
Go install that app
The links says “available”. It’s called Drammer