Thanks Andrea for your analysis. Then I think I'll put Geoserver as non vulnerable (or at least not easy) on this list then:
https://github.com/NCSC-NL/log4shell/tree/main/software (NCSC == National Cyber Security Centre of NL) About your analysis, here: https://www.lunasec.io/docs/blog/log4j-zero-day/ I read that (at least in the >2.0 version) it seems possible to load a Class file via JNDI of a remote server which then could be loaded in server process and be triggered in a second stage. But I'm not so much in Java Class loading anymore to conclude if that is different from your text. Anyway: thanks and I hope this will not create to much havoc in the Log4j (user) world... Regards, Richard Duivenvoorde On 12/12/21 17:00, Andrea Aime wrote:
On Sun, Dec 12, 2021 at 3:45 PM mark <mc.pr...@gmail.com <mailto:mc.pr...@gmail.com>> wrote: Only in very, very specific configurations is log4j (gen. 1 / 1.2.x) vulnerable - but not in the same way as log4j2; it requires using a JMS Appender that uses jdni. please read https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126 <https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126> (and linked comments there) Looking at the comments and code, I have the impression that even having a JMSAppender configured, is not enough to trigger the issue, because it's still not trying to expand user input that might come from a request. The vulnerable code is in an initialization reading the configuration file. So basically, in order to make that work, the attacker needs to have console access, gain write access to the data directory, change the log configuration to one that would trigger the issue, and then wait for a GeoServer restart, or a configuration reload. The attacker has to go through all these lengths only if it cannot find anything else on the system that can be used for an attack. Just to give you an idea, if they have rights to modify the GeoServer war file, they can swap a jar with one that has the same named classes, but which internally do whatever they please. This looks, to me, a very narrow window of opportunity, in order to make that happen they already punched a hole in the network and ssh access, and of all the possibilities they have at that point, they go and choose an attack path that they cannot even trigger directly? We might improve our deployment a bit by removing the JMSAppender class from the log4j 1.2.x jar (or replacing with one that just throws exceptions on usage)... it will help for cases where the attacker gets access to the console, can write on the data dir, but not to the war itself. And can be done in time for next releases (given the attacker needs to gain console access first, to leverage the above vulnerability, do we really need to re-release GeoServer?) Then we can discuss an upgrade to a newer logging library... (log4j2, logback, or something else). And maybe also looking into how to set aside a pot of money to handle vulnerabilities like this one, using donations only: I like how this balances well with the user community, want free security fixes? We'll be able to work on it proportionally to how much users themselves care about the subject. Cheers Andrea == GeoServer Professional Services from the experts! Visit http://bit.ly/gs-services-us <http://bit.ly/gs-services-us>for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions Group phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 333 8128928 https://www.geosolutionsgroup.com/ <https://www.geosolutionsgroup.com/> http://twitter.com/geosolutions_it <http://twitter.com/geosolutions_it> ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
