JEP411: Missing use-case: Monitoring / restricting libraries

Sat Apr 17 14:18:50 UTC 2021

> Ron wrote:

> I think it’s worth adding that treating libraries as untrusted code is
unworkable over the long run

Well, define 'untrusted'.

If you mean: "untrusted" as in it may well contain code explicitly designed
to compromise our internal security, put there for malicious purposes by
someone who is looking to infiltrate your software, systems, data, or
clients – then, yes, I agree. Don't run libraries that may be compromised,
even if you have registered a SecurityManager.

But if you mean "untrusted" as in: I did not personally check the full
source code of the entire library, and it may be doing things _not_ with
malicious intent, but nevertheless something that opens up additional
attack surface that I wasn't expecting and need to update my internal
security policies accordingly (or outright stop the library from doing it):
Then I disagree. Why would it be 'unworkable' to treat libraries this way?
I'd say rather the opposite: There will always be misunderstandings between
the user of a library and the author of one of what and how it works.

There's a bit of community interaction with such things: If, say, the ZXING
library (google's QR code generator stuff) ends advertising itself as
'makes QR code images', but is implemented as a light wrapper around
https://charts.google.com?qr, then I expect the community to make a bit of
a stink on social media about this, but the community cannot necessarily be
trusted upon to take that first step quickly (of figuring out a library is
doing things that cause one to raise one's eyebrow). There is ample
historic context for this, such as the amount of time it took to find
heartbleed. Monitoring a library for network access would let you figure
out, quickly, that ZXING is not doing what you thought it did.

NB: Just to be clear, zxing _does not_ make any network calls. The library
generates PNGs with QR codes as you would expect. But it makes for a
plausible hypothetical, I think.

 --Reinier Zwitserloot

On Fri, 16 Apr 2021 at 23:28, Ron Pressler <ron.pressler at oracle.com> wrote:

> I think it’s worth adding that treating libraries as untrusted code is
> unworkable over the long run, as their set of permissions possibly
> needs to be reexamined with every update. On the other hand, JFR can serve
> as a mechanism for tracing application behaviour, which,
> when streamed, can serve to raise alerts.
>
> — Ron
>
> > On 16 Apr 2021, at 22:02, Sean Mullan <sean.mullan at oracle.com> wrote:
> >
> > Hello Reinier,
> >
> > Thanks for the feedback on the JEP. If I read your message correctly,
> you seem to be primarily concerned with logging and/or restricting access
> to file and network operations.
> >
> > In my personal view, some of the examples you present that do somewhat
> sketchy things are probably not a good idea to put in production. There
> should be additional audits and reviews of code, and code that is not
> widely used should be eyed with extra suspicion. It may not be quite the
> same as running untrusted code, but it seems quite near it.
> >
> > It doesn't seem realistic to keep the SecurityManager API and possibly a
> lot more of related APIs supported for this limited use case. Also if you
> remove the access control and policy infrastructure from the JDK, then you
> are responsible for the policy, determining what code is making the check,
> whether it is trusted or not, etc. That is difficult to implement safely.
> My guess is that it would become too hard to use, or too hard to implement
> safely, and would become rarely used (like the Security Manager).
> >
> > That said, I think it is worth exploring (in this JEP) or another JEP
> ways that we might think about that could help provide DiD protection for
> network and file access. This is an opportunity to look at the problem with
> a fresh set of eyes, w/o the existing complicated infrastructure and APIs
> that encompass the Security Manager.
> >
> > Thanks,
> > Sean
> >
> > On 4/15/21 9:29 PM, Reinier Zwitserloot wrote:
> >> One useful thing that you can do with SecurityManager, which would be
> impossible if it is removed, and which isn't described in the 'specific
> narrow use cases' section:
> >> Monitoring and restriction of, specifically, third party libraries.
> >> 99 out of a 100 modern java projects have a rather long list of
> dependencies, and most of those dependencies have a limited and specific
> intent. "This library reads EXIM data from a JPG". "This library marshals
> JSON into java POJOs". "This library makes QR code PNGs".
> >> As an app programmer I want to monitor, and optionally restrict what
> these libraries can do. I can have an app that does (and is intended to)
> make network connections all the time, but as part of doing the job I wrote
> it for, it may be generating some QR PNGs. If the _QR generator library_ is
> making network calls? I want to know, and I probably want to stop it from
> happening.
> >> SecurityManager can do that. I don't know of a good way to take care of
> this without it, and it is not (currently) described in JEP411. I can't use
> OS-level monitoring, because the OS has no awareness of modules / packages
> / classnames, so I can't tell it to accept without log or warning any
> network access done by the parts of my application that are supposed to do
> this, but that I _do_ want it to log, warn, or halt any attempt by that QR
> generator library to hit the network.
> >> The original intent of SecurityManager was clearly to allow you to run
> untrusted code on a VM (the 'applet' use case), but this is somewhat
> different: It's not so much about attempting to secure presumably malicious
> code in a library or applet, but instead about attempting to secure against
> operations that ordinary java code may do, but which you simply aren't
> expecting from some specific library.
> >> Some real-world and/or highly plausible examples:
> >> * An XML parser library may make network calls or open files on disk
> due to e.g. XXE shenanigans: See
> https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing
> <
> https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing>
> – this isn't just plausible, we have plenty of proof that this has caused
> significant security breaches multiple times in XML's history. A
> SecurityManager that monitors (or outright denies) specifically the network
> and disk access from an XML parser library would have meant XXE attacks
> could never have happened.
> >> * Some twitter library may be invoking a relative-pathed `cmd.exe` in
> order to retrieve some system info from windows that cannot be obtained
> with any of the core java libraries. Perhaps to check if the twitter
> desktop client is installed (the authors of the library may well be unaware
> of the new ProcessInfo API). No doubt a scan of all java-tagged projects on
> github finds rather a lot of libraries that Runtime.exec("cmd.exe") for
> some unexpected, non-malicious purpose. Nevertheless, ProcessBuilder does
> apply $PATH processing and a system operator may not be willing to accept
> invokes to a relative path that can be trivially hijacked if some directory
> in the PATH is compromised, especially if the programming team that uses
> the library wasn't expecting it to do so. A SecurityManager can monitor
> this and even stop it from happening.
> >> * Any library could have the bright idea to 'phone home' and make a
> network call simply to give the library author some idea of how widespread
> their library is used. This could have an entirely innocuous purpose: The
> library author thought it'd be a cool idea to have a live map of the planet
> on their website, with a little animated blip every time their library is
> used to, say, parse some JSON. SecurityManager is the simplest way to spot
> this and stop it.
> >> I don't think SecurityManager is necessarily fantastic at stopping
> _intentionally malicious behaviour_ by a library written by untrustworthy
> charlatans (even though that was its original intent). But, it does a great
> job at stopping a misunderstanding between a library author and the user of
> said library, such as the rather plausible scenarios I just described.
> >> Modern security practices put a lot of focus on monitoring;
> SecurityManager can do that too: A SecurityManager is not obligated to deal
> with e.g. a notification that some code is attempting to open a file by
> throwing SecurityException - they can also simply log or notify somebody
> that it is happening and allow it. They could check if the caller is in a
> subset of 'blessed' code that has been checked by the dev team and has
> sign-off that it is allowed to do it. They could simply do a quick echo in
> dev-mode only, just so developers are aware whilst running tests that some
> library is doing things that have potential security implications and open
> potential surface area for a breach.
> >> I'm not sure if the file-based configuration of the security manager
> (policy files) needs to be kept around to enable this use case, but the
> basic infrastructure, and almost all of the various `check` methods in
> java.lang.SecurityManager have plausible scenarios where an application may
> want to monitor or deny what it triggers on when a library is doing it that
> you don't want it to or did not expect to.
> >>  --Reinier Zwitserloot
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210417/1e4099be/attachment.htm>