[jira] [Comment Edited] (SOLR-5287) Allow at least solrconfig.xml and schema.xml to be edited via the admin screen

["Uwe Schindler (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-5287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13835855#comment-13835855 ] 

Uwe Schindler edited comment on SOLR-5287 at 11/30/13 6:22 PM:
---------------------------------------------------------------

Hi,
I don't want to be "the bad guy" or a showstopper, but this should be reverted before Solr 4.7 comes out. From a security perspective, we cannot do this at all, unless we add some login features to the admin UI and some request handlers.

Together with the help of security guys we already closed some horrible leaks in Solr, that may be used to view local files outside of Solr's config directly. Some examples are the recently XML-based attacks: external entities on data imports (SOLR-3895), escaping from SolrResourceLoader to read etc/passwd (SOLR-4882),...

This week the Redhat people contacted me about those issues and they are very happy that they are resolved. Now they are also working on Solr 3.6.x and will fix the issues there, too.

The problems with all this is partly Solr's openness for requests from anywhere, so in an ideal world, you have to use a firewall to limit access to the Solr server.

Unfortunately a firewall is not always enough. If you have something like a small XXE vulnerability in your front-end server (using Solr) and the user from the outside can "trick" the server to send special crafted HTTP-requests to the Solr server behind your firewall (the Solr server must be accessible from the fron-end server, otherwise you would not be able to use Solr).

By closing those attacks I took care of, at least big issues can be prevented (although you might be still possible to execute some crazy javascript with function queries - if enabled in the config), but you can no longer send documents to solr that use xinclude/external entities to load local files from the server. Or ask for velocity templates or XSL stylesheets from outside config dir.

The problem opened by this issue is the following: You can upload any arbitrary file to the config directory without any checks. So you could theoretically also upload an XSL file and then use it with the tr=... parameter. As XSL can execute any java code, you have full control on the system.

Another thing is the fact that we allow explicitely xinclude and external entities on solrconfig and solrschema.xml (to allow structuring your config into parts). This was done under the knowledge, that the files using external entities/xinclude can only be placed in the config dir, if you have access to the local file system on the server.

Now that you can upload any file and change anything, you are wide open to any attack you can think of. There is no more security at all, once you have access to ShowFileRequestHandler, you can do anything on the Solr server, really anything!

If you are interested about how to "hack" a Solr server (before 4.6) that is sitting behind a firewall through a vulnerable front-end server, read [http://www.agarri.fr/blog/]

Redhat already assigned 3 CVE numbers to these issues and take the older issues seriously, and they will patch older versions and also force users to upgrade. cf, [CVE-2013-6397|https://access.redhat.com/security/cve/CVE-2013-6397] (SOLR-4882), [CVE-2013-6407|https://access.redhat.com/security/cve/CVE-2013-6407] (SOLR-3895), [CVE-2013-6408|https://access.redhat.com/security/cve/CVE-2013-6408] (SOLR-4881).

If Redhat would know about this feature in Solr 4.7, they would throw Solr out of the window and remove it from their packages! This commit will make the project really look bad for security people. And users will think that Solr should be avoided.


was (Author: thetaphi):
Hi,
I don't want to be "the bad guy" or a showstopper, but this should be reverted before Solr 4.7 comes out. From a security perspective, we cannot do this at all, unless we add some login features to the admin UI and some request handlers.

Together with the help of security guys we already closed some horrible leaks in Solr, that may be used to view local files outside of Solr's config directly. Some examples are the recently XML-based attacks: external entities on data imports (SOLR-3895), escaping from SolrResourceLoader to read etc/passwd (SOLR-4882),...

This week the Redhat people contacted me about those issues and they are very happy that they are resolved. Now they are also working on Solr 3.6.x and will fix the issues there, too.

The problems with all this is partly Solr's openness for requests from anywhere, so in an ideal world, you have to use a firewall to limit access to the Solr server.

Unfortunately a firewall is not always enough. If you have something like a small XXE vulnerability in your front-end server (using Solr) and the user from the outside can "trick" the server to send special crafted HTTP-requests to the Solr server behind your firewall (the Solr server must be accessible from the fron-end server, otherwise you would not be able to use Solr).

By closing those attacks I took care of, at least big issues can be prevented (although you might be still possible to execute some crazy javascript with function queries - if enabled in the config), but you can no longer send documents to solr that use xinclude/external entities to load local files from the server. Or ask for velocity templates or XSL stylesheets from outside config dir.

The problem opened by this issue is the following: You can upload any arbitrary file to the config directory without any checks. So you could theoretically also upload an XSL file and then use it with the tr=... parameter. As XSL can execute any java code, you have full control on the system.

Another thing is the fact that we allow explicitely xinclude and external entities on solrconfig and solrschema.xml (to allow structuring your config into parts). This was done under the knowledge, that the files using external entities/xinclude can only be placed in the config dir, if you have access to the local file system on the server.

Now that you can upload any file and change anything, you are wide open to any attack you can think of. There is no more security at all, once you have access to ShowFileRequestHandler, you can do anything on the Solr server, really anything!

If you are interested about how to "hack" a Solr server (before 4.6) that is sitting behind a firewall through a vulnerable front-end server, read [http://www.agarri.fr/blog/]

Redhat already assigned 2 CVE numbers to these issues and take the older issues seriously, and they will patch older versions and also force users to upgrade. cf, [CVE-2013-6397|https://access.redhat.com/security/cve/CVE-2013-6397] (SOLR-4882), [CVE-2013-6407|https://access.redhat.com/security/cve/CVE-2013-6407] (SOLR-3895), [CVE-2013-6408|https://access.redhat.com/security/cve/CVE-2013-6408] (SOLR-4881).

If Redhat would know about this feature in Solr 4.7, they would throw Solr out of the window and remove it from their packages! This commit will make the project really look bad for security people. And users will think that Solr should be avoided.

> Allow at least solrconfig.xml and schema.xml to be edited via the admin screen
> ------------------------------------------------------------------------------
>
>                 Key: SOLR-5287
>                 URL: https://issues.apache.org/jira/browse/SOLR-5287
>             Project: Solr
>          Issue Type: Improvement
>          Components: Schema and Analysis, web gui
>    Affects Versions: 4.5, 5.0
>            Reporter: Erick Erickson
>            Assignee: Erick Erickson
>             Fix For: 5.0, 4.7
>
>         Attachments: SOLR-5287.patch, SOLR-5287.patch, SOLR-5287.patch, SOLR-5287.patch, SOLR-5287.patch
>
>
> A user asking a question on the Solr list got me to thinking about editing the main config files from the Solr admin screen. I chatted briefly with [~steffkes] about the mechanics of this on the browser side, he doesn't see a problem on that end. His comment is there's no end point that'll write the file back.
> Am I missing something here or is this actually not a hard problem? I see a couple of issues off the bat, neither of which seem troublesome.
> 1> file permissions. I'd imagine lots of installations will get file permission exceptions if Solr tries to write the file out. Well, do a chmod/chown.
> 2> screwing up the system maliciously or not. I don't think this is an issue, this would be part of the admin handler after all.
> Does anyone have objections to the idea? And how does this fit into the work that [~sarowe@syr.edu] has been doing?
> I can imagine this extending to SolrCloud with a "push this to ZK" option or something like that, perhaps not in V1 unless it's easy.....
> Of course any pointers gratefully received. Especially ones that start with "Don't waste your effort, it'll never work (or be accepted)"...
> Because what scares me is this seems like such an easy thing to do that would be a significant ease-of-use improvement, so there _has_ to be something I'm missing.
> So if we go forward with this we'll make this the umbrella JIRA, the two immediate sub-JIRAs that spring to mind will be the UI work and the endpoints for the UI work to use.
> I think there are only two end-points here
> 1> list all the files in the conf (or arbitrary from <solr_home>/collection) directory.
> 2> write this text to this file
> Possibly later we could add "clone the configs from coreX to coreY".
> BTW, I've assigned this to myself so I don't lose it, but if anyone wants to take it over it won't hurt my feelings a bit....



--
This message was sent by Atlassian JIRA
(v6.1#6144)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org