Thanks for the email Hannes.
We had this discussion (on responsible disclosure
<http://osgeo-org.1560.x6.nabble.com/Handling-of-a-detected-security-flaw-tt5139395.html#a5139410>)
last year - and had some agreement how we would like issue of this nature
to be handled.
Please take moment to review that thread
<http://osgeo-org.1560.x6.nabble.com/Handling-of-a-detected-security-flaw-tt5139395.html#a5139410>
so we do not cover the same ground again. As volunteers we are often
passed the results of security audits in public
<http://osgeo-org.1560.x6.nabble.com/Some-results-of-external-security-test-cross-site-scripting-and-request-for-a-bit-of-help-on-fixes-td5039681.html>
and
in private.
aside: It was not responsible to include in the issue report a
demonstration of the flaw. In situations like this I would expect a user
contact the project team (the steering committee as listed on our website,
or Andrea who is our OSGeo project officer). The user report was
understandably upset, so I did not take them to ask in this case - perhaps
that was a mistake on my part.
Although the above discussion explored the issue we did not get any solid
procedure change into our developers guide. Something we could put on the
agenda for tomorrows Skype meeting. As a member of the community you are
welcome to join that Skype meeting.
With respect to an immediate release I am not in position to volunteer my
time, or any volunteer here toward that effort. What we could do is pull
previous release off the website until a replacement is available next
month.
Although we wish we were in position to release the software as needed in
cases like this we do not have the resources as volunteers on this project.
We have very carefully committed to a monthly release cycle, both to our
respective employers (to keep a lid on the amount of community work that is
done) and to each other (to prevent team members burning out).
What I can do is offer to help you make the release, this is just my own
habit as a project lead helping new contributors take part.
--
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
