Hi Daniel, Not sure about your line of thoughts :-)
My understanding * There is a recipe out there how someone can access the file system and the setup was not bad security-wise - only "?api" built-in was enabled * I think the "?api.class.getResource" and "?api.class.getResourceAsStream" can be marked as unsafe method? * I also think that ALLOWS_NOTHING_RESOLVER is not the default configuration? * I actually tried the published code and it reads my "/etc/passwd" :( If the assumptions above are correct - can this particular attack be avoided? If so we should react and improve the configuration ... Thanks in advance, Siegfried Goeschl > On 24.12.2019, at 11:50, Daniel Dekany <daniel.dek...@gmail.com> wrote: > > 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
