DTML summary: unless you configure it carefully, enabling DTML may expose you to trojan attacks on all your zope content from people who have wiki edit access. Although damn useful, it's a power feature, be sure you understand all this before you enable it on a public-writable wiki, or keep good backups. Security is your responsibility.

Cleanup needed.

security --SimonMichael, Wed, 17 Sep 2003 16:13:14 -0700 reply > The BasicFrontPage says that I need to be "aware of the issues" involved in a server-side trojan issue. It points me to many scary looking pages telling me how setting up ZWiki will cause my whole site to spontaneously combust. Question: IS THIS FIXED? And if not where is there an easy to follow HOW-TO on how to make sure my site is not vulnerable?

It doesn't exist yet; perhaps it should be at SecurityDiscussion?. It will include words to the effect of "Zwiki, currently in development status, has been developed for primarily cooperative communities and has not been security-hardened. Running a wiki with only trusted editors should not make your server any less secure than Zope itself (but Zwiki has not been audited for this). Running a fully-open wiki with non-trusted/anonymous editors makes you potentially vulnerable to DTML/javascript/HTML server trojans (details, links). Most javascript is disabled by default; you can disable DTML completely with a no_dtml property on your root folder (see ReleaseNotes). Javascript/HTML trojan abuse may still be possible after this, we don't know; the remaining level of risk is something many sites don't bother about. The default DTML configuration is still evolving. We welcome your research and documentation of the security implications of anonymous-writable zwikis. Joyful Systems is available to do this work at any time."

Good question. You're actually to first to ask it directly that I can recall..


So it seems to me, if I turn off DTML, then generally speaking, I don't have much to worry about for my server. As far as HTML, JavaScript type Trojans, what do we need to do to solve those problems? If someone can tell me about the threats, I might be able to help.


comments:

... --SimonMichael, Wed, 17 Sep 2003 19:02:45 -0700 reply

if I turn off DTML, then generally speaking, I don't have much to worry about for my server.

I need to give an official answer to that: I don't want to be misread as offering some kind of warranty that doesn't exist, or lull you into skipping backups. Many things can go wrong with a server. So I have to be conservative: it's up to you to decide what backup and security policies are sufficient for your situation and Zwiki's present state of development. I'll describe the latter as best I can, if you have more questions.

... --SimonMichael, Wed, 17 Sep 2003 19:19:49 -0700 reply
PS here's my situation: this server runs in a freebsd jail, is backed up regularly (and mirrored by google) and so is essentially disposable - I can in principle weather a total wipe of the server. There has been one minor case of persistent vandalism in five years, and no known trojan-type abuses. So for me YAGNI applies, I have no personal need for harder security right now even though I run a wide-open DTML-enabled wiki. If the site became as popular as WikiPedia that equation might change.

Search broken by no_dtml -- Thu, 18 Sep 2003 09:53:48 -0700 reply
For me, turning off DTML is the least paranoid thing I can do (I am a pretty paranoid person to begin with). I notice however, if I do this, that the search pages and the recent changes pages get broken because they have dtml in them. Any suggestions?

Search broken by no_dtml --Simon Michael, Thu, 18 Sep 2003 10:10:15 -0700 reply
Yes, that's one of the drawbacks. See the 0.22 ReleaseNotes for details of three methods you can call to get some of this functionality back (SOMEPAGE/searchwiki for example).

Search broken by no_dtml --Simon Michael, Thu, 18 Sep 2003 10:44:06 -0700 reply
TestPage has them also.

DTML policy, again --SimonMichael, Wed, 05 Nov 2003 13:38:43 -0800 reply
As a researcher and builder, I want to promote the exploration and use of "active" pages by enabling DTML by default. To review, the main problem with this is that someone can leave a dtml trojan that could theoretically delete all your zope objects next time a manager views the page. Or, if the wiki folder is owned by a low-privileged user as we recommend (but is not the case by default), then at most it could delete all objects in the wiki. But as the Zwiki userbase grows, and I find myself setting up wikis for clients, this policy is no longer suitable. Reluctantly I am feeling we must switch to never enabling DTML by default.

Basically, that's whereI have wound up. -- Wed, 05 Nov 2003 13:50:59 -0800 reply
Do not enable dtml by default. The search pages can be made uneditable, and dtml enabled. (In order to do this though, I hacked the no_dtml check to check for a boolean value instead of just it being there. This way, I could say "no_dtml" for the folder, and then on the search page, I can create a property called "no_dtml" and set it to false.) This is a 2 line hack.

Can we await non-DTML Recent Changes? --Samotnik, Wed, 05 Nov 2003 14:10:04 -0800 reply
So good, Simon, You reverted to the subject of non-DTML service pages. Some time ago I stressed security reasons not for hacers, but average users - You can't imagine their invention :).

Of the access services, the RecentChanges page is most usful. Can You or anybody translate it to non-DTML?

Can we await non-DTML Recent Changes? --SimonMichael, Wed, 05 Nov 2003 14:24:25 -0800 reply
There's a DTML, but skin-based (therefore non-editable) version in the default and plone skins: SecurityDiscussion/recentchanges . It needs more skinning work and a fix to show the right information.

Can we await non-DTML Recent Changes? --SimonMichael, Wed, 05 Nov 2003 14:29:58 -0800 reply

average users - You can't imagine their invention :).

Samotnik, you're right - and that's precisely why I'd like to have this enabled everywhere.

But, without a little more protection, leaving it enabled is just too surprising. Not now, but in the future, when Zwiki has spread and someone decides to start vandalising wikis.

prefer to have all pages the same --SimonMichael, Wed, 05 Nov 2003 14:40:10 -0800 reply

The search pages can be made uneditable, and dtml enabled.

That's what we used to do, but I fear that is too fiddly and prone to mistakes - someone will enable editing without realizing the consequence; or someone will create a child page inheriting the page type (well, I closed that hole); or someone will construct a link that, when a manager clicks it, will perform an edit on the dtml-enabled page - etc. The "everything is a page" model is simple and nice but for the default "no surprises" setup I think we have to do this functionality outside the wiki.

It is not only a question of vandalism -- Wed, 05 Nov 2003 15:56:24 -0800 reply
> in the future, when Zwiki has spread and someone decides to start vandalising wikis.

I think not only about vandalsm, i.e. intentional destroying. My test users are simply not familiar with WWW and computing. They do silly things because not concious of consequences. Samotnik

history --SimonMichael, Sat, 08 Nov 2003 22:51:12 -0800 reply
ReleaseNotesForZeroPointSix:

" deemphasised DTML-enabled content where not needed - changed pages to structuredtext where possible, restricted permissions on the rest, changed the default page type to structuredtext. MikePelletier & Jim pointed out the trojan issue (ZopeSecurityWiki:TrojanIssueOverview) to me. Zwiki by nature is of course very vulnerable to this kind of attack. So a focus of this release was to close some of the gaping holes in at least the default installation. Regretfully I changed to a non-dtml default page type (structuredtext instead of structuredtextdtml), and made most of the zwiki_examples non-dtml. Some of the default pages rely on dtml to function (recentchanges, jumpto, searchpage) so on these I disabled anonymous Change ZWiki Pages permission by default. You shouldn't be able to install a wiki with executable content without realizing it. "

Also, I had forgotten this; not sure if it still applies:

" Jim's validation patch above adds a useful safety measure: dtml code executed when viewing a zwiki page runs with the permissions of Anonymous, not the permissions of the current user. This had some ramifications for zwiki setup - anonymous Access Contents Information permission is now required on a zwiki folder for an anonymous user to view recentchanges, etc. I think the readme in zwiki_examples still needs an update here. "