Brief comment on ECC attack below, the code download can be prevented by
granting DownloadPermission only to code signers and not user
principals. In this case the imposter service would only be able to
cause a signed code source to class-load. Since Java serialization is
disabled, the attacker would probably be unable to penetrate the jvm,
but still could potentially steal data.
On 28/04/2022 3:25 pm, Peter Firmstone wrote:
Hi Martin,
Your arguments are the reasons why we use the principle of least
privilege. It creates a headache for attackers, similar to the
developer who's enabled SM for the first time and must manually add
every required permission for their software to function (who thought
that was a good idea lol?). The attacker requires an intimate
knowledge of the permissions their attack vectors or gadgets require,
including those a thread of execution has already been granted as well
as the features that those permissions will grant the attacker access
to. If the thread of execution doesn't have all required
permissions, it will cause the jvm to exit with a SecurityException.
How does the attacker obtain all the required information? With great
difficulty.
As soon as the software does something a generated polp policy file
hasn't captured, a security exception is almost inevitably thrown,
even if it wasn't designed to protect an intended target, it almost
inevitably gets in the way. You will find that it's almost impossible
to do anything unintended. Although once you can impersonate a user
or service, say with the recent ECC exploit, you can at least do what
that user or service is allowed to do, but it still won't allow the
attacker to achieve their intended end goal unless the user or has all
the required permissions. In our case if the attacker can impersonate
a service, then they can load code, that's a problem, as our software
assumes ECDSA provides strong confidentiality. We recognise that once
you get to the stage of loading code into the jvm, it's pretty much
game over. A polp policy file won't defend against the recent ECC
exploit.
https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-jeri/src/main/java/net/jini/jeri/ssl/ConfidentialityStrength.java
What polp can protect against however, is an exploit in a feature that
you don't use, it protected against the recent Log4J vulnerability.
An example of a polp policy file:
https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecuresharedvm.policy
One of the improvements we can make (when re-implementing access
controls), is to reduce the size of the jdk's trusted computing base,
instead of having many trusted protection domains with all permission
(characterised with a null protection domain), we can give each module
a separate protection domain identity, and limit each only to the
permissions required for our software to function as intended. This
means that jvm modules we don't use will have no permissions at all.
To get around the large trusted jdk code base, we provided two methods
which append a ProtectionDomain, with only the user's required
permissions, it also prevents injection of a user Subject's
permission's into less privileged service domains. It's use hasn't
really caught on though, no doubt due to complexity.
https://github.com/pfirmstone/JGDMS/blob/c1edf5892306f24f8f97f459f499dec54984b08f/JGDMS/jgdms-platform/src/main/java/net/jini/security/Security.java#L590
This is really a hack because the jdk's trusted computing base is too
large, also user permissions should be granted only to protection
domains that have the necessary user principals and code signers, to
avoid injecting additional permissions into less privileged service
protection domains.
All data parsing the jvm performs, should also be moved into separate
modules, so that data parsing access controls and privileges could
have been managed (this is one of the missing checks you mention), and
yes it did provide a false sense of security for many years that Java
serialization was secure when it wasn't. I had many difficulties
explaining to developers in 2010 that Java serialization wasn't
secure, they didn't believe me and it cause problems.
Had the Java 2SE security infrastructure never been introduced,
perhaps something else would have evolved, or at the very least, our
software wouldn't depend on it. Java's access controls have certainly
suffered from a lack of investment.
Unfortunately our software is dependent on it and designed around it
at a fundamental level, even if SM is null (which incidentally I've
haven't yet tested, I think we have code that checks that SM is
enabled), our software is still using AccessControlContext's to
establish TLS connections and authenticate users. Personally I would
like to see parts of AccessController and AccessControlContext
retained for retrieving the Subject for establishing secure
connections in a way that's compatible across all Java versions.
After removing access controls, it effectively means AllPermission is
granted to every authenticated user (and in our case service). Any
access controls that we create at a higher level, can be circumvented
by the lack of lower level access controls. So the only access control
is authentication.
We have no desire or want to instrument the jvm, we have been advised
that this is the new way to implement access controls by OpenJDK, it's
simply that we want to continue to support future versions of Java and
cannot do so without access controls. Our software has been designed
with and depends on access controls.
Java has had access controls for 24 years, we couldn't foresee that it
would be removed in a breaking manner in such a short time frame.
Remember how long Thread.stop and similar bad api's remained in
deprecated form?
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8204243
This isn't something we wanted or planned to do, it's a task that has
been created for us and we have few resources to address it.
Regards,
Peter.
On 28/04/2022 3:37 am, Martin Balao wrote:
David,
I understand the reasons behind seeing authorization checks at the
runtime layer as something that just adds, without any harm in the
worst case (all of this putting the maintenance cost and other
arguments aside.)
My concern is more about the general security principles underpinning
the idea. We will probably agree that half-barriers are not barriers,
and might cause a false sense of security. If we have authorization
checks at the runtime level, they must be comprehensive, coherent and
well-maintained. Their availability suggests that mixing high-level
checks with runtime-level ones can be part of a good security design
in modern application development. For the reasons that we've been
discussing, I'm not convinced of that. And even when subtle, I prefer
the runtime not to make the suggestion. If you still want it, you can
go ahead with instrumentation; but it's clear that for the runtime
developers that is a workaround and not a desirable security design.
What I mean by splitting responsibility is that application
developers can use a mix of high and low level checks, at different
layers, with more complexity. As Sean said, letting the unauthorized
user to move towards the edge of the action is more risky. We can
lose sight of workarounds and holes with the additional attack
surface and complexity that comes at a lower layer. What I want to
stress is the value of clarity, simplicity and division of
responsibilities as a general security principle.
Martin.-
