I have the luck to migrate a large monolithic system from Java7 and Scala 2.10 to Java8 and Scala 2.11. So far so good. The application is using SpringSecurity.
After updating the spring libraries to the newest one we faced a null pointer exception thrown in Wss4jSecurityInterceptor in the validateMessage method here:
if (validationActionsVector.contains(WSConstants.NO_SECURITY)) {
return;
}
The exception occurs during running a test. However, before I post here tons of code (test/implementation..) probably somebody has an idea where to approach the problem - or which part should be investigated in more detail.
EDIT:
One interesting fact that by compiling with Java7 and Scala 2.10 (with the same library versions) the null pointer exception do not occur.
It's an open SWS bug
If you don't use the validation (no validationActions set), then do:
interceptor.setValidateResponse(false);
interceptor.setValidateRequest(false);
Edit:
As of 30.10.2017 the bug is closed. Should work fine with versions 2.4.1, 3.0.0.RELEASE and above.
the main reason is the inconsistency between the versions of ws and xmlsec.
if you are only client, then you can opt out the validation.
interceptor.setValidationActions("NoSecurity");
interceptor.setValidateResponse(false);
Related
We are using spring-web in one of our projects which uses Java 8 and Veracode has reported a v high flaw in spring-web framework.
I know updated 6.x.x has been released and it's vulnerability free but in order to update to spirng 6 Java needs to be updated considering our project is very old and on path of EOL by this Sept upgrading it to Java 17 is somewhat not a feasible option.
Are we expecting any release for 5.x.x version with this vulnerability fixed?
The problem highlighted by this CVE is that deserialization of Java serialized objects from an untrusted source is dangerous.
However, flagging all versions of Spring-Web 5.x.x as being vulnerable is misleading. Sure, the Spring-Web codebase has code that allows that to happen. But so do all versions of Java ... until they deprecate and remove Java object serialization entirely. (That is described as a "long term goal", but I doubt that will happen any time soon.)
The correct way to deal with this is not to "upgrade" ... but to audit your code carefully to look for places where you are using Java object deserialization. Then you check each place to see if you are (potentially) getting the data from an untrusted source, or a source that could be compromised thereby rendering it risky.
If you are not using Java object serialization you are fine.
If you are not getting the serialized data from an untrusted (or risky) source you are (probably) fine ... modulo the accuracy of your assumptions and your analysis.
Otherwise you need to change your application to stop using Java object serialization / deserialization in a risky way. Do it another way; e.g. use JSON and a JSON binding technology.
Note that upgrading to Spring-Web 6 or higher doesn't actually solve the problem anyway. Sure they removed the "vulnerable" classes, but the "ability" to use Java serialization unsafely exists in Java. Spring-Web cannot prevent it.
For more background, I recommend that you read issue 24434 on the Spring issue tracker.
In particular, read this comment from one of the developers which explains their stance on the issue.
When we switched from Jackson version 2.8.9 to 2.9.8 we ran into some trouble with serializing data in CBOR format. As it turns out the custom Jackson module we've been using is causing trouble in this newer version. These issues start at version 2.9.0.
I've made a repository that reproduces the issue and found that when I disabled our custom TemporalAmountModule issues went away. I did not write the TemporalAmountModule myself but it looks like the Custom Serializer and Deserializer are the cullprit. These do not introduce any complex code but I don't really understand why they don't work properly anymore because I am not to familiar with Serializers and Deserializers.
I've made a repository that reproduces the issue I am having. When you disable the module you can see it is working properly. When you change the jackson version to 2.8.x (latest in that range is 2.8.11) you can see it works properly too.
https://github.com/Archcry/reproduce-jackson-error
The expected result should be the same as it was in version 2.8.9 (or 2.8.11 for that matter). Jackson should not break any functionality in a minor version release but it may deprecate certain methods (which they did). The deprecated methods are not the ones causing the issues though because I tried updating them but ended up with the same result. The actual result at the moment is an error saying Can not write a field name, expecting a value.
Issue was solved on GitHub, see https://github.com/FasterXML/jackson-databind/issues/2320
Edit:
Issue is being worked on and shouldn't have happened in the first place.
Edit 2:
Issue is no longer worked on, due to the lack of context it's hard to reproduce.
Unfortunately while I can see the exception from sample project, I am not able to construct simpler version with combinations. I wonder if that might be related to use of immutables, annotations.
So I think I'll leave this as-is for now.
I am Getting this error when trying to run spring batch to load the list of executions.
java.lang.IllegalAccessError: tried to access method
org.springframework.batch.core.repository.dao.JdbcJobExecutionDao.getJobParameters(Ljava/lang/Long;)Lorg/springframework/batch/core/JobParameters;
from class
org.springframework.batch.admin.service.JdbcSearchableJobExecutionDao
After doing some analysis, I found that JdbcJobExecutionDao is part of Spring-batch and has the implementation of getJobParameters() as protected method while, JdbcSearchableJobExecutionDao is part of spring-batch-admin which has extended the JdbcJobExecutionDao.
So as per the Oracle documentation, it says that IllegalAccessError is -
Thrown if an application attempts to access or modify a field or to
call a method that it does not have access to.
Normally, this error is caught by the compiler; this error can only
occur at run time if the definition of a class has incompatibly
changed.
I don't understand, I don't have control over these jars/classes. Am I doing something wrong while using them? or is there a problem with the versions I am using for both jars.
spring-batch - version 2.2.0.RELEASE
spring-batch-admin - version 1.3.0.BUILD-SNAPSHOT(Tried with 1.3.0.RELEASE also)
Refered to sites -
java.lang.IllegalAccessError: tried to access method
https://github.com/spring-projects/spring-batch/blob/master/spring-batch-core/src/main/java/org/springframework/batch/core/repository/dao/JdbcJobExecutionDao.java
https://github.com/spring-projects/spring-batch-admin/blob/master/spring-batch-admin-manager/src/main/java/org/springframework/batch/admin/service/JdbcSearchableJobExecutionDao.java
So, I fixed this by using proper versions. It was a version mismatch problem between spring-batch & spring-batch-admin. I referred to this spring docs site and tried the recommended versions and it worked!
http://docs.spring.io/spring-batch-admin/spring-batch-admin-manager/dependencies.html
So, now I am using
2.2.7.RELEASE(Spring-Batch)
with
1.3.1.RELEASE(Spring-Batch-Admin)
and I am not getting the java.lang.IllegalAccessError anymore. Need to check if any other functionalities have been disturbed because this is a very old project.
Hope this helps someone facing similar problem.
I'm facing this exception when receiving an Xml and trying to parse it. The code responsible for that is well tested when running as an standalone application. However I'm now integrating it in Tomcat.
The stack trace is:
java.lang.IllegalStateException: org.xml.sax.SAXNotRecognizedException: http://javax.xml.XMLConstants/feature/secure-processing
at com.sun.xml.internal.bind.v2.util.XmlFactory.createParserFactory(XmlFactory.java:121)
at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.getXMLReader(UnmarshallerImpl.java:139)
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:157)
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:204)
Digging around I found this, so maybe the solution is to change the options Tomcat sets.
So the question is:
Which is the problem's root?
Best way to solve it?
Is a good approach to change Tomcat options? how is this done?
Update
This happens when running it with Java 8, reverting to Java 7 works ok.
I had faced similar issue, this issue occurs when there is big difference in versions of xerces jar and xercesImpl jar. To solve this, I used xerces-2.9.0 and xercesImpl-2.9.1 and the issue gone.
I know this is an old question. But just updating it if it is of any help to others..
We had a similar issue recently while upgradig to java 8 with JBOSS 3.2.6. The cause of the issue was an old xercesImpl.jar. We upgraded to xercesImol-2.9.1.jar and the issue was resolved.
Well, this worked for me:
Added below to my tomcat configuration arguments:
-Djavax.xml.parsers.SAXParserFactory="com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl"
Question 1: (Solved)
I'm facing an issue with class loader in Weblogic.
I've a Web application which executes the following code.
AccessController.doPrivileged()
This is handled by another classloader.
When the above code gets executed, Class Not Found exception occurred for a project specific class(for example Sample.class) which exist in web project.
How can I solve this issue?
Solution:
Weblogic 10.3.1.0 is using com.bea.core.apache.commons.net_1.0.0.0_1-4-1.jar... I want to use commons-net-2.0.jar from my code
Question 2:
After getting solution as I mentioned earlier, now its throwing ClassCastException as follows.
java.lang.ClassCastException: org.apache.xerces.jaxp.SAXParserFactoryImpl cannot be cast to javax.xml.parsers.SAXParserFactory
at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:128)
To answer your second question:
the most probable thing is that you already have an implementation of the SAX somewhere (which is located upper in the classpath).
For example JSF requires one implementation of SAX parser (WL admin console webapp uses JSF, so chances are SAX is already imported).
There should be only one implementation, otherwise you could experience strange behavior and strange exceptions. Delete the second implementation from the lib folder of the application.