Hannes:
Your email provides an extensive background on the risk associated with the
issue.
Would you be willing to rework the content into a blog post for the
website. It would help explain what is going on in the event we choose to
delist the 2.7.1 release and ask users to grab a nightly build.
I do not know anything about asking for a CVE.
Jody
--
Jody Garnett
On 22 June 2015 at 14:07, Johannes Kröger <[email protected]>
wrote:
> Hi!
>
> Earlier I posted things on Twitter and IRC that others seem to have
> taken as more or less personal attacks or at least abrasive ranting. I
> am sorry about that, please do not take my criticism personal. It is
> easy to forget that there are people behind "words on the internet".
> However I was and still am shocked at the handling of a critical
> security issue in GeoServer and the neglect to protect the users. I
> might be overreacting but I am reasonably sure that I am not. The
> responses I got suggest that people do not realise the severity of the
> issue and thus both sides get agitated. This mail might be very
> "rambly", sorry.
>
> TL;DR: GeoServer let(s) unauthenticated remote users read arbitrary
> files from the servers it runs on. This was and is not properly
> communicated to its users nor is the fix properly distributed.
>
> == The issue ==
>
> This is about https://osgeo-org.atlassian.net/browse/GEOS-7032
>
> That is a problem with everyone's favorite XEE:
> https://www.owasp.org/index.php/XML_External_Entity_%28XXE%29_Processing
>
> https://www.owasp.org/images/5/5d/XML_Exteral_Entity_Attack.pdf has
> some more things one can do with this, page 28+.
>
> This also shows directory listings.
>
> You can gather a lot of intelligence about servers if you can read
> arbitrary (as long as permissions allow) files. Being also able to see
> directory listings helps a lot at discovery. Since you will access files
> as the webserver (I guess?) you will also have access to things like
> scripts and configurations in which you might find things like database
> credentials.
>
> As something is trying to parse the files as XML, many files result in
> errors rather than their whole plain text being printed. There might be
> ways around that, I am not sure.
>
> People have suggested that it is only severe if you run GeoServer
> (well, it's server) as root, but I doubt that. If this gives you full
> access to any arbitrary file remotely as root, this is catastrophic. If
> you can "just" read all the files you can as non-root user of the
> webserver, it is more than severe enough.
>
> While this is not a remote code execution, it has severe effects on
> system security and might lead to easy discovery of a RCE. If the
> severity is still not clear, please say so and I will try to research a
> bit more (alternatively give me the OK to snoop around a GeoServer of
> yours (production, not "empty" demo) as example). I am not a security
> guy myself, just a random "hacker" in the classic sense of the word,
> curious at how things work and how they break.
>
> == The timeline so far ==
>
> May 18th the issue was reported, including a working example exploit.
> May 28th a fix was implemented in the sources.
> June 18th GeoServer 2.6.4 was released
>
> == The response ==
>
> The reporter included a working example and some details about the
> severity of the bug. While I have not tested it, the bug should also
> affect Windows just the same. The severity is understated in the
> comments, suggesting that it is only a major issue if GeoServer is run
> as root.
>
> Response from the GeoServer team was quick and constructive. The fix
> was written and implemented in a very reasonable time frame, especially
> considering it is the work of volunteers. The comment says: "Will be
> part of 2.7.2 and 2.6.4, we are not cutting releases anymore from 2.5.x
> nor buildling it, so a build from source will be required for those
> that use 2.5.x".
>
> Now, this was almost one month ago. The first new release that included
> the fix came on June 18th for the "stable" branch of GeoServer, 2.6.4.
> The issue and its fix were mentioned in the body of the announcement
> with bold text.
>
> Now if you look at http://geoserver.org/download/ , you see 2.7.1
> advertised as the stable, recommended release of GeoServer. That is
> 2.7.1 with this issue inside, suggested for installation for new users.
> And any users of the 2.7. branch are not alerted of the issue in its
> code until 2.7.2 happens.
>
> Again in other words:
> You are distributing software with a known remote file disclosure issue
> to any new users. You have not notified the users of the 2.7. branch in
> any way about a remote file disclosure issue. You have not notified the
> users of the 2.6. branch or provided a fix for 3 weeks.
>
> The issue and its fix in 2.6. were not given any special announcement,
> they were (emphasized) part of completely normal release notes. There
> was no extra mail or post, no CVE. You know your users better than me
> though, maybe they all always read all the release notes or maybe
> GeoServer has some internal notification system (I only used it once,
> years ago).
>
> Considering how widely GeoServer is deployed, not to mention the many
> government servers, this shocks me. If you look around today, you can
> find more vulnerable servers than patched ones. This includes machines
> at companies that I would think are being closely integrated in the
> FLOSS geo community and thus should be aware of new releases (eg.
> Boundless, GeoSolutions, WhereGroup).
>
> I looked around for some common best practices or guidelines on how to
> handle such severe bugs and communicating them to a community but sadly
> came up empty handed. :(
>
> A common procedure seems to hide the bug report from the public until
> the fix iss ready and distributed to all branches. How critical issues
> are then communicated differs a lot, some projects have dedicated
> mailing lists for that.
>
> Please immediately try to release an update for the 2.7. branch. Please
> try to notify your users in any way about this issue that they
> know it *requires* them to act to protect the security of their systems.
> I would suggest a mail and blog post with a warning in its title. We all
> know how easy it is to dismiss "just another release of something".
>
> If it is possible, I would suggest requesting a CVE so that
> administrators that follow those will be notified about the issue.
>
> Thanks for reading! I hope I made it more clear why I think that this
> requires a much bigger response and responsible handling.
>
> All the best, Hannes
>
>
> ------------------------------------------------------------------------------
> Monitor 25 network devices or servers for free with OpManager!
> OpManager is web-based network management software that monitors
> network devices and physical & virtual servers, alerts via email & sms
> for fault. Monitor 25 devices for free with no restriction. Download now
> http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
> _______________________________________________
> Geoserver-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
------------------------------------------------------------------------------
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors
network devices and physical & virtual servers, alerts via email & sms
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
