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

[ianG]

On 7/01/14 05:11 AM, Kevin W. Wall wrote:

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


God, no, that would be sin.

> 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.


I personally dismiss the sandbox and SecurityManager stuff as likely 
false sense of security.  OK, nice when working, it probably won't hurt, 
but, how do you know it is working, and how much effort is required to 
dance around it?  These are unanswerables.

(I'm not even sure what the use case is, was it just applets?)


> 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.


Right.  On server-side, the server is the sandbox.  Anything else is 
another sin brought to you by the marketing borg, and as equally valueless.


>      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.


So, these are extraordinarily different applications.  People seem to 
think that because Java is potentially used in both, the results should 
be about the same.  But the applications are so different, there is no 
comparison.

Substitute Java in the above for any other language, including a 
different one for each, and you've still got exactly the same problem 
statement.  Afaics.


> 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.


Looks like wheelspinning for non-core managers with too little to do.

> 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.

Right.  But if someone can get at my java server-side code, then I've 
got bigger problems.  Problems that exist regardless of the language...



> -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.

Sure.  Like browsers, that environment deliberately mixes apps from 
different places.  Something is needed.

> [1] Pissed of my developers to no end, too. :)

No doubt.  What benefit did you earn for this acrimony?




iang