Can you qualify this? Native code is sandboxed just as managed code is (of course it is). Ancient buggy kernel? Most handsets have very contemporary kernels.
But surely you will provide some compelling citations.
Well, as an example, if you are using 4.0.0-3 you probably have a kernel susceptible to mempodipper (although that's "buggy", not "ancient", and it is not possible to exploit that bug from an app: you have to do it over adb).
Regardless, it is true: most of the exploits that have been used (Rage Against the Cage, GingerBreak, zergRush) have been in user-land components (adbd, vold, libsysutils), not in the kernel. On Android 1.x, though: kernel bugs FTW.
Basically every device for which some kind of rooting tool exists is vulnerable.
It is not too hard to leverage the same exploit used by rooting tools to circumvent the UID based sandbox and to access the data of other applications, including the phone book, security tokens / passwords stored in SharedPreferences etc.
However, with a buggy kernel, you don't necessarily need native code to perform the exploit: you just need access to whatever part of the kernel that has the bug (which is often something innocuous). If there is a bug in the filesystem driver where attempting to open file descriptor to paths larger than 1024 bytes long will cause a buffer overflow, I can exploit that just as easily from Java as I could from C.
Basically every device for which some kind of rooting tool exists is vulnerable.
Most if not all rooting tools work via the debug interface. One rather clever app -- if you have USB debugging turned on -- would essentially do a localhost debug connection to exploit this, but generally these are ADB exploits. This has nothing to do with native versus managed, and native provides no additional opportunity than managed.
I replied to the original post because there is a pretty prolific belief that native=crazy dangerous. Yet of course the iPhone has entirely native apps, and we've had native sandboxing and rights restrictions since...what...the creation of UNIX?
From these two it is fairly easy to tell how current the kernel is for any rev of android out there. A quick cross comparison shows that it was more or less current at time of release but isn't updated afterwards. This means there are quite a few three or four year old kernels out there since most devices are in the 2.x range. I am not sure what qualifies as ancient, but I never really had a problem with the 2.6 kernel line.
But surely you will provide some compelling citations.