doc/plugins/po/discussion.mdwn

   1 [[!toc ]]
   2
   3 ----
   4
   5 # Security review
   6
   7 ## Probable holes
   8
   9 _(The list of things to fix.)_
  10
  11 ### po4a-gettextize
  12
  13 * po4a CVS 2009-01-16
  14 * Perl 5.10.0
  15
  16 `po4a-gettextize` uses more or less the same po4a features as our
  17 `refreshpot` function.
  18
  19 Without specifying an input charset, zzuf'ed `po4a-gettextize` quickly
  20 errors out, complaining it was not able to detect the input charset;
  21 it leaves no incomplete file on disk. I therefore had to pretend the
  22 input was in UTF-8, as does the po plugin.
  23
  24         zzuf -c -s 13 -r 0.1 \
  25             po4a-gettextize -f text -o markdown -M utf-8 -L utf-8 \
  26              -m GPL-3 -p GPL-3.pot
  27
  28 Crashes with:
  29
  30         Malformed UTF-8 character (UTF-16 surrogate 0xdfa4) in substitution
  31         iterator at /usr/share/perl5/Locale/Po4a/Po.pm line 1449.
  32         Malformed UTF-8 character (fatal) at /usr/share/perl5/Locale/Po4a/Po.pm
  33         line 1449.
  34
  35 An incomplete pot file is left on disk. Unfortunately Po.pm tells us
  36 nothing about the place where the crash happens.
  37
  38 > It's fairly standard perl behavior when fed malformed utf-8. As long
  39 > as it doesn't crash ikiwiki, it's probably acceptable. Ikiwiki can
  40 > do some similar things itself when fed malformed utf-8 (doesn't
  41 > crash tho) --[[Joey]]
  42
  43 ----
  44
  45 ## Potential gotchas
  46
  47 _(Things not to do.)_
  48
  49
  50 ### Blindly activating more po4a format modules
  51
  52 The format modules we want to use have to be checked, as not all are
  53 safe (e.g. the LaTeX module's behaviour is changed by commands
  54 included in the content); they may use regexps generated from
  55 the content.
  56
  57 ----
  58
  59 ## Hopefully non-holes
  60
  61 _(AKA, the assumptions that will be the root of most security holes...)_
  62
  63 ### PO file features
  64
  65 No [documented](http://www.gnu.org/software/gettext/manual/gettext.html#PO-Files)
  66 directive that can be put in po files is supposed to cause mischief
  67 (ie, include other files, run commands, crash gettext, whatever).
  68
  69 ### gettext
  70
  71 #### Security history
  72
  73 The only past security issue I could find in GNU gettext is
  74 [CVE-2004-0966](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0966),
  75 *i.e.* [Debian bug #278283](http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=278283):
  76 the autopoint and gettextize scripts in the GNU gettext package (1.14
  77 and later versions) may allow local users to overwrite files via
  78 a symlink attack on temporary files.
  79
  80 This plugin would not have allowed to exploit this bug, as it does not
  81 use, either directly or indirectly, the faulty scripts.
  82
  83 Note: the lack of found security issues can either indicate that there
  84 are none, or reveal that no-one ever bothered to find or publish them.
  85
  86 #### msgmerge
  87
  88 `refreshpofiles()` runs this external program.
  89
  90 * I was not able to crash it with `zzuf`.
  91 * I could not find any past security hole.
  92
  93 #### msgfmt
  94
  95 `isvalidpo()` runs this external program.
  96
  97 * I was not able to make it behave badly using zzuf: it exits cleanly
  98   when too many errors are detected.
  99 * I could not find any past security hole.
 100
 101 ### po4a
 102
 103 #### Security history
 104
 105 The only past security issue I could find in po4a is
 106 [CVE-2007-4462](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4462):
 107 `lib/Locale/Po4a/Po.pm` in po4a before 0.32 allowed local users to
 108 overwrite arbitrary files via a symlink attack on the
 109 gettextization.failed.po temporary file.
 110
 111 This plugin would not have allowed to exploit this bug, as it does not
 112 use, either directly or indirectly, the faulty `gettextize` function.
 113
 114 Note: the lack of found security issues can either indicate that there
 115 are none, or reveal that no-one ever bothered to find or publish them.
 116
 117 #### General feeling
 118
 119 Are there any security issues on running po4a on untrusted content?
 120
 121 To say the least, this issue is not well covered, at least publicly:
 122
 123 * the documentation does not talk about it;
 124 * grep'ing the source code for `security` or `trust` gives no answer.
 125
 126 On the other hand, a po4a developer answered my questions in
 127 a convincing manner, stating that processing untrusted content was not
 128 an initial goal, and analysing in detail the possible issues.
 129 The following analysis was done with his help.
 130
 131 #### Details
 132
 133 * the core (`Po.pm`, `Transtractor.pm`) should be safe
 134 * po4a source code was fully checked for other potential symlink
 135   attacks, after discovery of one such issue
 136 * the only external program run by the core is `diff`, in `Po.pm` (in
 137   parts of its code we don't use)
 138 * `Locale::gettext` is only used to display translated error messages
 139 * Nicolas François "hopes" `DynaLoader` is safe, and has "no reason to
 140   think that `Encode` is not safe"
 141 * Nicolas François has "no reason to think that `Encode::Guess` is not
 142   safe". The po plugin nevertheless avoids using it by defining the
 143   input charset (`file_in_charset`) before asking `TransTractor` to
 144   read any file. NB: this hack depends on po4a internals.
 145
 146 ##### Locale::Po4a::Text
 147
 148 * does not run any external program
 149 * only `do_paragraph()` builds regexp's that expand untrusted
 150   variables; according to [[Joey]], this is "Freaky code, but seems ok
 151   due to use of `quotementa`".
 152
 153 ##### Text::WrapI18N
 154
 155 `Text::WrapI18N` can cause DoS
 156 ([Debian bug #470250](http://bugs.debian.org/470250)).
 157 It is optional, and we do not need the features it provides.
 158
 159 If a recent enough po4a (>=0.35) is installed, this module's use is
 160 fully disabled. Else, the wiki administrator is warned about this
 161 at runtime.
 162
 163 ##### Term::ReadKey
 164
 165 `Term::ReadKey` is not a hard dependency in our case, *i.e.* po4a
 166 works nicely without it. But the po4a Debian package recommends
 167 `libterm-readkey-perl`, so it will probably be installed on most
 168 systems using the po plugin.
 169
 170 `Term::ReadKey` has too far reaching implications for us to
 171 be able to guarantee anything wrt. security.
 172
 173 If a recent enough po4a (>=2009-01-15 CVS, which will probably be
 174 released as 0.35) is installed, this module's use is fully disabled.
 175
 176 ##### Fuzzing input
 177
 178 ###### po4a-translate
 179
 180 * po4a CVS 2009-01-16
 181 * Perl 5.10.0
 182
 183 `po4a-translate` uses more or less the same po4a features as our
 184 `filter` function.
 185
 186 Without specifying an input charset, same behaviour as
 187 `po4a-gettextize`, so let's specify UTF-8 as input charset as of now.
 188
 189 `LICENSES` is a 21M file containing 100 concatenated copies of all the
 190 files in `/usr/share/common-licenses/`; I had no existing PO file or
 191 translated versions at hand, which renders these tests
 192 quite incomplete.
 193
 194         zzuf -cv -s 0:10 -r 0.001:0.3 \
 195           po4a-translate -d -f text -o markdown -M utf-8 -L utf-8 \
 196             -k 0 -m LICENSES -p LICENSES.fr.po -l test.fr
 197
 198 ... seems to lose the fight, at the `readpo(LICENSES.fr.po)` step,
 199 against some kind of infinite loop, deadlock, or any similar beast.
 200
 201 The root of this bug lies in `Text::WrapI18N`, see the corresponding
 202 section.
 203
 204
 205 ----
 206
 207 ## Fixed holes
 208