-
Notifications
You must be signed in to change notification settings - Fork 951
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Grails® framework RCE via Data Binding - CVE-2022-35912 #12626
Comments
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? c8bb44e |
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 |
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.
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 |
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 ) |
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. |
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? |
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. |
Thank you @JasonTypesCodes |
What about just adding the patched file to the |
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 |
@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. |
@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. |
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 |
@JasonTypesCodes, also, when will the details about the exploit be released? We want to make sure to keep ahead of that date. |
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? |
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. |
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
The text was updated successfully, but these errors were encountered: