[Geoserver-devel] Last message in dev mail archive is of 12th oct

2021-12-12 Thread Richard Duivenvoorde 

Hi Devs,

I often point to a link in the mailing archive if I do not want to repeat a 
answer, but I just found out that there is not archive anymore after 12th of 
Oct 2021

https://sourceforge.net/p/geoserver/mailman/geoserver-devel/

Is this a known issue?

Regards,

Richard Duivenvoorde


___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] log4j(2?) vulnurability?

2021-12-12 Thread Richard Duivenvoorde 

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 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 

(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 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/ 

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

Re: [Geoserver-devel] log4j(2?) vulnurability?

2021-12-12 Thread Richard Duivenvoorde 

Hi Jody,

Our 'OpenGeoGroep' in The Netherlands tries to give back around 10% of our 
profit to the FOSS projects we are using.

As Geoserver is an important corner stone for Open Geo stuff, and we were 
looking for candidates at his moment: we cansponsor at least  3 days (depending 
on tariff).

I will contact you in private.

Regards,

Richard Duivenvoorde

On 12/12/21 20:37, Jody Garnett wrote:

We still have not had resources to update to log4j2 … if anyone has budget or 
3-5 days of time we would be happy to upgrade and patch for this vulnerability.

Seriously our version of log4j is no longer supported and some technical debt 
that could use some love :)

Jody

On Sun, Dec 12, 2021 at 1:15 AM Richard Duivenvoorde mailto:rdmaili...@duif.net>> wrote:

Hi Devs,

In our national IT security group (and national news) there is an item 
about an issue with log4j2, pointing to:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-44228 

or
https://logging.apache.org/log4j/2.x/security.html 


As I deployed some Geoservers at some servers here and there :-) I'm 
wondering IF Geoserver (as being a public faced java application) is vulnarable 
or not...

Anybody can confirm Geoserver (or Tomcat) use log4j(2?) <=2.14.1? Or 
actually should Geoserver users do the mitigation actions written in the apache 
security link?
OR totally is not affected...

Any hints appreciated,

Regards,

Richard Duivenvoorde


___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net 

https://lists.sourceforge.net/lists/listinfo/geoserver-devel 


--
--
Jody Garnett




___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [JIRA] (GEOS-10333) log4j vulnerability issue

2021-12-12 Thread Muke Z (JIRA) 
Muke Z ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3Ad43b47ad-a959-49e0-862f-01b93431e21d
 ) *created* an issue

GeoServer ( 
https://osgeo-org.atlassian.net/browse/GEOS?atlOrigin=eyJpIjoiMmViODQ3YTdkMDQ4NDc2ZGJkMmNkNWFkYjBjMGNhYmMiLCJwIjoiaiJ9
 ) / Improvement ( 
https://osgeo-org.atlassian.net/browse/GEOS-10333?atlOrigin=eyJpIjoiMmViODQ3YTdkMDQ4NDc2ZGJkMmNkNWFkYjBjMGNhYmMiLCJwIjoiaiJ9
 ) GEOS-10333 ( 
https://osgeo-org.atlassian.net/browse/GEOS-10333?atlOrigin=eyJpIjoiMmViODQ3YTdkMDQ4NDc2ZGJkMmNkNWFkYjBjMGNhYmMiLCJwIjoiaiJ9
 ) log4j vulnerability issue ( 
https://osgeo-org.atlassian.net/browse/GEOS-10333?atlOrigin=eyJpIjoiMmViODQ3YTdkMDQ4NDc2ZGJkMmNkNWFkYjBjMGNhYmMiLCJwIjoiaiJ9
 )

Issue Type: Improvement Affects Versions: 2.20.1 Assignee: Unassigned 
Components: Configuration Created: 13/Dec/21 1:06 AM Priority: Medium Reporter: 
Muke Z ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3Ad43b47ad-a959-49e0-862f-01b93431e21d
 )

Due to the vulnerability issue of log4j recently. Is there a way can turn off 
log4j in Geoserver? or is there a plan patch for upgrading log4j?

Thanks

( 
https://osgeo-org.atlassian.net/browse/GEOS-10333#add-comment?atlOrigin=eyJpIjoiMmViODQ3YTdkMDQ4NDc2ZGJkMmNkNWFkYjBjMGNhYmMiLCJwIjoiaiJ9
 ) Add Comment ( 
https://osgeo-org.atlassian.net/browse/GEOS-10333#add-comment?atlOrigin=eyJpIjoiMmViODQ3YTdkMDQ4NDc2ZGJkMmNkNWFkYjBjMGNhYmMiLCJwIjoiaiJ9
 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( 
https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core=utm_source%3DNotificationLink%26utm_medium%3DEmail
 ) or iOS ( 
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495=EmailNotificationLink=8
 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100183- 
sha1:f6eba4b )___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] log4j(2?) vulnurability?

