You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Ishan Chattopadhyaya (Jira)" <ji...@apache.org> on 2020/08/10 07:33:00 UTC
[jira] [Updated] (SOLR-14071) Untrusted configsets shouldn't be
allowed to use directive
[ https://issues.apache.org/jira/browse/SOLR-14071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ishan Chattopadhyaya updated SOLR-14071:
----------------------------------------
Description:
Allowing untrusted configsets, i.e. those have been uploaded using the configset upload API without authx enabled, to use the <lib> directive can open up possibilities for malicious users to include insecure contribs libraries.
Whoever wants to use their own libraries can add them to the classpath of Solr (i.e. place them wherever solr-core-*jar resides). For them, the <lib> directive won't be necessary anyway.
Update: another workaround (that is *NOT RECOMMENDED*) for this problem is to set the configset's "trusted" flag to true using direct ZK edit:
{code}
bin/zkCli.sh -server zk1:2181 set /configs/myConfigSet '{"trusted": "true"}'
{code}
^ This requires Zookeeper's CLI.
The same can be done via Java as well (here, we're unsetting the znode so that it is trusted):
{code}
try (SolrZkClient zkClient = new SolrZkClient(zookeeper.getHost() + ":" + zookeeper.getPort(), 100)) {
zkClient.setData(ZkConfigManager.CONFIGS_ZKNODE + "/" + configset, (byte[]) null, true);
}
{code}
was:
Allowing untrusted configsets, i.e. those have been uploaded using the configset upload API without authx enabled, to use the <lib> directive can open up possibilities for malicious users to include insecure contribs libraries.
Whoever wants to use their own libraries can add them to the classpath of Solr (i.e. place them wherever solr-core-*jar resides). For them, the <lib> directive won't be necessary anyway.
Update: another workaround (that is NOT RECOMMENDED) for this problem is to set the configset's "trusted" flag to true using direct ZK edit:
{code}
bin/zkCli.sh -server zk1:2181 set /configs/myConfigSet '{"trusted": "true"}'
{code}
^ This requires Zookeeper's CLI.
The same can be done via Java as well (here, we're unsetting the znode so that it is trusted):
{code}
try (SolrZkClient zkClient = new SolrZkClient(zookeeper.getHost() + ":" + zookeeper.getPort(), 100)) {
zkClient.setData(ZkConfigManager.CONFIGS_ZKNODE + "/" + configset, (byte[]) null, true);
}
{code}
> Untrusted configsets shouldn't be allowed to use <lib> directive
> ----------------------------------------------------------------
>
> Key: SOLR-14071
> URL: https://issues.apache.org/jira/browse/SOLR-14071
> Project: Solr
> Issue Type: Improvement
> Reporter: Ishan Chattopadhyaya
> Assignee: Ishan Chattopadhyaya
> Priority: Blocker
> Fix For: 8.4
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> Allowing untrusted configsets, i.e. those have been uploaded using the configset upload API without authx enabled, to use the <lib> directive can open up possibilities for malicious users to include insecure contribs libraries.
> Whoever wants to use their own libraries can add them to the classpath of Solr (i.e. place them wherever solr-core-*jar resides). For them, the <lib> directive won't be necessary anyway.
> Update: another workaround (that is *NOT RECOMMENDED*) for this problem is to set the configset's "trusted" flag to true using direct ZK edit:
> {code}
> bin/zkCli.sh -server zk1:2181 set /configs/myConfigSet '{"trusted": "true"}'
> {code}
> ^ This requires Zookeeper's CLI.
> The same can be done via Java as well (here, we're unsetting the znode so that it is trusted):
> {code}
> try (SolrZkClient zkClient = new SolrZkClient(zookeeper.getHost() + ":" + zookeeper.getPort(), 100)) {
> zkClient.setData(ZkConfigManager.CONFIGS_ZKNODE + "/" + configset, (byte[]) null, true);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org