grails-core
grails-core copied to clipboard
grails
Grails® framework RCE via Data Binding - CVE-2022-35912
Issue description
I am opening this issue to facilitate the discussion about this. More information available at https://grails.org/blog/2022-07-18-rce-vulnerability.html
Could you provide an example of the vulnerability (I don't see any tests or info in the CVE)? I need to backport this to 3.3.9 as there are breaking changes preventing me from moving to anything higher and would like to test it works. I assume these are the only changes required? https://github.com/grails/grails-core/commit/c8bb44e13b905d32291aeaace31b762ee8a76e5a
Any idea if this affects grails 2 versions?
Had the same question before. Here's all that I could find about it: https://twitter.com/JasonTypesCodes/status/1548971229897433088
@erichelgeson
Could you provide an example of the vulnerability (I don't see any tests or info in the CVE)?
We haven't yet published the technical mechanics of this attack yet as we are trying to provide folks some time to upgrade before the attack becomes more broadly known. We will be publishing the details soon. We are identifying a timeline for that to become public.
I need to backport this to 3.3.9 as there are breaking changes preventing me from moving to anything higher
If you aren't able to upgrade your application, for a 3.3.9 app you could get the patched databinding library by adding the updated dependency explicitly to your build.gradle:
compile "org.grails:grails-databinding:3.3.15"
Hi @JasonTypesCodes. Will the above mentioned patched 3.3.15 version of databinding library work in Grails 2.5.6 environment?
As a systems administrator (not developer), what's the best method to detect vulnerable versions? A filesystem scan for grails-databinding-5.2.x.jar? Along with 5.2 less than 5.2.1, 5.1 less than 5.1.9, 4.1 less than 4.1.1, and 3.3 less than 3.3.15? Is that the correct naming convention?
We have identified the change that allows this attack to succeed, and it was added in version 3.3.10. Grails framework versions below 3.3.10 are not vulnerable to this specific attack. Due to the nature of the attack, it is possible that a variation could be discovered that does impact Grails framework versions 3.3.9 and lower. We strongly suggest that all Grails applications be upgraded to a patched and supported version of the framework. More info is on the updated blog post: https://grails.org/blog/2022-07-18-rce-vulnerability.html
(cc @erichelgeson )
@nair-rajeev
Hi @JasonTypesCodes. Will the above mentioned patched 3.3.15 version of databinding library work in Grails 2.5.6 environment?
That is quite a jump. I would not expect that to work. Even if it builds and runs, there are likely other breaking changes in the way that databinding is handled that may impact you.
@Jwalker107
As a systems administrator (not developer), what's the best method to detect vulnerable versions? A filesystem scan for grails-databinding-5.2.x.jar? Along with 5.2 less than 5.2.1, 5.1 less than 5.1.9, 4.1 less than 4.1.1, and 3.3 less than 3.3.15? Is that the correct naming convention?
The full known set of impacted versions are: >= 3.3.10 & < 3.3.15 ; >= 4.0.0 & < 4.1.1 ; >= 5.0.0 & < 5.1.9 ; 5.2.0
I can't say if this is the "best method" for your environment, but looking for a grails-databinding.jar in those version ranges should work. Please note that in most cases these applications will be packaged as a war which includes the jar inside of it so it may not be visible on the filesystem without extracting the contents of the war file.
Potentially similar to the spring4shell issue, is an up to date version of Tomcat a mitigation for this?
If so, will specific versions of Tomcat be listed as a prerequisite for this vector?
Or, any mitigating steps that can be applied in the interim while we wait for vendor upgrades?
Potentially similar to the spring4shell issue, is an up to date version of Tomcat a mitigation for this?
If so, will specific versions of Tomcat be listed as a prerequisite for this vector?
Note that, just like spring4shell, the key aspect is the access to the classloader. Upgrading tomcat addressed one of the attack vectors in spring4shell, but once you are able to modify anything in the classloader, there are multiple attack vectors that can be explored.
@nair-rajeev
Hi @JasonTypesCodes. Will the above mentioned patched 3.3.15 version of databinding library work in Grails 2.5.6 environment?
That is quite a jump. I would not expect that to work. Even if it builds and runs, there are likely other breaking changes in the way that databinding is handled that may impact you.
Thank you @JasonTypesCodes
What about just adding the patched file to the src folder? This should override the vulnerable file from the library. Is this a acceptable workaround to patch older projects to gain some more time to upgrade?
What about just adding the patched file to the
srcfolder? This should override the vulnerable file from the library. Is this a acceptable workaround to patch older projects to gain some more time to upgrade?
If you are in a position where you are able to add an updated file to a src folder, I suspect you could also upgrade the Grails version of your project. If there are reasons that you are unable to do that in the short term, you could try upgrading only the grails-databinding dependency as described above.
@JasonTypesCodes , we've got a vendor that is saying their patches for this issue are still a week out. I appreciate that you're not publishing PoCs or specifics, but can you indicate whether we're looking at a log4shell type of deal, or a lower-risk situation? Trying to figure if we need to take production systems offline until patches drop.
can you indicate whether we're looking at a log4shell type of deal, or a lower-risk situation?
@chrismyers81 This vulnerability is an RCE which is short for remote code execution. That means that someone that knows how to exercise the attack can cause a vulnerable system to execute arbitrary code from over a network.
@JasonTypesCodes, true. But some RCEs only cause issues if, say, feature X is being used. Or, they cause issues if certain complex conditions are met. Others like log4shell cause issues simply because the library is loaded.
In lieu of specifics, can you provide a cvss? NVD doesn't have an analysis yet.
@JasonTypesCodes, true. But some RCEs only cause issues if, say, feature X is being used. Or, they cause issues if certain complex conditions are met. Others like log4shell cause issues simply because the library is loaded.
In lieu of specifics, can you provide a cvss? NVD doesn't have an analysis yet.
This vulnerability is in the Grails data binding logic which can be used to bind a map of data (like the params from an incoming web request) to an object. This could be done explicitly in your application code, or implicitly by the framework if you are using features like command objects. Many Grails applications make use of the data binding logic.
https://docs.grails.org/latest/guide/theWebLayer.html#dataBinding
If you inspect your application looking for use of data binding, please remember that plugins can introduce controllers and may be using data binding as well.
@JasonTypesCodes I would assume Weblogic is vulnerable as well running Java 8 and Databinding jars before 3.3.15. Just curious as all the mentions are mostly of Tomcat.
@JasonTypesCodes, also, when will the details about the exploit be released? We want to make sure to keep ahead of that date.
In lieu of specifics, can you provide a cvss? NVD doesn't have an analysis yet.
It would appear that NVD has CVSS at this time: https://nvd.nist.gov/vuln/detail/CVE-2022-35912
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Now that we're about two months down the road, when will details about the vulnerability be posted?
Now that we're about two months down the road, when will details about the vulnerability be posted?
We will post an update when details are released. At this time, we want to continue to give organizations the opportunity to patch and release their Grails applications.