7:43 p.m.
Hello,
in the process of writing a translation plugin[1] for ikiwiki[2],
using po4a, we wondered how safe it was to run po4a on
untrusted content. Hence the following questions.
(You might need to know, in order to provide an accurate answer, that
we actually don't use /usr/bin/po4a* at all, but rather the
Locale::Po4a Perl module.)
Was po4a designed with "processing safely on untrusted content" as
a goal? If not, do you consider it is now achieved as a side effect?
About the external dependencies:
- I could not find any command execution in Locale::Po4a, did I miss
some?
- The first glance makes me think that Locale::gettext is used only to
display translated messages; can you please confirm this?
- Amongst the dependencies (I could quickly list DynaLoader, Encode,
Encode::Guess, Text::WrapI18N, Locale::gettext), is there one (or
more) that you know to be unsafe to process untrusted content?
- What about the msgmerge command, that po4a command-line programs
use, as well as this ikiwiki plugin?
Was the full code checked for symlink attacks when CVE-2007-4462
was fixed?
Was po4a tested with a fuzzing program? Would you be interested in the
results if I did this?
[1] http://ikiwiki.info/plugins/contrib/po/
[2] http://ikiwiki.info
Bye,
--
intrigeri <intrigeri(a)boum.org>
8:08 a.m.
New subject: [Po4a-devel] po4a against untrusted content
Hello,
On Sat, Nov 08, 2008 at 02:43:15AM +0100, intrigeri(a)boum.org wrote:
Hello,
in the process of writing a translation plugin[1] for ikiwiki[2],
using po4a, we wondered how safe it was to run po4a on
untrusted content. Hence the following questions.
(You might need to know, in order to provide an accurate answer, that
we actually don't use /usr/bin/po4a* at all, but rather the
Locale::Po4a Perl module.)
Was po4a designed with "processing safely on untrusted content" as
a goal? If not, do you consider it is now achieved as a side effect?
"processing safely on untrusted content" was not an original goal.
However, I would like to differentiate parts of po4a:
* The po4a's Core (Po.pm, Transtractor.pm)
I really do not expect any security issues in the core
functionalities. They should only use simple and static regular
expressions and standard Perl features.
I don't think there are any implicit requirements on the inputs
provided to the core by the modules or by the PO file parser.
* The po4a's modules
The modules are parsing the "untrusted content", the behavior of the
modules might be changed by commands included in the content (LaTeX
module only?), they might use some unstrusted content later in a
regular expression.
The module usually do not have any interface to the system (like
reading or writing files, executing commands), but use the
Transtractor interface for this.
* The po4a commands
They are also parsing untrusted content (command line arguments, config
files) and have more interfaces to the system.
* The po4a's testsuite
Not developed with security in mind.
About the external dependencies:
- I could not find any command execution in Locale::Po4a, did I miss
some?
I'm not sure what you mean with "command execution"
If it's about external system's program, then there are some (look for
system, qx, open, or `):
diff might be used by Po.pm
nsgmls is used by Sgml.pm
- The first glance makes me think that Locale::gettext is used only
to
display translated messages; can you please confirm this?
That's right.
- Amongst the dependencies (I could quickly list DynaLoader, Encode,
Encode::Guess, Text::WrapI18N, Locale::gettext), is there one (or
more) that you know to be unsafe to process untrusted content?
I had some failure with WrapI18N (endless loops), which might cause DOS.
http://bugs.debian.org/470250
It is just used to have a better formating of the output error/warning
mesages.
You probably do not need this feature.
I hope DynaLoader is safe.
I have no reason to think that Encode::Guess is not safe. It can also be
avoided if the encoding is always specified. (This might need some
adaptation in po4a to only load it if needed)
I have no reason to think that Encode is not safe.
Other non-required dependencies:
Term::ReadKey
SGMLS
They are not dependencies for your use case.
- What about the msgmerge command, that po4a command-line programs
use, as well as this ikiwiki plugin?
I never checked them. I've never hearded about any security issues with
msgmerge. It is a known and widely used command.
It uses the gettext library which is already checking the format
of its content.
I do not expect any security issues from it.
It is not used by Locale::Po4a, but by the po4a command lines. However,
I expect that you will have to use them.
Was the full code checked for symlink attacks when CVE-2007-4462
was fixed?
Yes, except the testsuite.
Was po4a tested with a fuzzing program? Would you be interested in
the
results if I did this?
It was not tested, and it would be really appreciated.
A first step, and the most interesting thing for you would be to test the
core functionalities.
I expect more trouble with the modules (endless loops)
Thanks for your interest,
--
Nekral
1:01 p.m.
New subject: [Po4a-devel] po4a against untrusted content
Hello,
Nicolas François wrote (08 Nov 2008 14:08:13 GMT) :
* The po4a's modules
The modules are parsing the "untrusted content", the behavior of the
modules might be changed by commands included in the content (LaTeX
module only?), they might use some unstrusted content later in a
regular expression.
The module usually do not have any interface to the system (like
reading or writing files, executing commands), but use the
Transtractor interface for this.
I'll check the Text module for similar problems, and report back.
If it's about external system's program, then there are some
(look for
system, qx, open, or `):
diff might be used by Po.pm
nsgmls is used by Sgml.pm
Being more or less a Perl newbie, I did not grep'ed for qx.
Seems the core only runs diff. We use neither write_if_needed() nor
move_po_if_needed() yet, so this will have to be checked if we start
using them at some point.
I had some failure with WrapI18N (endless loops), which might cause
DOS.
http://bugs.debian.org/470250
It is just used to have a better formating of the output error/warning
mesages.
You probably do not need this feature.
I'll try to disable its use, and report back.
I have no reason to think that Encode::Guess is not safe. It can also
be
avoided if the encoding is always specified. (This might need some
adaptation in po4a to only load it if needed)
I'll try to prevent this module to be used, and report back.
Other non-required dependencies:
Term::ReadKey
SGMLS
They are not dependencies for your use case.
I'll try to disable their use, and report back.
It is not used by Locale::Po4a, but by the po4a command lines.
However, I expect that you will have to use them.
I did not use them, but found inspiration in there, hence the use of
msgmerge to refresh the PO files.
(no need to Cc: me, I'm now on the list :)
Thanks, Nicolas, for your detailed answer.
Bye,
--
intrigeri <intrigeri(a)boum.org>
2:27 p.m.
New subject: [Po4a-devel] po4a against untrusted content
Hello,
On Sat, Nov 08, 2008 at 08:01:28PM +0100, intrigeri(a)boum.org wrote:
Nicolas François wrote (08 Nov 2008 14:08:13 GMT) :
> * The po4a's modules
> The modules are parsing the "untrusted content", the behavior of the
> modules might be changed by commands included in the content (LaTeX
> module only?), they might use some unstrusted content later in a
> regular expression.
> The module usually do not have any interface to the system (like
> reading or writing files, executing commands), but use the
> Transtractor interface for this.
I'll check the Text module for similar problems, and report back.
Note: the Text module had significant changes since the last release.
Please use the CVS version.
(CVS adds support for asciidoc)
> I had some failure with WrapI18N (endless loops), which might
cause DOS.
> http://bugs.debian.org/470250
> It is just used to have a better formating of the output error/warning
> mesages.
> You probably do not need this feature.
I'll try to disable its use, and report back.
Currently, it is used if present.
It should thus be easy to add an option to always disable it.
> Other non-required dependencies:
> Term::ReadKey
> SGMLS
> They are not dependencies for your use case.
I'll try to disable their use, and report back.
It makes me think that for the usage in a ikiwiki module, you may have to
change the change the way errors and warning are reported.
(Term::ReadKey is used to get the size of the terminal to format the
warnings)
Best Regards,
--
Nekral
6:22 a.m.
New subject: [Po4a-devel] po4a against untrusted content
Hello,
Nicolas François wrote (08 Nov 2008 20:27:22 GMT) :
> > I had some failure with WrapI18N (endless loops), which
might cause DOS.
> > http://bugs.debian.org/470250
> > It is just used to have a better formating of the output error/warning
> > mesages.
> > You probably do not need this feature.
>
> I'll try to disable its use, and report back.
Currently, it is used if present.
It should thus be easy to add an option to always disable it.
Well, Joey came up with a patch (see below) that adds a nowrapi18n
option to Locale::Po4a::Common, but I now realize it's not enough, as
almost every po4a module runs its own 'use Locale::Po4a::Common;'.
I guess the "obvious" solution (i.e. adding support in every module
for the nowrapi18n option Joey implemented) is not desirable.
Any other idea?
Here are Joey comments, and his patch:
That doesn't really need to be in a BEGIN. This patch moves it
to
`import`, and makes this disable wrap18n:
`use Locale::Po4a::Common q{nowrapi18n}` --[[Joey]]
<patch>
--- /usr/share/perl5/Locale/Po4a/Common.pm 2008-07-21 14:54:52.000000000 -0400
+++ Common.pm 2008-11-11 18:27:34.000000000 -0500
@@ -30,8 +30,16 @@
use strict;
use warnings;
-BEGIN {
- if (eval { require Text::WrapI18N }) {
+sub import {
+ my $class=shift;
+ my $wrapi18n=1;
+ if ($_[0] eq 'nowrapi18n') {
+ shift;
+ $wrapi18n=0;
+ }
+ $class->export_to_level(1, $class, @_);
+
+ if ($wrapi18n && eval { require Text::WrapI18N }) {
# Don't bother determining the wrap column if we cannot wrap.
my $col=$ENV{COLUMNS};
</patch>
Bye,
--
intrigeri <intrigeri(a)boum.org>
| gnupg key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| So what?
12:52 p.m.
New subject: [Po4a-devel] po4a against untrusted content
On Wed, Nov 12, 2008 at 01:22:24PM +0100, intrigeri(a)boum.org wrote:
Hello,
Well, Joey came up with a patch (see below) that adds a nowrapi18n
option to Locale::Po4a::Common, but I now realize it's not enough, as
almost every po4a module runs its own 'use Locale::Po4a::Common;'.
I guess the "obvious" solution (i.e. adding support in every module
for the nowrapi18n option Joey implemented) is not desirable.
It also has the advantage of being simple.
How do you want to use this feature:
From ikiwiki, you load the Text module with this option, and the
option
is forwarded to Common.
From the command line tools, Chooser is loaded, and no option is
specified, no changes are needed.
This means that from all module, we need to change:
use Locale::Po4a::Common;
to:
use Locale::Po4a::Common $_;
(It might be obvious that I did not test this at all ;)
If the idea is something like that, it seems good, and could be re-used
for other features.
Any other idea?
Common is currently very command-line oriented.
It might be possible to create another Common.pm
It might also be possible to check if po4a is running on a terminal or
not. (I think it won't be when run by ikiwiki)
Cheers,
--
Nekral
11:12 a.m.
New subject: [Po4a-devel] po4a against untrusted content
Hi,
(sorry not to answer to Nicolas' last email, and to somehow break the
thread... I deleted it by accident.)
intrigeri wrote (12 Nov 2008 12:22:24 GMT) :
Well, Joey came up with a patch (see below) that adds a nowrapi18n
option to Locale::Po4a::Common, but I now realize it's not enough, as
almost every po4a module runs its own 'use Locale::Po4a::Common;'.
I guess the "obvious" solution (i.e. adding support in
every module
for the nowrapi18n option Joey implemented) is not desirable.
I've tried for hours to implement Nicolas' suggestion, i.e. to forward
nowrapi18n option from every module to Locale::Po4a::Common; this
seems impossible to achieve, given the nested/circular dependency
network that currently exists between all Locale::Po4a::* modules;
implementing this would imply to have every module forward this option
to any other module it is use'ing, which ends up with a quite long and
ugly diff, and still, I did not manage to make it work as wanted.
I've therefore chosen a far simpler solution, still based on Joey's
proposed patch: the first time Locale::Po4a::Common is loaded
determines whether Text::WrapI18N is used.
As explained in the pod my patch adds, the one who wants to use
Locale::Po4a programmatically *and* disable the use of Text::WrapI18N
must write e.g.
use Locale::Po4a::Common qw(nowrapi18n);
use Locale::Po4a::Text;
instead of:
use Locale::Po4a::Text;
This is far from being a perfect solution, but it is less invasive
and... it works.
This is implemented in the first attached patch against CVS head,
namely: 0001-Common.pm-support-a-nowrapi18n-option.patch
Side note: as this works around #470250, and fixes a security issue
(exposed by my ikiwiki plugin use case), is it realistic to get
something based on this patch into Lenny? I would happily provide the
same patch against the po4a package currently in Lenny.
I also implemented another of Nicolas' suggestions, i.e. to disable
Text::WrapI18N use unless the module is used from a program running on
an interactive terminal. This is:
0002-Common.pm-do-not-use-wrapi18n-unless-running-on-an-interactive-terminal.patch
It's unfortunately not sufficient for ikiwiki needs, as ikiwiki
sometimes runs on interactive terminals, e.g.
when ikiwiki-mass-rebuild is invoked by dpkg in postinst. And you
really don't want your dpkg upgrade to be frozen inside an infinite
loop, due to weird content having been checked into whatever wiki
you're hosting two months ago. That's why the first patch is needed
as well.
Bye,
--
intrigeri <intrigeri(a)boum.org>
| gnupg key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| The impossible just takes a bit longer.
5:15 p.m.
New subject: [Po4a-devel] po4a against untrusted content
Hi,
Thanks for the 2 patches (and the documentation). I committed them.
I made a change in the second one. I don't think there is a need for
checking if STDIN is a terminal, so I removed this test, and I added a
test for STDERR.
(the re-wrapped messages are usually sent to STDERR, so this STDERR check
is probably more important than STDOUT).
On Thu, Jan 15, 2009 at 06:12:58PM +0100, intrigeri(a)boum.org wrote:
Side note: as this works around #470250, and fixes a security issue
(exposed by my ikiwiki plugin use case), is it realistic to get
something based on this patch into Lenny? I would happily provide the
same patch against the po4a package currently in Lenny.
If #470250 is really a security issue (DOS, right?), I would prefer
libtext-wrapi18n-perl to be fixed. This would also provide a fix for
non-programmatic usage of the Locale::Po4a library and even usage of
libtext-wrapi18n-perl outside of po4a.
Do you think this should be raised to the security team and release team?
Best Regards,
--
Nekral
9:40 p.m.
New subject: [Po4a-devel] po4a against untrusted content
Hi,
Nicolas François wrote (15 Jan 2009 23:15:19 GMT) :
Thanks for the 2 patches (and the documentation). I committed them.
Thanks. My ikiwiki po plugin now disables the use of Text::WrapI18n,
if the installed po4a version is recent enough (currently means: CVS).
On Thu, Jan 15, 2009 at 06:12:58PM +0100, intrigeri(a)boum.org wrote:
>
> Side note: as this works around #470250, and fixes a security issue
> (exposed by my ikiwiki plugin use case), is it realistic to get
> something based on this patch into Lenny? I would happily provide the
> same patch against the po4a package currently in Lenny.
If #470250 is really a security issue (DOS, right?), I would prefer
libtext-wrapi18n-perl to be fixed. This would also provide a fix for
non-programmatic usage of the Locale::Po4a library and even usage of
libtext-wrapi18n-perl outside of po4a.
I obviously would prefer this too. But last time I checked, your
proposed patch had received no answer from
libtext-wrapi18n-perl maintainer.
Do you think this should be raised to the security team and
release team?
I'm not familiar enough with Debian security process to know how
seriously this potential denial of service would be taken by
these teams, in particular at a time when testing is frozen and
release is imminent (yeah).
$ apt-cache rdepends libtext-wrapi18n-perl
libtext-wrapi18n-perl
Reverse Depends:
po4a
po4a
module-assistant
docbook2x
debconf-i18n
On the one hand, module-assistant and debconf-i18n are often, or
usually, run with root credentials. On the other hand, they are run
against input data that has been uploaded into Debian, and thus can be
considered as somehow trusted... else you've got harder problems
to solve.
docbook2x commands may be run by a user against untrusted data.
This package has no reverse dependencies. I can not think of
a situation where one would need to run them as root against untrusted
data, especially in an automated, non-interactive way, so it seems to
me the worse that can happen is having to hit Ctrl-C after a few
minutes lost waiting for the infinite loop to eventually end.
As a conclusion, my non-DD opinion on this topic is: this bug should
be fixed in Lenny, and thus deserves a NMU (if needed) and a freeze
exception, but a DSA would probably be a bit too much.
Bye,
--
intrigeri <intrigeri(a)boum.org>
| gnupg key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| If you must label the absolute, use it's proper name: Temporary.
6085
days inactive
6157
days old
8 comments
2 participants
participants (2)
-
intrigeri -
Nicolas François