Closed jgstew closed 2 years ago
I was at first envisioning "unfixing" all of the mitigated files on the entire device, but it might make sense to have an option to only unfix a specific one, but I guess you could achieve that same effect by limiting the scope of the "unfix" more narrowly than the "fix" to try to only roll back the applications that have broken.
I would love to know if anyone has actually had any applications break by doing the mitigation. Right now I think there is just fear of possible breakage, but I don't know of any actual breakage by the mitigation. In the short term, the main goal is discovery.
As far as I know, spring boot application was the only case. (log4j2-scan < 1.5.0)
Looks like this was released in this version here: https://github.com/logpresso/CVE-2021-44228-Scanner/releases/tag/v2.5.0
@jgstew Yes. I will close this issue. Thank you for feature suggestion!
--restore
is worth its weight in gold. I have had to use it so far with Geonetwork and the GDI-DE Registry.
I know this seems a little odd, but if it is not hard to do, it would be really interesting if there was an
--force-unfix
option that would detect any where a JAR has been mitigated by this utility and roll it back by restoring the backed up file.The reason for this is so that operations teams can run the scan and fix widely, but if an application is found to be broken after the fact, just roll back everything on the device where the breakage occurred.
There is a lot of hesitation to deploy this utility widely in production in the actual
--fix --force-fix
mode to mitigate because of "what if it breaks things". Having an easy undo helps alleviate these concerns.I wouldn't consider this a high priority or anything, especially if it would be difficult, but I think it could be a very useful feature.