A security flaw in Groovy was detected in versions 1.7 to 2.4.3:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3253
The MethodClosure class in runtime/MethodClosure.java in Apache Groovy 1.7.0 through 2.4.3 allows remote attackers to execute arbitrary code or cause a denial of service via a crafted serialized object.
Does this affect "typical" Grails projects that retrieve data from user input (web forms), the DB, web services, etc. and assume this is all text, not serialized objects? In other words, is there any of this happening implicitly that we should be aware of?
Otherwise, what should we look for to ensure this bug isn't affecting us?
Grame has an issue for exactly this, but noone has been able to show any way to exploit it in a Grails app yet: https://github.com/grails/grails-core/issues/9113
In short: "the plan is 2.5.1 and 3.0.4 will have Groovy 2.4.4"
Related
Apologies if I've missed this elsewhere, but could anyone tell me please if Cytoscape uses Log4j?
I have Cytoscape v3.9.0 on macOS Big Sur v11.6, with openjdk v11.0.7 installed. Just wondering if it's safe to open Cytoscape to use at the moment or if it needs a security update.
Cytoscape uses log4j, but the core only uses log4j 1.x. The sbml app does use log4j2, however. Be aware that the avenue for this particular exploit is that an attacker must format a message to send to the logger that requests the logger to load code from LDAP, DNS, or some other repository. The typical pattern from this exploit is through HTTP requests to a web server. In the context of Cytoscape, this would mean fashioning a CyREST query that includes the log message in such a way as to get Cytoscape to pass that to log4j. This would be extremely difficult and quite specific to Cytoscape. So, as a direct answer, yes, there are components of Cytoscape that use log4j2 (the sbml app), but running Cytoscape on your desktop is very likely to be safe. To make sure it's safe, you can block traffic to the Cytoscape REST port from outside of your laptop.
-- scooter
We are using TestNG framework with Log4j for preparing end to end tests. Should we take some action?
Just because the vulnerability is only in your test dependencies, does not mean you could ignore it.
However you should be under full control of your input and this should cover all possible log messages as well. So you could assume that nobody from outside can easily exploit this vulnerability. So if are not planning to add injection Strings to your test data, you should be OK.
I recommend to update anyway, as you never know if it could be used in some way of exploit chain (another exploit in the future might rewrite your input, and that ends up in the logging). But it has a lower priority than fixing any public available server.
Version 2.15.0 of log2j contains the fix.
In one of my servers i am getting the above exception. can anyone suggest how to resolve this.
in the WLS9-async component due to unsafe deserialization of XML
encoded Java objects. An unauthenticated, remote attacker can exploit
this, via a crafted Java object, to execute arbitrary Java code in
the contex
How to apply the patch on this
Thanks in advance.
It is a known security issue relative to java deserialization mecanism.
You can read details about in this article from Oracle. The best thing to do is to apply the latest PSU and CPU published by Oracle.
You can also rename the bea_wls9_async_response.war application from your WebLogic Server installation to prevent the issue.
I've been looking at this:
http://calumleslie.blogspot.com/2008/06/simple-jvm-sandboxing.html
regarding sandboxing the JVM. However, that was written three (four?) years ago now, and is for Java. I haven't managed to find anything more recent or specific.
I know I could probably do the same thing for Scala, but I was wondering if Scala had any inbuilt sandboxing capabilities? The use case is to do scripting and configuration in Scala (like how Lift does it) while still maintaining security (i.e. preventing config.scala opening network sockets or reading from the hard disk). Does anyone have any experience doing this?
You use the same mechanism as in Java: install a SecurityManager . The default ClassLoader will give loaded code a "read" FilePermission for its own classpath and an "exitVM" RuntimePermission; other actions require permissions.
What are good framework choices for web security in a Scala web application. We would like to try out Scala web development, but couldn't yet find good Scala web app security frameworks.
From the Java side I know at least Spring Security and Apache Shiro.
Do you have experience with Scala web app security frameworks or with Spring Security / Apache Shiro in a Scala context?
Lift has security baked in as described here by David Pollak, the author of Lift.
I used Spring Security in small Scala web application. I created it as I started to learn Scala and I tried to use complete Java stack: Spring MVC + Spring + Spring Security + Hibernate + BlazeDS (I also used Flex in this project for the frontend). Now I can tell that it was really nice and positive experience. Generally the question is how good scala integrates with Spring and Hibernate. I had to use #BeanProperty or #BeanInfo and java collections in entities.
But I have not faced any real issues from the spring security side. It was working as expected. I can remember only one minor issue with Spring AOP: service classes were publishing their methods through BlazeDS to the flex application. I also secured them with Spring Security's object ACLs (with <security:intercept-methods /> and <security:protect />). All this stuff, of course, is possible because of AOP magic. So I noticed this wired Spring AOP's behavior - if your class implements some interfaces, then it will use JDK's proxies to implement them and delegate all calls to target, but if class does not implementing any interfaces, then it will use cglib to extend your class and delegate each method call. The problem is that my public service classes does not implement any interfaces, but AOP was not working properly. The reason is ScalaObject interface that is implemented by all scala classes. So I created new traits for all public services in order to solve this problem (I have not found any way to configure Spring AOP - seems that this behavior is hardcoded).
So as you can see it's not a problem to use Spring Security with Scala. I believe that it should be even easier to use Apache Shiro because it claims to be completely container or environment independent (I heard that it's possible to use Spring Security outside Spring, but I also heard that it's pretty painful). Generally in Scala you can archive everything you can in Java. The question is how pretty/idiomatic/pure/side-effect-free resulting code would be.
By the way, there is a new project that integrates Lift with Apache Shiro: lift-shiro. Here you can also find small blog post about it.
Hope this helps.