[
https://issues.apache.org/jira/browse/SOLR-6736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15881883#comment-15881883
]
Ishan Chattopadhyaya edited comment on SOLR-6736 at 2/24/17 3:42 AM:
---------------------------------------------------------------------
I have created a branch jira/solr-6736 with the latest patch (after updating it
for master).
Regarding the security vulnerability that this new API exposes, I have the
following thoughts to take this forward:
# We can allow unauthenticated/unauthorized users to upload a configset, but
mark such configsets with a "trusted=false" flag while storing in ZK (metadata
on the configset's znode). If this endpoint is secured using authorization and
authentication, then we can store the uploaded configsets with "trusted=true".
# Upon creation of a collection using an untrusted configset, any attempt to
register a "vulnerable" component, e.g. StatelessScriptUpdateProcessor,
XsltUpdateRequestHandler, DataImportHandler etc., should fail with an error
that indicates that the configset was not trusted and it can be made trusted by
enabling authentication/authorization for the API endpoint and re-uploading the
configset. Same error when using a config API command to register any update
handler using an untrusted configset.
# Ensure that untrusted configsets never overwrite existing trusted configsets.
As a separate exercise, we should audit our use of the XML parser to ensure XXE
attacks are not possible on XML files, either uploaded from here/elsewhere or
loaded from the disk.
[~varunrajput], [~anshumg], [~noble.paul], WDYT?
was (Author: ichattopadhyaya):
I have created a branch jira/solr-6736 with the latest patch (after updating it
for master).
Regarding the security vulnerability that this new API exposes, I have the
following thoughts to take this forward:
# We can allow unauthenticated/unauthorized users to upload a configset, but
mark such configsets with a "trusted=false" flag while storing in ZK (metadata
on the configset's znode). If this endpoint is secured using authorization and
authentication, then we can store the uploaded configsets with "trusted=true".
# Upon creation of a collection using an untrusted configset, any attempt to
register a "vulnerable" component, e.g. StatelessScriptUpdateProcessor,
XsltUpdateRequestHandler, DataImportHandler etc., should fail with an error
that indicates that the configset was not trusted and it can be made trusted by
enabling authentication/authorization for the API endpoint and re-uploading the
configset. Same error when using a config API command to register any update
handler using an untrusted configset.
As a separate exercise, we should audit our use of the XML parser to ensure XXE
attacks are not possible on XML files, either uploaded from here/elsewhere or
loaded from the disk.
[~varunrajput], [~anshumg], [~noble.paul], WDYT?
> A collections-like request handler to manage solr configurations on zookeeper
> -----------------------------------------------------------------------------
>
> Key: SOLR-6736
> URL: https://issues.apache.org/jira/browse/SOLR-6736
> Project: Solr
> Issue Type: New Feature
> Components: SolrCloud
> Reporter: Varun Rajput
> Assignee: Ishan Chattopadhyaya
> Attachments: newzkconf.zip, SOLR-6736-newapi.patch,
> SOLR-6736-newapi.patch, SOLR-6736-newapi.patch, SOLR-6736.patch,
> SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch,
> SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch, test_private.pem,
> test_pub.der, zkconfighandler.zip, zkconfighandler.zip
>
>
> Managing Solr configuration files on zookeeper becomes cumbersome while using
> solr in cloud mode, especially while trying out changes in the
> configurations.
> It will be great if there is a request handler that can provide an API to
> manage the configurations similar to the collections handler that would allow
> actions like uploading new configurations, linking them to a collection,
> deleting configurations, etc.
> example :
> {code}
> #use the following command to upload a new configset called mynewconf. This
> will fail if there is alredy a conf called 'mynewconf'. The file could be a
> jar , zip or a tar file which contains all the files for the this conf.
> curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
> @testconf.zip
> http://localhost:8983/solr/admin/configs/mynewconf?sig=<the-signature>
> {code}
> A GET to http://localhost:8983/solr/admin/configs will give a list of configs
> available
> A GET to http://localhost:8983/solr/admin/configs/mynewconf would give the
> list of files in mynewconf
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
