bugGNU troff - Bugs: bug #55557, gropdf can execute arbitrary...


bug #55557: gropdf can execute arbitrary commands

Submitted by:  Deri James <deri>
Submitted on:  Wed 23 Jan 2019 03:59:31 PM UTC  
Category:  Device gropdf Severity:  4 - Important
Item Group:  Warning/Suspicious behaviour Status:  Confirmed
Privacy:  Public Assigned to:  Deri James <deri>
Open/Closed:  Open Planned Release:  None

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


Thu 24 Jan 2019 04:12:37 PM UTC, comment #2: 

I think all the approaches involving careful @ARGV mangling are far too delicate and it's too hard to be certain that they're correct.  My preference would be to avoid <> entirely and use three-argument open, as in the attached patch.

Colin Watson <cjwatson>
Project Member
Wed 23 Jan 2019 11:22:35 PM UTC, comment #1: 

It looks like putting this line in the program, after any command line flags have been handled/removed from ARGV:-

map { $_="< ".$_."\0" } @ARGV;

This does a similar job to the code referenced by Colin at:-


Except that it does not add "./" before any space at the start of the filename, because that will fail if a space is given before a full pathname, it is only useful if a file in the current directory has embedded leading spaces in its filename. Even with the gropdf code as it is currently you would need to pass the filename as "./ filename" to avoid the spaces being ignored.

I believe this line can be added to gropdf, hyphenex, gpinyin, and gperl. I am not sure about glilypond yet, I need a bit more thought on that, since it does a lot of work with ARGV in the program args.pl.

Does anyone have a better idea?

Deri James <deri>
Project MemberIn charge of this item.
Wed 23 Jan 2019 03:59:31 PM UTC, original submission:  

Vincent Lefevre has reported this security problem on the debian bug tracker:-


So I am opening this bug here. It has been discussed on the groff mailing list, here:-


The problem is explained as:-

"... but providing a "filename" with a pipe character can yield an
arbitrary command execution:

$ touch foo
$ ls 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 "<>". "

Colin Watson has suggested including code to "clean" the the arguments passed on the gropdf command line. He has also identified other perl scripts which may have a similar problem:-

  $ 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 <>

I shall look at ways of blocking this behaviour.

Deri James <deri>
Project MemberIn charge of this item.


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #46089:  0001-Avoid-Perl-s-unsafe-operator.patch added by cjwatson (20KiB - text/x-patch - Avoid Perl's unsafe "<>" operator)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by cjwatson (Updated the item)
  • -email is unavailable- added by deri (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-01-24 cjwatson Attached File- => Added 0001-Avoid-Perl-s-unsafe-operator.patch, #46089

    Back to the top

    Powered by Savane 3.5