Re: Freemarker and security

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 ${}
A limited number of directives: <#if>, <#list>, <#assign>
A few built-ins: ?substring()
Macros
Includes, with control over paths

Disallowed:
Everything else

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




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