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

Gus Heck commented on SOLR-16777:
---------------------------------

[https://solr.apache.org/guide/solr/latest/configuration-guide/configsets-api.html#configsets-upload]

specifies two other features that also are only available with trusted 
configsets. <lib> is not the only issue. So unless the whole trusted config set 
feature is going away hard-coding a value seems to create a trap for the user.

I don't have time to work on this right now, but I'm -1 on anything that makes 
schema designer (or any other feature) fail for unclear reasons. If the error 
message is clear enough, and the ref guide is updated to clarify the 
incompatibility of the listed "trusted" features with schema designer and we 
commit to doing something nicer in 9.3 I'll change that to -0.9, but it would 
be much better to be consistent with the existing feature. 

Security is important,  but we shouldn't make our software trappy and hard to 
use either.

> 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.2.2
>
>         Attachments: SOLR-16777.patch
>
>          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