Sergey Glazunov is not "Pinkie Pie": they each separately attacked Chrome in 2012 using unrelated exploits; this was part of the same event, so their names are used together often, which may be why you are confused.
Sounds like a use After free vulnerability. IE Is well known for these [1].
If you know C or C++ it's very straight forward. A function creates an object or structure on the heap. The malicious code writer or the function can then pass a pointer to that object/struct to another function which then frees it. The problem is the other function doesn't realize that the pointer has been freed and is still able to write into that memory address even though it's sitting on the free list.
The interesting arises when another object gets allocated to the same location. Since you still have a dangling pointer, you can write into that object. If it's C++ you can overwrite the virtual function table pointer to one you control, or if its C hope that there is a function pointer hanging around.
Correction, most applications coded in languages with manual memory management (C, C++, Pascal dialects), without use of static code analysers to verify correctness.
It is amazing how many companies forbid the use of STL, templates and all related mechanisms that enable automatic memory management in C++ in their style guides, while still coding in C style.
enable OPTIONAL automatic memory management. The problem is it does not enforce it.
I've never heard of a place that forbade STL, templates or such since 2005 or so. But it's not like STL or templates help; It's RAII that does. And there's no way to enforce RAII, so a stl::list<char * > is not any better at protecting you from use after free than char * x[] is.
Basically you just have a pointer:
p1 -> [Object 1]
And someone holds access to p1 even after you free p1, so now:
p1 -> [Junk]
The security flaw is when that memory is reclaimed for some use, so now:
p1 -> [Object 2]
And the malicious holder has free access to the properties of the new object.
There were separate successful attacks demonstrated against iphones at the same event. I say this just incase anyone thinks of selling any Google shares... ;)
Terminology pedantry: the term "Zero day" is normally used to refer to exploits being used in the wild. This was a demo at pwn2own, and by rule was disclosed to the vendor. It is unpatched, but not a "zero day" unless someone else knows how to do it.
It's also not the title of the article, which right now is simply "Chrome on a Nexus 4 and Galaxy S4 falls".
Do we know this is really the case? I am skeptical about whether this guy had already discovered the vulnerability the day before the event. Fuzzing a browser can take a few hours running all the valgrind suites and analyze each failure can take a while. The article makes it seem he did it very quickly. What tools did he use? I am new to fuzzing browser.
"A zero-day (or zero-hour or day zero) attack or threat is an attack that exploits a previously unknown vulnerability in a computer application, meaning that the attack occurs on "day zero" of awareness of the vulnerability." [1]
If the party responsible for fixing a vulnerability knows of it before it is exploited, then they had more than "zero days" to fix it.
Is there a better write up of the exploit? How did they escape the renderer sandbox?
(I ask, because I theorize that it's really easy to escape the Chrome renderer sandbox because the renderer is attached to Binder and thus has access to the whole system_server interface and everything else registered through the magic android.os.ServiceManager).
Pwn2Own has a whole ceremony where they very "securely" take the exploit directly to the vendor so that the vendor can address the issue.
ZDI is built around Intrusion Detection/Prevention, so they are effectively buying the newest and greatest exploits, ostensibly for the purpose of writing new IDS/IPS detection rules.
The consequence is that you probably won't get a better write up of the exploit for some time. To be eligible for the award, you agree to withhold publicly disclosing the details of your exploit for some time.
The secrecy around handling the exploits may be a contributing factor to Dragos' weirdness on the #badbios thing. The Pwn2Own contest would be the reason he's got a legitimate possibility of being targeted by something as strange as he's been describing.
They say Google is working to address it, so presumably this is still an issue in the current shipping version of Chrome (eg: on Nexus 5)?
So then the interesting thing is whether it is also an issue in the new WebView which is Chromium based. If it is, then it is actually burned into the ROMs and requires an OTA to address. By far my biggest problem with the Android update situation is that security issues are baked into ROMs on locked phones and consumers have literally no physical way to protect themselves against vulnerabilities that are discovered. Google's own phone, the Nexus One, has not received an OTA since October 2011, which must surely mean it has some serious security flaws discovered by now. I think Google is very lucky that a persistent, widespread security epidemic has not occurred based on one of these "baked in" flaws.
32 comments
[ 1.9 ms ] story [ 70.3 ms ] threadE: corrected mistaken identities
If you know C or C++ it's very straight forward. A function creates an object or structure on the heap. The malicious code writer or the function can then pass a pointer to that object/struct to another function which then frees it. The problem is the other function doesn't realize that the pointer has been freed and is still able to write into that memory address even though it's sitting on the free list.
The interesting arises when another object gets allocated to the same location. Since you still have a dangling pointer, you can write into that object. If it's C++ you can overwrite the virtual function table pointer to one you control, or if its C hope that there is a function pointer hanging around.
[1] http://www.cvedetails.com/vulnerability-list/vendor_id-26/pr...
Of course it appears Rust will be much better in this regard.
If you mean security and STL. Do Google developers use std::array::at() instead of std::array::operator[]() as an example?
Do they use smart pointers and STL containers instead of pure C++ pointers, arrays, strings everywhere?
Do they use references instead of pointers in function arguments for out parameters?
Do they use RAII for all types of resources?
Do they produce builds with -Wall -Werror?
Does the static analyzer run as part of the build?
Being able to use STL is just the first step for secure C++.
enable OPTIONAL automatic memory management. The problem is it does not enforce it.
I've never heard of a place that forbade STL, templates or such since 2005 or so. But it's not like STL or templates help; It's RAII that does. And there's no way to enforce RAII, so a stl::list<char * > is not any better at protecting you from use after free than char * x[] is.
Automatic memory management in C++ does not effectively protect you from use-after-free.
http://www.theregister.co.uk/Print/2013/11/14/pwn2own_cracke...
> The attack didn’t defeat Apple's sandboxing technology otherwise they would have earned a lot more.
Also Google makes more money from iOS than Android.
It's also not the title of the article, which right now is simply "Chrome on a Nexus 4 and Galaxy S4 falls".
So if you found a vulnerability that's not publicly known / new, that means you got a zero day. It also implies that it's not patched.
If the party responsible for fixing a vulnerability knows of it before it is exploited, then they had more than "zero days" to fix it.
[1] http://en.wikipedia.org/wiki/Zero-day_attack
(I ask, because I theorize that it's really easy to escape the Chrome renderer sandbox because the renderer is attached to Binder and thus has access to the whole system_server interface and everything else registered through the magic android.os.ServiceManager).
ZDI is built around Intrusion Detection/Prevention, so they are effectively buying the newest and greatest exploits, ostensibly for the purpose of writing new IDS/IPS detection rules.
The consequence is that you probably won't get a better write up of the exploit for some time. To be eligible for the award, you agree to withhold publicly disclosing the details of your exploit for some time.
The secrecy around handling the exploits may be a contributing factor to Dragos' weirdness on the #badbios thing. The Pwn2Own contest would be the reason he's got a legitimate possibility of being targeted by something as strange as he's been describing.
If not, then it is obviously still bad because Chrome has fairly extensive permissions but it is not "take over your whole device" bad.
So then the interesting thing is whether it is also an issue in the new WebView which is Chromium based. If it is, then it is actually burned into the ROMs and requires an OTA to address. By far my biggest problem with the Android update situation is that security issues are baked into ROMs on locked phones and consumers have literally no physical way to protect themselves against vulnerabilities that are discovered. Google's own phone, the Nexus One, has not received an OTA since October 2011, which must surely mean it has some serious security flaws discovered by now. I think Google is very lucky that a persistent, widespread security epidemic has not occurred based on one of these "baked in" flaws.