[Cryptography] defaults, black boxes, APIs, and other engineering thoughts

[Kevin W. Wall]

On Mon, Jan 6, 2014 at 1:15 AM, ianG <iang at iang.org> wrote:
>
> On 6/01/14 01:59 AM, Jerry Leichter wrote:
>>
>> On Jan 5, 2014, at 3:25 PM, Jonathan Thornburg wrote:
>>>
>>> But this raises some genuine questions:
>>> * Is there a secure web browser?  My trust level in any of the biggies
>>>   (Microsoft, Apple, Google, Mozilla) is low...
>>
>> I'm with you.  For what it's worth, I think Chrome is probably, across
>> time, the most secure, because Google puts a huge amount of effort
>> involving a really experienced team into making it so.  I place some
>> amount of trust in Safari, but that's a matter of statistics, not
>> anything special about the code:  People aren't attacking it as much.
>> (Apple seems to have been getting ever more serious, but how far they've
>> come is hard to judge.)
>>
>> But a modern browser is the ultimate example of immense complexity in
>> commonly used software today....
>>
>> I do find fascinating the reaction to the never-ending series of
>> security issues in Flash and Java.
>
>
>
> It's very annoying.  All of those bugs labelled as Java are really applets
> in browsers.  So every time a scare story comes along, we have to read
> all about it only to discover it is really nothing to do with the language.
>

Sorry, but I can't allow Oracle / Sun to get off the hook that easily. :)

Yes, almost all of the Java vulnerabilities have manifested themselves
as exploits executed as Java applets. But that does not make the problem
some plug-in that launches the Java applet or even the applet security
manager that provides the applet sandbox.  These vulnerabilities have almost
all been exploits in regular Java classes (the JavaFX classes seem to be
particularly exploitable) that have allowed an attacker to escape the
Java sandbox.

Specifically, these vulnerabilities could lead to breaches in server-side
Java but for two things:
    1) Server-side Java rarely (I've only seen it twice [0] and once was an app
       that I was the tech lead for [1]) uses a Java SecurityManager and an
       appropriately restrictive security policy, so there is in essence
       no sandbox from which to escape on the server side.
    2) It's traditionally much harder to get Java applications to execute
       malicious Java byte code on the server side than it is to get Java
       clients to execute Java byte code in their browsers. The former
       requires either remotely executing Java code (e.g., via RMI or some
       similar fashion) or getting your code uploaded to the application
       server and executed there (e.g., from malware in a tainted 3rd party
       Java library), whereas the latter only requires that you get any of
       billions of naive users who have Java-enabled browsers to visit some
       site hosting a malicious applet.

And while there have been some Java specific exploitable vulnerabilities
that explicitly affected server-side Java code (e.g., the DoS in
String.hashCode() that leades to hash table collisions comes to mind;
see CVE-2012-2739 for details), they generally are easier to mitigate
because not only can you usually fix by patching Java, but you can also
often apply virtual patches with software such as Web Application Firewalls
or IDS, or sometimes even just rewrite a portion of code.

But make no doubt about it, these are exploits in the Java classes and/or
the JVM and not just some browser applet plug-in.

-kevin
---------
[0] I'm referring to the Java security policies and the appropriate use of
    Java SecurityManagers to enforce it in the JavaEE application server
    and not the Dalvik permissions that is common in Android programming.
[1] Pissed of my developers to no end, too. :)
-- 
Blog: http://off-the-wall-security.blogspot.com/
NSA: All your crypto bit are belong to us.