[ 
https://issues.apache.org/jira/browse/SOLR-16777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ishan Chattopadhyaya updated SOLR-16777:
----------------------------------------
    Description: 
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.

  was:
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.

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.


> Schema Designer blindly "trusts" potentially malicious configset
> ----------------------------------------------------------------
>
>                 Key: SOLR-16777
>                 URL: https://issues.apache.org/jira/browse/SOLR-16777
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Ishan Chattopadhyaya
>            Assignee: Ishan Chattopadhyaya
>            Priority: Critical
>         Attachments: SOLR-16777.patch
>
>
> 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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to