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

Mark Robert Miller commented on SOLR-16777:
-------------------------------------------

LGTM.

Summarized changes:

ZkConfigSetService.java: The method signature of loadConfigSetFlags was 
modified to remove the CoreDescriptor parameter.

ConfigSetService.java:

Import of ZkSolrResourceLoader was removed.
Two methods, isConfigSetTrusted(String name) and 
isConfigSetTrusted(SolrResourceLoader coreLoader), were added to check whether 
a given config set or a config set associated with a resource loader is trusted.
In the loadConfigSet method, the check for a trusted config set was replaced 
with a call to the new isConfigSetTrusted method.
The createSolrConfig method was updated to use the isConfigSetTrusted method 
for the trusted argument.
The loadConfigSetFlags method was modified, similar to the change in 
ZkConfigSetService.java, to remove the CoreDescriptor parameter.
ConfigSetAPIBase.java:

The isTrusted method was made static, and its visibility was changed to public.
The isCurrentlyTrusted method was removed.
The method ensureOverwritingUntrustedConfigSet was updated to use 
configSetService.isConfigSetTrusted(configName) instead of 
isCurrentlyTrusted(configName).
CreateConfigSetAPI.java: Updated to use 
configSetService.isConfigSetTrusted(createConfigPayload.baseConfigSet) instead 
of isCurrentlyTrusted(createConfigPayload.baseConfigSet).

UploadConfigSetAPI.java: Updated to use 
configSetService.isConfigSetTrusted(configSetName) instead of 
isCurrentlyTrusted(configSetName).

SchemaDesignerAPI.java: Updated to use the static isTrusted method from 
ConfigSetAPIBase.java. Also added logic to remove the trusted flag on the 
configSet if the request is untrusted.

SchemaDesignerConfigSetHelper.java: Updated to load the Solr config with the 
trusted flag retrieved from isConfigSetTrusted. Added isConfigSetTrusted and 
removeConfigSetTrust methods.

Trust is now determined based on the config set itself rather than on the 
loading process, and checks for trust have been centralized in the 
ConfigSetService class.

> Schema Designer blindly "trusts" potentially malicious configset
> ----------------------------------------------------------------
>
>                 Key: SOLR-16777
>                 URL: https://issues.apache.org/jira/browse/SOLR-16777
>             Project: Solr
>          Issue Type: Bug
>    Affects Versions: 9.0, 8.10, 8.11.2, 9.1, 9.2, 9.1.1
>            Reporter: Ishan Chattopadhyaya
>            Assignee: Ishan Chattopadhyaya
>            Priority: Blocker
>             Fix For: 9.3
>
>         Attachments: SOLR-16777-1.patch, SOLR-16777.patch, 
> Screenshot_20230503_165913.jpg, Screenshot_20230503_181534.jpg
>
>          Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> When configset API is used to upload configsets by unauthenticated users, a 
> "trusted: false" flag is set on the configset. Such configsets cannot use the 
> <lib> directive to load classes while creating/loading collections. Details 
> here: https://solr.apache.org/guide/8_10/configsets-api.html#configsets-upload
> Unfortunately, this safety mechanism was bypassed in the schema designer when 
> a isConfigsetTrusted was hardcoded to true. 
> [https://github.com/apache/solr/blob/branch_9_1/solr/core/src/java/org/apache/solr/handler/designer/SchemaDesignerConfigSetHelper.java#L697]
>  
> As per Skay's report 
> [https://twitter.com/Skay_00/status/1646870062601756672|https://twitter.com/Skay_00/status/1646870062601756672),]
>  remote code execution is possible in unsecured Solr clusters where 
> authentication hasn't been enabled. This ticket is to mitigate one aspect of 
> that, i.e. the schema designer vulnerability. While our recommendation to all 
> users remains the same, i.e. to secure Solr installations with authentication 
> and authorization, I thank Skay for his detailed report.



--
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

Reply via email to