Summary: | glassfish iiop protocal unserializable remote code execute | ||
---|---|---|---|
Product: | z_Archived | Reporter: | rugal orich1 <627963028> |
Component: | Orb | Assignee: | Security vulnerabilitied reported against Eclipse projects <vulnerability.reports-inbox> |
Status: | NEW --- | QA Contact: | |
Severity: | critical | ||
Priority: | P3 | CC: | russ, russell.gold, sawamura.hiroki, steve.millidge, wayne.beaton |
Version: | unspecified | Keywords: | security |
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | All | ||
Whiteboard: |
Description
rugal orich1
2020-01-27 21:56:01 EST
I've added the Eclipse Glassfish project leads and have marked this bug "committers-only" (i.e., only visible to committers). Project leads, there is help for handling vulnerabilities in handbook [1]. [1] https://www.eclipse.org/projects/handbook/#vulnerability I assume this bug needs a vulnerable jar on the server classpath e.g. Commons Collections which as AFAIK is not the default? We will take a look. (In reply to Steve Millidge from comment #2) > I assume this bug needs a vulnerable jar on the server classpath e.g. > Commons Collections which as AFAIK is not the default? > We will take a look. Yes, Commons Collections is not the default. When glassfish is installed by default, it will only have a limited impact, because there are a certain number of jars that are loaded into the classloader, but users may add vulnerable jars themselves when using glassfish. Thanks for clarifying the scope of the issue on a vanilla install of the server. We are investigating and working on a fix. I think this should be moved to the Orb project which is upstream from GlassFish for fixing. Not yet, at least. There are a few possible ways to fix it: One involves the application classloader. If each application has its own, that can restrict the classes which could be deserialized, even if those classes are present in the server. The problematic classes tend not to be used by applications directly. Another possibility is a blacklist of the known problem classes (that is, those which could start independent processing). Of course, that's a game of whack-a-mole, with hackers finding more and more classes that could be on the server. That blacklist would need to be updated for the server, but the ORB would need to support the JEP290 blacklist mechanism to recognize it. So I'd recommend adding JEP290 support to the ORB, and also having Glassfish warn, or warn and halt, if started on a JDK that doesn't implement JEP290 |