[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: textdomain.rb Security Error - Insecure operation - exist?

From: boud
Subject: Re: textdomain.rb Security Error - Insecure operation - exist?
Date: Sat, 3 Feb 2007 22:19:52 +0100 (CET)

hi dmitry,

On Sat, 3 Feb 2007, Dmitry Borodaenko wrote:


Many thanks for this report! In fact, this particular error is the one
that made me lose my patience and implement the improved error
reporting, so that we would finally be able to nail it down :)

The only problem with error reporting now is that some error reports
go to ErrorLog file defined in vhost and some error reports go to the main apache error.log file. The former is a problem for security
reasons (ip logging), the latter is a problem because it gets mixed
up with the error messages of other programs using apache.

Also, people who don't have root access to a system might not be able
to read the general apache error log file.

In engine/helpers.rb it looks like the log(msg) method says that
errors go to $stderr and i guess it's apache (or higher up, the script that
starts apache) who decides what $stderr is.

Would there be any sense in giving the sysadmin an option in defaults.yaml
to define something like

errorlog: '/var/log/samizdat/error.log'

and setting   $stderr= config['errorlog']  ?

i guess this would create the problem of general system maintenance which is that the install (e.g. debian install) should also add a logrotate script in order to not fill up the whole disk with error messages.

Anyway, back to the gettext bug topic.

I don't think fiddling with cache.rb will help: language_list() is
never cached (probably should be, I wonder how much performance will
it gain us). Besides, Samizdat never passes tainted data to
bindtextdomain(), it validates and untaints it. This means the data
got mysteriously re-tainted somewhere in GetText or even deeper in
Ruby itself.

I didn't look deeper into the GetText from Debian/stable (which will
very soon become old-stable anyway), but I suspect that untainting the
file name isn't very safe from security point of view. If you can
replicate this bug (I couldn't catch it), try to find which of the
components of that File.join() is tainted, and only untaint it if
you're sure it only contains safe characters.

My hypothesis at the moment is that locale may be taken from an
environment variable, e.g. although i can guess what "||=" means,
i haven't found it in the

  def bindtextdomain(domainname, path = nil, locale = nil, charset = nil)
    locale ||= Locale.get
    charset ||= ENV["OUTPUT_CHARSET"] ? ENV["OUTPUT_CHARSET"] : Locale.codeset

In any case, here's my hack to test this.  i'm not sure how much
locale is forced to be a 2 (or sometimes 3) letter code, or whether
it's a full description like pl_PL.UTF-8 . This particular check
should reset to "en" for anything other than a 2(3) letter code.  If i
(and others) don't see the bug again during the next few weeks, then
maybe we'll be one step closer to it. :)

i found one way to force identical error messages to the "naturally
occurring bug" is to put   locale.taint   in gettext/textdomain.rb:

        fname = File.join(dir, locale.taint, "LC_MESSAGES", @name + ".mo")

but in principle it could also be dir or @name. This certainly reproduces
the effect of the bug.

Anyway, this is my present hack:

--- gettext/textdomain.rb_0.8.0-1       2007-02-03 21:11:23.660880816 +0100
+++ gettext/textdomain.rb       2007-02-03 21:11:37.116835200 +0100
@@ -134,7 +134,9 @@
       @locale_dirs.each do |dir|
-        fname = File.join(dir, locale, "LC_MESSAGES", @name + ".mo")
+#        fname = File.join(dir, locale, "LC_MESSAGES", @name + ".mo")
+        locale = "en" if (locale =~ /^[a-z][a-z][a-z]?$/) == nil  # check on 
+        fname = File.join(dir, locale.untaint, "LC_MESSAGES", @name + ".mo") # 
locale.untaint 03.02.2007
         @search_files << fname
         if File.exist?(fname)
           @mo =, @charset)

I didn't look deeper into the GetText from Debian/stable (which will
very soon become old-stable anyway), but I suspect that untainting the

If it's solved in more recent versions of gettext, that's fine, but
for the moment we have this bug in gettext-1.7.0-1 to solve:

BTW, i've start a bugs page linked from the main docs.indy page:

For the moment we presumably have few enough developers and bug reports
to do this through a wiki - i don't have the experience to say whether
this or something like bugzilla or another bug-reporting system would
be better. For me, the wiki is fine.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]