[External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

Tue May 18 00:13:42 UTC 2021

We can call any mechanism that might impose restrictions a mitigation, but that
doesn’t mean that any mechanism is worth its cost. I believe that the evidence
gathered over the past few decades shows that attempting to assign different 
permissions to code of different origin in the same process is not a particularly
effective way of increasing security compared to the alternatives, which is why
the only other mainstream platform to employ such a mechanism other than Java has
dropped it some years ago, and no other such platform has adopted it since.

I don’t think rearchitecting is required. What’s required is a reexamination of 
security-per-hour-effort gained by trying to assign different permissions to 
different code sources.

— Ron

> On 18 May 2021, at 01:02, David Black <dblack at atlassian.com> wrote:
> 
> Hi Ron,
> 
> On Mon, 17 May 2021 at 21:38, Ron Pressler <ron.pressler at oracle.com> wrote:
>> 
>> I would say that trying to mitigate attacks on vulnerabilities in trusted code based on specific code paths is
>> not recommended. You’re trying to preemptively defend agains something complex — a security bug — with
>> another complex mechanism. Even if you do happen to defend against a particular attack attempt due to a bug
>> that happens to be in the “less trusted” code rather than in the more trusted code, the cost/benefit to this
>> approach is not very attractive, in my opinion.
> 
> That is your opinion and I will note that your reply didn't reference
> my references that noted that there are & have been bugs in libraries
> and java itself which make mitigating SSRF attacks difficult.
> With regards to mitigating SSRF "something complex", I'd argue that it
> isn't complex in itself but mitigating SSRF can be, with another
> complex mechanism - I will note that implementing the mechanism is
> rather simple so long as you are not using the built in java security
> manager.
> 
>> I think it is easier and simpler (and so more secure) to not differentiate codepaths in the same process, grant
>> whatever minimal privileges are required to the entire process with more watertight mechanisms than the SM,
>> and then actively monitor it — say, with streaming JFR events, which will be made richer, and already do
>> expose the stack trace — for suspicious activity. If a bug is found — fix it.
> 
> I am not familiar with the Java Flight recorder but the documentation
> for it seems to suggest that it is only for diagnostic purposes.
> 
>> 
>> If your application clearly has more trusted/less exposed components and less trusted/less exposed ones,
>> and you feel that they must be separated for security reasons, consider running them in different processes.
>> Process isolation is a more secure, better studied, and better supported security mechanism than the Security Manager.
> 
> My reading of your proposed solution is that it requires
> re-architecting applications to ensure that any potential security
> issues occur inside of an isolated and monitored component/process.
> However, we do not get to pick where security issues can develop. It
> is true we can mitigate the risk of security issues by using isolated
> processes but I think you may have missed my main point which is
> effectively "something that lets us examine $X, e.g. a network
> connection, before the action is performed let's us at least partially
> mitigate security vulnerabilities and while it might be ideal to have
> software that contains 0 security vulnerabilities in it that often
> isn't realistic." From my prior email - "So having a "belt and
> braces", prox(y|ies) and a security manager, approach is valuable."
> Perhaps a different but I would argue more complex solution would be
> to use a java agent to rewrite java classes so as to be able to
> implement class based checks at run time or to have java provide event
> hooks where decisions can be made (but ... that sounds rather similar
> to the current situation with the security manager).
> 
> I would like to apologise for the system we use at my place of work
> messing with the email subject. But I would appreciate it if you
> didn't top post to reply to my email as you have left out some
> concerns such as that Java 8 seemingly is still affected by
> https://bugs.openjdk.java.net/browse/JDK-8161016.
> 
> 
>> — Ron
>> 
>>> On 17 May 2021, at 03:11, David Black <dblack at atlassian.com> wrote:
>>> 
>>> Hi Ron
>>> 
>>> On Thu, 13 May 2021 at 20:22, Ron Pressler <ron.pressler at oracle.com> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On 13 May 2021, at 03:11, David Black <dblack at atlassian.com> wrote:
>>>>> 
>>>>> 
>>>>> This seems somewhat more useful than 1 & 2 but imho it would be better to be able to perform checks/grant access on a call stack basis.
>>>> 
>>>> This is an important point we’re trying to get across. The very reason the Security Manager was made this
>>>> way is because it does *seem* better; certainly it is much more flexible. However, twenty five years of
>>>> experience have shown us that *in practice* this is not the case, certainly not when you look at the
>>>> ecosystem as a whole. It is hard to get right, which results in people not using the mechanism (which
>>>> significantly reduces its utility and the value in maintaining it), or worse, use it and think it gets
>>>> the job done, but actually use it incorrectly, providing the illusion of security without actual security.
>>> 
>>> Agreed, but if you don't have this level of introspection/detail how
>>> do you propose to, at least partially, mitigating bug classes such as
>>> SSRF?
>>> 
>>>>> Atlassian currently makes use of a security manager to prevent access to cloud metadata services that do not have an amazon sdk related class on the call stack. This helps to mitigate the impact of SSRF in applications running in a cloud environment (https://urldefense.com/v3/__https://github.com/asecurityteam/ssrf-protection-example-manas-security-manager__;!!GqivPVa7Brio!IyJmrzRjucwPoKg96_YX9o_oR9CWp1zWRELtDpWvfKRtM8jcx7ZJI9Phg_PHR4-37A$ ).
>>>> 
>>>> 
>>>> We’re talking about a situation where *all* the classes running in your application are trusted,
>>>> i.e. assumed to not be malicious, and that an accidental vulnerability might exist in any one of them.
>>>> Can you explain why you believe this mechanism, that treats different classes differently is the best
>>>> way to improve security?
>>> 
>>> Because it allows for restrictions to be placed upon "trusted"[0]
>>> classes so as to offer some mitigation against classes of bugs such as
>>> SSRF. You can also use a security manager to monitor for potential
>>> policy implementation issues & make adjustments. Specifically for
>>> SSRF, if you want to mitigate the issue you need to ensure that
>>> network connections being made respect proxy settings but also allow
>>> support for certain code paths bypassing proxy settings to access
>>> potentially sensitive network locations (e.g. cloud metadata
>>> resources) this can result in mistakes in configuration occurring and
>>> or finding libraries/classes that ignore proxy configuration. You may
>>> be thinking "oh but surely no library/class would have proxy
>>> problems?" well that answer is "yes they can and do". For example,
>>> https://bugs.openjdk.java.net/browse/JDK-8161016[1] was fixed in java
>>> 9 but has not yet been fixed in java 8[2]. In a similar fashion,
>>> OkHttp before version 3.5.0 could also fallback back to a direct
>>> connection[3]. So having a "belt and braces", prox(y|ies) and a
>>> security manager, approach is valuable.
>>> 
>>> 
>>> [0] "Trusted" classes are not immune to security issues
>>> [1] https://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/3dc9d5deab5d
>>> [2]https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/0056610eefad/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#l1180
>>> &  https://urldefense.com/v3/__https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/master/jdk/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java*L1180__;Iw!!GqivPVa7Brio!IyJmrzRjucwPoKg96_YX9o_oR9CWp1zWRELtDpWvfKRtM8jcx7ZJI9Phg_PCT2HmkQ$
>>> [3] https://urldefense.com/v3/__https://square.github.io/okhttp/changelog_3x/*version-350__;Iw!!GqivPVa7Brio!IyJmrzRjucwPoKg96_YX9o_oR9CWp1zWRELtDpWvfKRtM8jcx7ZJI9Phg_OyQxtDiw$
>> 
> 
> 
> --
> David Black / Security Engineer.