The blog entry might starts its case with a privilege escalation independent of FreeMarker, but the question you got during your presentation wasn't about that, I think. But more importantly, some real world applications do allow editing templates for users who aren't necessarily some kind of superusers. Right now, after they realized that the problem exists at all, they will have to figure out a solution themselves. We are in a much better position to do the same.
DOS-ing is certainly less of a concern in general, though unintentional DOS-ing (or I guess unintentional) was a problem for try.freemarker.apache.org in the past. My point there is just that if really everyone from the Internet can edit templates, then it will be a problem, I guess for any practical template language. On Mon, Dec 23, 2019 at 11:55 PM Siegfried Goeschl < siegfried.goes...@gmail.com> 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 <daniel.dek...@gmail.com> 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 < > > siegfried.goes...@gmail.com> 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 > > -- Best regards, Daniel Dekany
