Zero-day vulnerability in Chrome on Nexus 4 and Samsung Galaxy S4(h30499.www3.hp.com)
h30499.www3.hp.com
Zero-day vulnerability in Chrome on Nexus 4 and Samsung Galaxy S4
http://h30499.www3.hp.com/t5/HP-Security-Research-Blog/Chrome-on-a-Nexus-4-and-Samsung-Galaxy-S4-falls/ba-p/6268679#.UoRsdJWIrIU
9 comments
Pretty much all web browser engines are full of use-after-free issues, not just IE.
Correction, most applications coded in languages with manual memory management (C, C++, Pascal dialects), without use of static code analysers to verify correctness.
C++ has automatic memory management, but it also supports manual as an option and for some reason people keep using it.
Of course it appears Rust will be much better in this regard.
Of course it appears Rust will be much better in this regard.
> C++ has automatic memory management, but it also supports manual as an option and for some reason people keep using it.
Automatic memory management in C++ does not effectively protect you from use-after-free.
Automatic memory management in C++ does not effectively protect you from use-after-free.
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 automatic memory management
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.
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.
Static analysis, although it only fixes your own code, not third party libraries.
Google uses the STL everywhere in Chrome.
Sure, but Google is special. We are talking about normal companies in regard what features one is allowed to use.
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++.
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++.
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".
It's also not the title of the article, which right now is simply "Chrome on a Nexus 4 and Galaxy S4 falls".
Isn't it reasonable to refer to it as a zero day since it is unknowable whether this exploit is being used in the wild?
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.
Only in the same way that referring to a person found dead at the side of the road from a presumptive car collision was "murdered".
I don't know where you get that definition but zero day means and used as a vulnerability that's not publicly known / previously unknown.
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.
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.
"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.
[1] http://en.wikipedia.org/wiki/Zero-day_attack
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
Pinkie Pie is an impressive dude. They've pwned devices/chrome at the last several pwn2own and pwnium conferences
E: corrected mistaken identities
E: corrected mistaken identities
Google should really just hire Glazunov and Pinkie Pie at this point.
I'm in two Pinkie Pie fanclubs now
There were separate successful attacks demonstrated against iphones at the same event. I say this just incase anyone thinks of selling any Google shares... ;)
http://www.theregister.co.uk/Print/2013/11/14/pwn2own_cracke...
http://www.theregister.co.uk/Print/2013/11/14/pwn2own_cracke...
You should sell Google shares because it's overvalued, not because of an exploit in something that has no impact on their earnings.
From the article you linked to:
> 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.
> 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.
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.
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.
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.
By the title I thought there was a problem with the nexus4, this is really about chrome on android right?
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).
(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.
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.
Does this also escape the Android Application Sandbox? It makes not mention of this, only escaping the protection offered by Chrome.
If not, then it is obviously still bad because Chrome has fairly extensive permissions but it is not "take over your whole device" bad.
If not, then it is obviously still bad because Chrome has fairly extensive permissions but it is not "take over your whole device" bad.
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...