Pondering the X client vulnerabilities

Posted May 30, 2013 21:17 UTC (Thu) by dvdeug (guest, #10998)
In reply to: Pondering the X client vulnerabilities by hummassa
Parent article: Pondering the X client vulnerabilities

Android runs Java. The first Power Mac G4 in 1999 had problems with export because it was classified as a super computer; every smart phone on the planet is faster then those systems running at 400 MHz.

I've never understood why an increase in speed is worth having to tell your customers that their credit card numbers are in the hands of hackers, or having your website hosting child porn. Taking the website down for a week while your IT department (getting massive overtime) is trying to recover what it can from your compromised systems is bloody expensive. It's a classic surcharge on day-to-day operations to prevent possible disaster.

Android doesn't really run Java

Posted May 31, 2013 11:39 UTC (Fri) by alex (subscriber, #1355) [Link] (2 responses)

Well obviously I'm being a little trollish ;-)

However an awful lot of the performance critical areas of the code are written in lower level code and exported to Java via JNI (not to mention key components like the browser which is pretty much all C++). There is a debate to be had as to how much can you ameliorate some of the worst areas of C with C++ but once you start up the road to interpreted/JITed higher level languages you will pay a performance penalty. It's fine when they are making fairly simple decisions that result in work for lower down the stack but when you are moving lots of stuff around you really don't to be in even the most efficient JIT code.

Android doesn't really run Java

Posted May 31, 2013 14:01 UTC (Fri) by hummassa (subscriber, #307) [Link]

You are right. And, of course, the performance penalty theoretically, at least, would increase still more when we are talking about performance as battery/energy economy. BTW -- THAT is what I'd like to see measured in this context.

In the same topic, people demonize C mainly because of three things: null pointers, buffer overflows and integer overflows. You can write beautiful and as-efficient-as C++ code without any of those. But PHP/Java-like vulns would persist (data scrubbing/encoding/quoting errors mainly) are a little bit more difficult.

Android doesn't really run Java

Posted May 31, 2013 18:12 UTC (Fri) by dvdeug (guest, #10998) [Link]

Java doesn't need to be interpreted; I presume it makes it easier to limit Android code and it certainly makes MIPS and ARM Androids both possible. In any case, it's not really relevant to the question of use-after-frees and buffer overruns.

The low-level stuff can't be ignored, but I'm a lot more comfortable having the base libraries be written in C, since they're written by someone who presumably knows what they're doing, and having the programs running on that code written in Java.

As for the browser, you're talking about a tool that deals with a sustained barrage of untrusted material, and it's not hard to feed a web browser compromised material. Looking at Chrome's recent vulnerabilities, in May we had 8 use-after-frees and one out-of-bounds read (and four other), and in March we had 6 use-after-frees and 1 out-of-bounds read (and 15 other, including some "memory corruptions"). (Counts of CVEs listed in Debian's changelog.)

As hummassa says, there's other standard security errors that Python and Java as well as C and C++ get up to. But 45% of Chrome's recent CVEs wouldn't have existed in Java or similar systems. Pick the low-hanging fruit first.