[
https://issues.apache.org/jira/browse/SOLR-15844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17458852#comment-17458852
]
Gus Heck commented on SOLR-15844:
---------------------------------
TLDR: you've done the work already, so no need to revert it but I don't think
it busy us anything in terms of safety
Long form / PSA for anyone who might interpret this fix as "velocity templates
are now worry free":
I'm a bit confused perhaps, and maybe I missed something somewhere (I haven't
had time to dig through velocity discussion on this CVE), but IIRC at the time
we published our CVE (that I linked), the idea was that people who can change
config templates generally control solr anyway. Only the ability to specify
templates at request time is an escalation of user capabilities because the
query author didn't have permission to modify the server. I think this change
fixes a non-problem.
On the whole CVE-2020-13936 seems strange because with the binding of java
methods to expressions in Velocity has always had the well known limitation
that templates are effectively java code. (this happens with any tools that use
something like like jexel or OGNL or jsp-el see
[https://owasp.org/www-community/vulnerabilities/Expression_Language_Injection]).
There have always been warnings vs double eval of templates for this reason as
well, dating back to when I first encountered velocity something like 15 years
ago IIRC. Also see VELOCITY-877
So the first CVE seems like the oldest news in the world and I really wonder
why it comes out at all let alone now.
The second CVE listed in this issue I guess implies that there is a class
called SecureUberspector in newer versions that attempts to guard some set of
java[ classes and
packages|https://github.com/apache/velocity-engine/pull/16/files#diff-5f6106181b24473026d26104da80efd32ae2a1ad813c0cec850752b353b6ad07],
and if someone were to rely on the default implementation of that, it's
failure would be reasonably concerning.... Yet, unmodified, it does nothing to
protect from people calling your own application's methods etc... (nor could it
even if they wanted to!) So the moment you store a ref to one of those classes
or wrap one of their methods etc presto, bypass available). It is at best a
false sense of security, doubly so for an open source project where people can
find out the names of all your classes and methods.
Basically IMHO it is a questionable mitigation of the fundamental limitation of
expression language libraries, and unless it's doing something really deep and
comprehensive, it's going to be leaky at best (e.g. do something like google's
Object Capabilities Model in [Caja|https://en.wikipedia.org/wiki/Caja_project]
for html/javscript/css .. which was too hard for even google to maintain!)..
>From a Solr perspective, use of velocity templates in any form, simply is
>permission for the user who adds the template to control the server. If
>templates are added to configs without review then you trust that user. Full
>stop. I fully expect that I'd be able to wreak all kinds of havoc on a server
>that had this patch if you allowed me to specify velocity template.
Peeking a little into
[SecureUberspector|https://github.com/VISTALL/apache.velocity-engine/blob/5aa0fc061b5a40313bb6019562966b3d207b98ed/velocity-engine-core/src/main/java/org/apache/velocity/util/introspection/SecureIntrospectorImpl.java#L88]
it relies on having a velocity configuration value that specifies a
*badClasses* and *badPackages* list... this is "allow by default" and therefore
insecure unless you've customized the config's list of classes and packages to
properly hide the application classes... i.e. any dangerous classes in solr or
any of it's dependencies... and keep that list up to date.
It doesn't hurt to update Velocity of course, but I am worried about this
update creating a false sense of security WRT allowing the use of velocity
templates in the first place.
> Upgrade Velocity to v2.3
> ------------------------
>
> Key: SOLR-15844
> URL: https://issues.apache.org/jira/browse/SOLR-15844
> Project: Solr
> Issue Type: Bug
> Affects Versions: 8.11
> Reporter: wcmrnd1
> Assignee: Jan Høydahl
> Priority: Blocker
> Fix For: 8.11.1
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Latest Version of Solr 8.11 bundles Apache Velocity 2.0 jar that has the
> following vulnerabilities:
>
> h1. Vulnerability Details
> h2. CVE-2020-13936
> *Vulnerability Published:* 2021-03-10 03:15 EST
> *Vulnerability Updated:* 2021-09-23 08:21 EDT
> *CVSS Score:* {color:#FF0000}8.8{color} (overall), {color:#FF0000}8.8{color}
> (base)
> {*}Summary{*}: An attacker that is able to modify Velocity templates may
> execute arbitrary Java code or run arbitrary system commands with the same
> privileges as the account running the Servlet container. This applies to
> applications that allow untrusted users to upload/modify velocity templates
> running Apache Velocity Engine versions up to 2.2.
> {*}Solution{*}: N/A
> {*}Workaround{*}: N/A
> h2. BDSA-2021-0710
> *Vulnerability Published:* 2021-03-22 12:01 EDT
> *Vulnerability Updated:* 2021-11-08 09:16 EST
> *CVSS Score:* {color:#FF0000}7.9{color} (overall), {color:#FF0000}8.8{color}
> (base)
> {*}Summary{*}: Apache Velocity is vulnerable to remote code execution (RCE)
> and arbitrary command execution due to how the SecureUberspector
> functionality does not sufficiently prevent access to dangerous classes and
> packages.
> An attacker with the ability to modify Velocity templates could use this
> issue to execute arbitrary Java code or system commands with the privileges
> of the account running the Servlet container.
> {*}Solution{*}: Fixed in
> [*2.3-rc1*|https://github.com/apache/velocity-engine/releases/tag/2.3-RC1] by
> [this|https://github.com/apache/velocity-engine/commit/f355cec739d4e705e541a149ff2d8806ed565401]
> commit.
> The latest stable releases are available
> [here|https://velocity.apache.org/download.cgi].
> {*}Workaround{*}: N/A
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
