Hi,
I'm not quite sure of the circumstances in which an attacker (presumably
the author of a document you've received) might be able to control the
arguments to gropdf; but regardless, this does seem to be undesirable
command-line handling and I think we should fix it.
$ find -name \*.pl | xargs grep -- '<>'
./src/devices/gropdf/gropdf.pl:while (<>)
./src/devices/gropdf/gropdf.pl: my $lin=<>;
./tmac/hyphenex.pl:while (<>) {
./contrib/gpinyin/gpinyin.pl:foreach (<>) { # get line from input
./contrib/gperl/gperl.pl:foreach (<>) {
./contrib/glilypond/glilypond.pl: LILYPOND: foreach (<>) {
./contrib/glilypond/glilypond.pl: } # end foreach <>
What I'm not quite sure of is what the best fix would be, since my Perl
is a bit rusty. Perl >= 5.20 has the safer <<>> operator, which only
interprets file names, but I don't know whether it would be acceptable
to bump groff's minimum Perl version from its current value of 5.6.1.
In my own wheelhouse, that would drop support for everything up to and
including Debian 7 (currently oldoldstable) and Ubuntu 14.04 (which goes
out of regular support this April), which does include some stuff that
we'd want to issue security updates for, so maybe that isn't the best
option.
Alternatively, perhaps we could just copy ARGV::readonly from CPAN into
the start of all our Perl scripts? It's sufficiently small that it
might not be worth getting too worked up about the code duplication:
https://metacpan.org/source/DAVIDNICO/ARGV-readonly-0.01/lib/ARGV/readonly.pm
Any other ideas welcome.
Thanks,
--
Colin Watson [cjwat...@debian.org]
--- Begin Message ---
Package: groff
Version: 1.22.4-2
Severity: grave
Tags: security
Justification: user security hole
According to the gropdf(1) man page:
gropdf [-dels] [-F dir] [-I dir] [-p paper-size] [-u [cmapfile]]
[-y foundry] [file ...]
but providing a "filename" with a pipe character can yield an
arbitrary command execution:
$ touch foo
$ ls foo
foo
$ gropdf "rm foo|"
$ ls foo
ls: cannot access 'foo': No such file or directory
$
The reason is that gropdf is a Perl script that uses the insecure
null filehandle "<>". The perlop(1) man page says:
Since the null filehandle uses the two argument form of "open" in
perlfunc it interprets special characters, so if you have a script like
this:
while (<>) {
print;
}
and call it with "perl dangerous.pl 'rm -rfv *|'", it actually opens a
pipe, executes the "rm" command and reads "rm"'s output from that pipe.
BTW, I fear that's not the only Perl script that is affected by such
a bug.
-- System Information:
Debian Release: buster/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500,
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-1-amd64 (SMP w/12 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages groff depends on:
ii groff-base 1.22.4-2
ii libc6 2.28-5
ii libgcc1 1:8.2.0-14
ii libice6 2:1.0.9-2
ii libsm6 2:1.2.2-1+b3
ii libstdc++6 8.2.0-14
ii libx11-6 2:1.6.7-1
ii libxaw7 2:1.0.13-1+b2
ii libxmu6 2:1.1.2-2
ii libxt6 1:1.1.5-1
Versions of packages groff recommends:
ii ghostscript 9.26~dfsg-0+deb9u2
ii imagemagick 8:6.9.10.23+dfsg-2
ii imagemagick-6.q16 [imagemagick] 8:6.9.10.23+dfsg-2
ii libpaper1 1.1.26
ii netpbm 2:10.0-15.3+b2
ii perl 5.28.1-3
ii psutils 1.17.dfsg-4
groff suggests no packages.
-- no debconf information
--- End Message ---
