Re: Freemarker and security

Thursday, December 9, 2010, 7:46:42 PM, Chris wrote:

> On 12/9/2010 5:11 AM, Daniel Dekany wrote:
>> Thursday, December 9, 2010, 4:47:28 AM, Chris wrote:
>>
>>> We're building an app where untrusted users will be able to create their
>>> own templates. This is a website where users will be able to create
>>> their own websites in a shared environment. The different sites will
>>> share a JVM.
>>>
>>> What are the security risks?
>>
>> I told for several occasions here that FTL (like almost any other
>> template language) was designed to be the part of the application
>> source code, so from a stricter security standpoint it's as dangerous
>> as Java code. And when it comes to security, you should be paranoid,
>> so even without looking into details, I would never dare to let
>> visitors upload templates. Unless of course I can also properly
>> "sandbox" arbitrary Java code they upload, because FreeMarker can only
>> do less...
>>
>>> I looked through the Freemarker template language and did not find much
>>> of concern, though I'm a bit leery of the ways that users might be able
>>> to invoke Java code.
>>
>> There are some ways to do that, if a users really wants that...
>>
>> - The ?new feature, while it only allows the instantiation of
>>    TemplateModel-s, is still very dangerous. In 2.3.17 there will be a
>>    setting to regulate what one can do with ?new, but until that do NOT
>>    ever let potentially malicious users to upload any templates unless
>>    you patch FreeMarker to only allow a fixed list of classes to be
>>    instantiated with ?new. I'm not kidding. Never ever allow that! To
>>    prevent FUD, this is only a concern if somebody lets untrusted
>>    users to upload templates (which is already quite a risk).
>>
>> - The data-model... depends on what ObjectWrapper are you using, but
>>    with BeansWrapper and its sub-classes (like the
>>    DefaultObjectWrapper!), you can access all public methods (with
>>    the default setting at least) and JavaBean properies of the exposed
>>    object. That's so by design of course. When programmers develop the
>>    API-s of the objects, they certainly won't always consider "what if
>>    this is called from a template that wasn't written by us".
>>
>>> Can anyone point to specific risks or holes we need to look out for?
>>
>> Apart from the access to Java objects/classes described above:
>>
>> - It's quite easy to implement DOS attacks... just create a sufficiently
>>    long loop, or build a huge string in a loop.
>>
>> - The paths specified for #import/#include can possibly reach files
>>    that they should not. It depends on the concrete TemplateLoader-s
>>    used, but some might can be tricked with tricky paths (like with an
>>    escaping that FM doesn't understand but the mechanism for which
>>    the TemplateLoader implementation is an adapter for does). Again,
>>    the issue is that not even the core TemplateLoader-s were ever
>>    professionally reviewed from security standpoint. They certainly
>>    protect you well against accidents, but against hackers... I
>>    wouldn't trust them. Unless, of course, you write your own
>>    TemplateLoader that was carefully designed that way, do some extra
>>    checks, etc.
>>
>>> Any advice on how to lock it down so users won't be able to do any
>>> damage outside the context of their own template?
>>
>> I don't believe that using *any* non-trivial template language that
>> wasn't designed especially for this is kind of thing is a wise idea,
>> assuming your users can be malicious. Except, if you can somehow
>> sandbox the templates on a lower level, as I said. User-written
>> FreeMarker templates are certainly fine if the worst the users can do
>> is hacking his/her own computer (i.e. when templates run on the
>> client)... but when they run on the server... I can (and will) fix
>> ?new etc, but it never will be safe enough for me to allow arbitrary
>> users to upload them. It's just too big, and wasn't designed for that.
>>
>
> Understood. I wonder if it would be possible to implement a subset of 
> Freemarker functionality, maybe by forking the Freemarker code?
>
> Allowed:
> Referencing data models using ${}

And most importantly, use some dead-simple ObjectWrapper.

> A limited number of directives: <#if>, <#list>, <#assign>
> A few built-ins: ?substring()
> Macros
> Includes, with control over paths

The #imports/#include-s you can control with a custom TemplateLoader
(Configuration.setTemplatLoader). (This is only fine as far as all
templates need the same permissions...)

> Disallowed:
> Everything else

There is still the case of DOS attacks, however. /-: Avoiding that
would be at best tricky even in a new template language that was
designed exactly for this... but some kind of
maximum-AST-nodes-executed limit might would work.

> Is there a parser class somewhere that could be modified so that other
> kinds of constructs simply aren't recognized?

FreeMarker uses JavaCC, so yes, there is.

-- 
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------