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 <dbl...@atlassian.com> wrote: > > Hi Ron, > > On Mon, 17 May 2021 at 21:38, Ron Pressler <ron.press...@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 <dbl...@atlassian.com> wrote: >>> >>> Hi Ron >>> >>> On Thu, 13 May 2021 at 20:22, Ron Pressler <ron.press...@oracle.com> wrote: >>>> >>>> >>>> >>>>> On 13 May 2021, at 03:11, David Black <dbl...@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.
