[
https://issues.apache.org/jira/browse/SOLR-16777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17718579#comment-17718579
]
Ishan Chattopadhyaya commented on SOLR-16777:
---------------------------------------------
<lib> and other unsafe features mentioned in the configset upload API will
generate an error (with the reason) when loaded from untrusted configsets.
Those features shouldn't be used anyway, so if they dont work with schema
designer, it is not the end of the world.
{quote}Which feature are you referring to as carried forward
{quote}
I guess he's referring to <lib> and other insecure features (stateless script
update processor?) etc.
> 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