2021-12-12 Thread Jody Garnett 
We still have not had resources to update to log4j2 … if anyone has budget
or 3-5 days of time we would be happy to upgrade and patch for this
vulnerability.

Seriously our version of log4j is no longer supported and some technical
debt that could use some love :)

Jody

On Sun, Dec 12, 2021 at 1:15 AM Richard Duivenvoorde 
wrote:

> Hi Devs,
>
> In our national IT security group (and national news) there is an item
> about an issue with log4j2, pointing to:
>
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-44228
> or
> https://logging.apache.org/log4j/2.x/security.html
>
> As I deployed some Geoservers at some servers here and there :-) I'm
> wondering IF Geoserver (as being a public faced java application) is
> vulnarable or not...
>
> Anybody can confirm Geoserver (or Tomcat) use log4j(2?) <=2.14.1? Or
> actually should Geoserver users do the mitigation actions written in the
> apache security link?
> OR totally is not affected...
>
> Any hints appreciated,
>
> Regards,
>
> Richard Duivenvoorde
>
>
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
-- 
--
Jody Garnett
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] log4j(2?) vulnurability?

2021-12-12 Thread Andrea Aime 
On Sun, Dec 12, 2021 at 3:45 PM mark  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!

Visit 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/

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

Re: [Geoserver-devel] log4j(2?) vulnurability?

2021-12-12 Thread mark 

Op 12-12-2021 om 10:14 schreef Richard Duivenvoorde:

Hi Devs,

In our national IT security group (and national news) there is an item 
about an issue with log4j2, pointing to:


http://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-44228
or
https://logging.apache.org/log4j/2.x/security.html

As I deployed some Geoservers at some servers here and there :-) I'm 
wondering IF Geoserver (as being a public faced java application) is 
vulnarable or not...


Anybody can confirm Geoserver (or Tomcat) use log4j(2?) <=2.14.1? Or 
actually should Geoserver users do the mitigation actions written in the 
apache security link?

OR totally is not affected...



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)


The general use case for log4J (gen. 1 / 1.2.x) is logging to a file 
using a FileAppender or the console using a Console Appender, it's what 
Geoserver does.
The networking appenders such as smtp appender and other 
networked/socket appenders don't work very well under high load and do 
contain some serious issues; but, again, are not used by GeoServer.


Mark



___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] log4j(2?) vulnurability?

2021-12-12 Thread Richard Duivenvoorde 

On 12/12/21 12:43, Marc Jansen wrote:

Hi all,

I found this thread on twitter, might contain some information in this regard: 
https://twitter.com/geowolf/status/1469347543087779848 



Yes, that is what I found too: Geoserver does not seem to use log4j2 (but log4j 
v1.x)...

I could not find the log4j2  JndiLookup.class (which you are supposed to 
remove) in geoserver jars (nor a Tomcat jars I downloaded by the way...)

But not fully convinced yet...

Regards,

Richard


___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] log4j(2?) vulnurability?

2021-12-12 Thread Marc Jansen 
Hi all,

I found this thread on twitter, might contain some information in this regard: 
https://twitter.com/geowolf/status/1469347543087779848

HTH

Best
Marc

Am 12. Dezember 2021 10:14:28 MEZ schrieb Richard Duivenvoorde 
:
>Hi Devs,
>
>In our national IT security group (and national news) there is an item about 
>an issue with log4j2, pointing to:
>
>http://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-44228
>or
>https://logging.apache.org/log4j/2.x/security.html
>
>As I deployed some Geoservers at some servers here and there :-) I'm wondering 
>IF Geoserver (as being a public faced java application) is vulnarable or not...
>
>Anybody can confirm Geoserver (or Tomcat) use log4j(2?) <=2.14.1? Or actually 
>should Geoserver users do the mitigation actions written in the apache 
>security link?
>OR totally is not affected...
>
>Any hints appreciated,
>
>Regards,
>
>Richard Duivenvoorde
>
>
>___
>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

[Geoserver-devel] log4j(2?) vulnurability?

2021-12-12 Thread Richard Duivenvoorde 

Hi Devs,

In our national IT security group (and national news) there is an item about an 
issue with log4j2, pointing to:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-44228
or
https://logging.apache.org/log4j/2.x/security.html

As I deployed some Geoservers at some servers here and there :-) I'm wondering 
IF Geoserver (as being a public faced java application) is vulnarable or not...

Anybody can confirm Geoserver (or Tomcat) use log4j(2?) <=2.14.1? Or actually 
should Geoserver users do the mitigation actions written in the apache security 
link?
OR totally is not affected...

Any hints appreciated,

Regards,

Richard Duivenvoorde


___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel