I looked over that article as well... like Siegfried says in spite of the title of the article it started with a privilege escalation attack that was independent of FreeMarker to get access to edit templates. Because of that it also was node an injection attack, those are totally different from privilege escalation and then code (template) editing allowed by whatever admin interface was built as part of the application using FreeMarker. Daniel seems pretty confident that the current FreeMarker scripting model can be restricted sufficiently to make templates 'safe' to edit with FreeMarker running with certain settings and object wrappers. The idea would be to have FreeMarker able to run more like template engines designed specifically for this like Thymeleaf and Liquid (the one that Shopify uses for templates that run on a shared SaaS platform where script attacks through templates would be a big deal). I've always had my doubts about such things when expressions in the script or template language support anything other than data access (no direct method calls) and then only in objects in the data exposed to the template. FreeMarker already has some stuff in place for this so it might just work well (though vetting it from a security standpoint is difficult!). For my part the reason I use FreeMarker and not Thymeleaf or Liquid is that it can support things like inline method calls when you're using it for 'trusted' templates, ie you manage your templates like code in the application. Well, also things like macros and XML processing and so on that make FreeMarker useful for all sorts of things (even though those didn't exist when I first started using FreeMarker around 18 years ago). The reason I have doubts is that big groups with lots of funding, like Elastic, failed to get that really secure when using a generic scripting language like Groovy for expressions (expressions that could be specified at runtime by untrusted users, configuration allowing). Elastic eventually deprecated support for Groovy in favor of other expression languages including a custom one they built called Painless that was designed for this purpose. I originally thought there was no way FreeMarker could fully support this given the feature set it has, but thinking on it more based on some comments from Daniel it might work fine thanks to the FreeMarker object wrapping approach where you can hide all methods and unexposed fields on wrapped objects. It would still be very much a use it that way at your own risk sort of thing, especially without configuration auditing and automated tests to make sure the configuration is blocking certain types of attacks, but seems plausible while still retaining the strengths and flexibility of FreeMarker for other uses (ie templates as 'trusted' code). -David
On Dec 23 2019, at 2:55 pm, Siegfried Goeschl <[email protected]> wrote: > Hi Daniel, > > I guess I need to re-read the FreeMarker documentation and ticket - having > said that > * The problem described in the article was less about arbitrary people but > someone who hacked through other security issues to become administrator with > temple editing rights > * The people having that skills usually don't have any interest in starting a > DOS attack by messing up templates - there are more valuable things out there > ... > * I think it is pretty much impossible to make FreeMarker 100% bullet proof > (tons of features, a lot of code, arbitrary libraries coming from the > application) but at least we can check that this attack does not work any > longer > * From my understanding - usually there a couple of security vulnerabilites > leading to complete data breach :-) > > Thanks in advance, > Siegfried Goeschl > > > On 23.12.2019, at 22:30, Daniel Dekany <[email protected]> wrote: > > Hi, > > In short, allowing untrusted users to edit templates is not supported. But, > > since people do it anyway, 2.3.30 will make an effort to allow doing that > > with taking far less risk than what people take now. The MemberAccessPolicy > > feature committed in recent days is the start of that. Actually, you could > > always just use SimpleObjectWrapper (as the FAQ states), but clearly that's > > too limiting for what many (most?) people use FreeMarker for. But anyway, I > > don't believe that a template engine with the complexity of FreeMarker will > > be ever a good fit for applications where random people can edit templates. > > If users are accountable in real life for what they did, like they are > > employees at the client, then probably it will be good enough, but not for > > use cases where anyone can edit templates. If nothing else, you will be too > > easily DOS-able then. > > > > As of the blog entry, see this: > > https://issues.apache.org/jira/browse/FREEMARKER-124 > > Here I would add that it's likely that the calls used in the blog entry > > won't work anymore in 2.3.30. I'm a bit uneasy about that, as it's a > > backward compatibility risk (it won't be just blocking that single method), > > while it doesn't provide real security. You need a whitelist of what's > > allowed for that (as opposed to a blacklist), and that's possible to do > > with MemberAccessPolicy, but I will also provide an implementation to help > > doing that. > > > > Also, in the FAQ: > > https://freemarker.apache.org/docs/app_faq.html#faq_template_uploading_security > > > > > > On Mon, Dec 23, 2019 at 7:25 PM Siegfried Goeschl < > > [email protected]> wrote: > > > > > Hi folks, > > > During my last presentation I was asked about how secure Apache Freemarker > > > is in the context of user editing their templates - well, hard to say > > > without knowing the application. > > > > > > But I came across an interesting article (see > > > https://ackcent.com/blog/in-depth-freemarker-template-injection/) where > > > the authors successfully hacked a CMS based on Apache FreeMarker > > > > > > * As far as I know the UNRESTRICTED_RESOLVER is the default? Maybe > > > ALLOWS_NOTHING_RESOLVER would be a better default? > > > * Enabling "?api" needs to be enabled by developers which is fine > > > * Update the "unsafeMethods.properties" according to the article? For the > > > records "java.lang.Thread.suspend()" is duplicated anyway > > > > > > Thanks in advance, > > > Siegfried Goeschl > > > > > > > -- > > Best regards, > > Daniel Dekany > >
