It is possible to craft a MO file with Plural-Forms taking arbitrary amounts of CPU and memory to evaluate. A test case is attached.

I realize that opening unstrusted MO files is a rather unusual use case, but the module already contains some code to protect againt malicious Plural-Forms, so I thought you might want to fix this problem as well.

Thanks,

can you please provide the PO file, too? Or did you construct the MO file manually?

Ah, I see what you are doing. Nice catch!

Plural-Forms: nplurals=0; plural=42**42**42;

The plural form gets parsed by gettext.c2py() and eventually turned into a lambda that executes int(42**42**42). Perhaps a custom AST visitor could be used to filter out dangerous ops and limit the amount of ops to a sane amount?

Why do we have "support" for untrusted MO files?

I would rather ask: why do we eval() MO files?

We don't eval() the whole MO file. It's just the pluralization formula, http://www.gnu.org/software/gettext/manual/gettext.html#index-nplurals_0040r_007b_002c-in-a-PO-file-header_007d-1093

The patch uses ast.NodeVisitor to look for dangerous code.

Making token filtering more thorough may be simpler that going through AST.

I think Python should accept all the operators that GNU gettext accepts:
http://git.savannah.gnu.org/cgit/gettext.git/tree/gettext-runtime/intl/plural.y?id=v0.18.2.1#n132

Thanks for the link plural.y! I was looking for a C file, not a YACC file.

The AST approach has advantages over tokenizing. The tokenizer returns just symbols but the AST has also context information. It makes it much easier to distinguish between unary - and binary -. Gettext supports substraction but doesn't allow negative numbers.

Python's gettext is not as strict as GNU gettext. For 3.4 I like to forbid oct and hex numbers, too.

The DoS as well as other flaws is fixed in issue28563 by implementing a complete parser for GNU gettext plural form expressions.