You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Claude Brisson (Jira)" <ji...@apache.org> on 2021/02/25 22:35:00 UTC
[jira] [Resolved] (VELOCITY-931) SecureUberspector should block
methods on ClassLoader and subclasses
[ https://issues.apache.org/jira/browse/VELOCITY-931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claude Brisson resolved VELOCITY-931.
-------------------------------------
Resolution: Fixed
Merged un master.
> SecureUberspector should block methods on ClassLoader and subclasses
> --------------------------------------------------------------------
>
> Key: VELOCITY-931
> URL: https://issues.apache.org/jira/browse/VELOCITY-931
> Project: Velocity
> Issue Type: Improvement
> Reporter: William Glass-Husain
> Assignee: William Glass-Husain
> Priority: Major
> Fix For: 2.3
>
>
> Currently, SecureUberspector matches classes stored with property "introspector.restrict.classes", which includes ClassLoader. It then matches exact class names and blocks all methods from being called on that class.
> However, in most cases it's actually a subclass of ClassLoader that's available in the context, which under normal circumstances would not be blocked.
> My proposal – treat this as a special case. (Remove it from the configuration). If the class being inspected is assignable from ClassLoader, then block it.
> You could make an argument that all the SecureUberspector should check if the class isAssignable from all configured classes, but I am concerned about possible performance penalties. I'd argue that we should hard code checks for a few special internal classes but force the user to configure other specific classes themselves.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org