I think it would be useful to configure the JVM to prevent loading of
untrusted (unsigned) code. This might be useful in preventing
injection attacks, where the attacker is attempting to have the JVM load
remote untrusted code.
--
Regards,
Peter
On 4/04/2025 3:45 am, Scott Lewis wrote:
On 4/3/2025 8:20 AM, Sean Mullan wrote:
On 3/13/25 3:44 PM, Scott Lewis wrote:
But from the point of view of the OSGi framework implementation (for
example), has there been any discussion to alternatives to leaving
SSLContext.setDefault open to all code at all times? e.g.
deprecation of public static setDefault, or changing the semantics
of setDefault so that it could only be called successfully once (on
startup). I understand that may not be feasible due to api
conventions, but was wondering if this or other approaches
(enhancing JCP) have been considered/discussed.
I am not familiar with OSGi so I don't understand the scenario you
are describing. Can you provide more details?
Although I'm referring to OSGi because that's my implementation
context of interest, the thoughts apply to any application where new
code/components are added/updated incrementally...e.g. many modern web
servers, many client-side apps.
The OSGI framework has been using the java mechanisms (built on sm and
permissions) to restrict these install/update dynamics as appropriate
for the application...e.g. only installing signed and
user-approved/trusted code.
SSLContext.setDefault seems to me to be a notably risky case for any
dynamic system, and particularly for java-based servers. I say risky
not only because of potential for explicit attacks or sslcontext
provider bug exploits or configuration confusion, but also for the
potential for errors during installation and/or upgrade, or even just
a vague level of trust in the component being installed.
Unlike many of the jvm APIs, SSLContext.setDefault cannot be
overridden/replaced by the surrounding application and/or a runtime
framework like OSGi. Thus the ideas for deprecating it, replacing it
through some new non-static api, or changing the semantics to allow it
to be used only (e.g. on startup), or disabled at runtime.
I've proposed using OSGi service registry to support framework
customization and securing of access to creating SSLContext instances
in the OSGi framework [1]. This does not, however, address the issue
of the vulnerability resulting from uncontrollable access to
SSLContext.setDefault...so that's why I asking about it here.
Thanks.
[1] https://github.com/osgi/osgi/issues/810
--Sean
