Hi, On Tue, 18 May 2021 at 10:13, Ron Pressler <ron.press...@oracle.com> wrote: > > 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 hope you aren't being rude on purpose by continuing to 1) top post and 2) not ignore various parts of my emails. To be clear, what I have written is partially answered by some of your other emails which you talk about using a java agent and or hooks which I mentioned in my previous email (& to say it again ... hooks seem like they would be similar to a security manager). > 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. I am not trying to be rude but I would like to ask what is more expensive - 1) auditing 1,000,000 lines of code - with active development on going 2) re-architecting an application so that the main process ?cannot? make new connections after a certain point (preventing new FDs from being opened) & making external connections from another process which has operating/configuration/other restrictions on it to prevent it from talking with sensitive network locations 3) examining all known locations using a security manager in a non-enforcing mode or as you noted - the Java Flight recorder & fixing all known currently existing locations 4) ^ 3 but you use a security manager or something that lets you make decisions about connections/$things such that you can block in addition to monitor things Let's say you want to do 1 - you likely will not be able to keep up with active development regardless of cost and humans make mistakes. Let's say you want to do 2 - we are talking about re-architecting a sizable application - it might not be possible to shift to your suggested split model and it also imposes a relatively high barrier to entry/additional complexity (e.g. additional monitoring) as well. Let's say you want to do 3 - this works but it doesn't do anything to help with changes to code changes, libraries, and java itself. Let's say you want to do 4 - this works but it won't be 100% secure, what if the class you permit somehow ends up in all call stacks/at the "allowed" location, we get the benefits of 3 but with some additional protection. Real world software security experience -^ will likely push security engineers towards 4 depending upon performance impacts etc. If we end up with hooks in places which allow us to make decisions but don't try to protect against tearing down/removing a "security manager" & the hooks are easier to use than the existing security manager, that sounds workable to me (not desirable but workable). (I could go on and rant about about how oracle made changes that mean that if you try to use a custom security manager in java 11 without referencing internal java classes you have a performance penalty - or how there are security related applet & other hangovers that hinder the use of the security manager in java applications). > > > 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. > -- David Black / Security Engineer.
