Are there any real life cases, where using final keyword in Java increases system security?

Question

I've came across that question on StackOverflow: https://stackoverflow.com/questions/18755713/how-does-final-play-a-role-in-security

The claim is made, that according to Wikipedia:

A final class cannot be subclassed. This is done for reasons of security and efficiency.

and the OP asked, how the security is achieved using final keyword.

What surprised me, most answers were claiming, that the final keyword would greatly increase security, because attacker won't be able to override your classes and calling your protected methods etc. They are mostly based on Oracle's article Secure Coding Guidelines

For example, making a class final prevents a malicious subclass from adding
finalizers, cloning, and overriding random methods

However, with my understanding, if the attacker gains the possibility to execute arbitrary Java code on the targeted system (and if you are considered of him overriding your classes, he is expected to be) than he can already do everything your code is able to do, therefore it's completely irrelevant from security point of view, if your methods are final or not, or even if fields are private and not exposed or not (he can serialize your class and read every field etc.).

But on the other side, is it possible to find such real-life scenario, when attacker wouldn't achieve his goals by executing arbitrary code, and he would succeed only (or such attack would be considerably easier) by 'maliciously' overriding your classes, such as described in Oracle's article? For example, if the application server is shared by multiple Java applications?

Answer 1

This feature of Java makes sense, security-wise, in the Applet model: a context where, indeed, the attacker gets to execute his code on your machine, and yet that potentially hostile code is still contained. This was meant initially for Web browsers, not for servers.

All the containment of a Java applet is performed on a per-call basis, in a very fine-grained way. There is a complex framework of permissions which encode what the applet can do and what it cannot do. In particular, a basic applet cannot perform arbitrary serialization of code, or reflection to inspect and/or modify instances out of its own package, or call native code. The final keyword also makes sense in that context: since String is final, then the standard classes can assume that when they receive as argument a String, it is the genuine object, not an EvilString which extends String but acts in unexpected ways when its Substring() method is invoked.

It turned out that maintaining security under these conditions was a hard problem -- harder than what Sun initially believed. There are hundreds, if not thousands, of standard library classes which must be made "permission aware", and, for each of them, the code must take care to enforce the appropriate permissions. It was inevitable that the Sun people, however competent they may be, forget a few corner cases, leading to exploitable vulnerabilities. During the last few years, there has been a steady stream of "Java applet vulnerabilities" which allow an evil Web site to take control of any Web browser which visits it, as long as that browser uses a Java plugin which has not been fixed.

None of this impacts Java as a programming language, as it is often used on servers, or in big desktop applications; in these situations, indeed, there is no hostile code running locally.

The final keyword can still serve as compiler-enforced documentation (thus not against attackers, but as a reminder for careless programmers); it also helps optimization (when the JVM sees a call to a final method, or to any method on a final class, then it knows that it can optimize the call into a direct jump into the method code, since there is no way that method could be overridden).

Answer 2

There is also design security:

By flagging classes and methods as final; the development team prunes the amount of future mutation in sensitive code*. This guides the development team (which may be distributed) and any future code maintainers or enhancement projects as to where sensitive behaviour is occurring and should occur - concentrating the design risk into a smaller area.

If I recollect correctly, BouncyCastle classes that not intended for public API consumption are locked down this manner to discourage unexpected polymorphic behaviour and home-brew design of crypto-primatives within BouncyCastle. While final doesn't stop anyone from modifying the source code and recompiling as they see fit, for any project with good design, final serves a decent warning flag for new developers that mutating the method may have unexpected side-effects upon internal framework integrity. And hence upon security.

_{* To the great inconvenience of classically-trained OOP developers I might add.}