Re: Freemarker and security

Daniel Dekany <[email protected]>
Newsgroups gmane.comp.web.freemarker.user
Message-ID <[email protected]>
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.

-- 
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
This SF Dev2Dev email is sponsored by:

WikiLeaks The End of the Free Internet
http://p.sf.net/sfu/therealnews-com
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.