[
https://issues.apache.org/jira/browse/SOLR-16777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17719052#comment-17719052
]
Jason Gerlowski commented on SOLR-16777:
----------------------------------------
+1 to what Gus said, and Jan's decision to reopen.
bq. Sure, please feel free to re-open and add the check here.
Procedurally, responding to review this way feels...maybe not "wrong", but at
least "odd". And maybe even slightly harmful?
Obviously I'm not saying every last review comment needs addressed. Some are
too minor or loosely held even by the reviewer. Often there's competing views,
or a suggestion might deserve its own spinoff ticket, etc. That stuff happens
all the time.
But to seemingly agree after a few back-and-forth's (or at least acquiesce?)
and still not incorporate the feedback - with no explanation - just feels a
little weird. It discounts the time Gus and others put in to their reviews.
And, longer term, it'd be natural for anyone reading here to hesitate before
giving you a review the next time around. Which, it goes without saying, hurts
everyone.
[~ichattopadhyaya] could you please at least explain why you don't care to
incorporate Gus' feedback?
> 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
