Thanks Andrea for your analysis.
Then I think I'll put Geoserver as non vulnerable (or at least not easy) on this list then:
Anyway: thanks and I hope this will not create to much havoc in the Log4j (user) world...
On Sun, Dec 12, 2021 at 3:45 PM mark <mc.prins@anonymised.com <mailto:mc.prins@anonymised.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
(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!
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions Group
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 333 8128928
https://www.geosolutionsgroup.com/
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
I'm wondering IF Geoserver (as being a public faced java application) is vulnarable or not...