Zero-day vulnerability in Chrome on Nexus 4 and Samsung Galaxy S4
h30499.www3.hp.com
h30499.www3.hp.com
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.
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.
E: corrected mistaken identities
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.
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.
(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.