• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

After filing Item1261 it occured to me that the code handling the MAKETEXT variable could do with a hardening to prevent DOS attacks on a TWiki installation with a I18N setup.


1) In LocalSite.cfg, set these variables:

$TWiki::cfg{UseLocale} = 1;
$TWiki::cfg{UserInterfaceInternationalisation} = 1;

2) Insert this content on a page:

%MAKETEXT{1-2-3 testing DOS}%

(proper format would be %MAKETEXT{"1-2-3 testing DOS"}% or %MAKETEXT{string="1-2-3 testing DOS"}%).

3) Try to save the page (server will not return, but enter an infinite loop)

4) killall view smile


The input is not malformed. This appears to be a perl bug.

When the string "1-2-3 testing dos" is fed to the Locale::Maketext::Guts::_compile method, the \G modifier on the RE is supposed to return each unique token in turn - i.e. it should return "1-2-3 testing done" once. However when called in the context of a view, it continuously returns the whole string. I can't reproduce this outside of TWiki, and if I enable debugging in Guts the problem goes away.

Anyone got any ideas?


I could reproduce this, and discovered that:

  string tranlated string not translated
"well-formed" string¹ does not loop does not loop
not "well-formed" string does not loop loops

¹ i.e. it is double-quoted, like "translate it" or string="translate it"

So, it looks like those "malformed" strings make TWiki loops if they are not translated. I need to investigate a little bit more.

Those "malformed" strings aren't translated because TWiki::I18N::Extract didn't catch %MAKETEXT{unquoted}% in code.


"Malformed input" is bad choice of wording, that's not what this is about, I agree.

I want to emphasize in this bug report, that is only when both variables in LocalSite.cfg are enabled, the problem occurs. Leaving one or the other disabled and you won't see the bug (..?).

$TWiki::cfg{UseLocale} = 1;
$TWiki::cfg{UserInterfaceInternationalisation} = 1;

To others: There's some discussion on this issue in IRC.


My problem is that for me, this only occurs when the MAKETEXT's parameter is not quoted. But, it does not make any sense! We still need to track this issue.

And, SP, that is definitely related to the I18N framework, we're conscious of that. smile


I tracked it back to the Attrs module. There was some suspect code there, which I changed slightly; and when I did, it stopped hanging. I am sure this is a perl bug, and am continuing to try and isolate it. Please let me know if the problem is seen again.

SVN 8066


Seems like it's back on track alright - pure perl voodoo in action smile

In just a few days I'll probably be able to stop wondering how the Attrs bug was related to enabling I18N / L10N *g*. Thanks for fixing!


thank you, CC !


Summary Malformed input in MAKETEXT variable on I18N-enabled installation allows for DOS attack
ReportedBy SteffenPoulsen

SVN Range Tue, 27 Dec 2005 build 7999
AppliesTo Engine

Priority Urgent
CurrentState Closed

Checkins 8031 8066
Edit | Attach | Watch | Print version | History: r11 < r10 < r9 < r8 < r7 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r11 - 2006-01-02 - AntonioTerceiro
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback