Bug 6379 - groff security issues CVE-2009-5080, CVE-2009-5081, and CVE-2009-5044
Summary: groff security issues CVE-2009-5080, CVE-2009-5081, and CVE-2009-5044
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 2
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact:
URL: http://lwn.net/Vulnerabilities/501107/
Whiteboard: MGA1TOO MGA2-64-OK, MGA2-32-OK, MGA1-...
Keywords: validated_update
Depends on:
Reported: 2012-06-08 22:38 CEST by David Walser
Modified: 2012-07-14 00:45 CEST (History)
9 users (show)

See Also:
Source RPM: groff-1.20.1-6.mga1.src.rpm
Status comment:


Description David Walser 2012-06-08 22:38:45 CEST
Fedora has issued an advisory on May 29:

CVE-2009-5044 only affects Mageia 1.

CVE-2009-5080 and CVE-2009-5081 also affect Cauldron/Mageia 2.
David Walser 2012-06-08 22:38:53 CEST

CC: (none) => dmorganec

David Walser 2012-06-08 22:39:02 CEST

CC: (none) => pterjan

David Walser 2012-06-15 00:00:25 CEST

Version: 1 => Cauldron
Whiteboard: (none) => MGA2TOO, MGA1TOO

Comment 1 David Walser 2012-06-15 19:30:48 CEST
Looks like I was incorrect, and all three CVEs affect both distros.

Patched package uploaded for Cauldron, Mageia 2, and Mageia 1.


Updated groff packages fix security vulnerabilities:

contrib/pdfmark/pdfroff.sh in GNU troff (aka groff) before 1.21
allows local users to overwrite arbitrary files via a symlink
attack on a pdf#####.tmp temporary file (CVE-2009-5044).

The contrib/eqn2graph/eqn2graph.sh, contrib/grap2graph/grap2graph.sh,
and contrib/pic2graph/pic2graph.sh scripts in GNU troff (aka groff)
1.21 and earlier do not properly handle certain failed attempts to
create temporary directories, which might allow local users to
overwrite arbitrary files via a symlink attack on a file in a
temporary directory (CVE-2009-5080).

The config.guess, contrib/groffer/perl/groffer.pl, and
contrib/groffer/perl/roff2.pl scripts in GNU troff (aka groff) 1.21
and earlier use an insufficient number of X characters in the
template argument to the tempfile function, which makes it easier
for local users to overwrite arbitrary files via a symlink attack
on a temporary file (CVE-2009-5081).


Updated packages in core/updates_testing:

from SRPMS:

Version: Cauldron => 2
Assignee: bugsquad => qa-bugs
Whiteboard: MGA2TOO, MGA1TOO => MGA1TOO

Comment 2 Zoltan Balaton 2012-06-26 20:08:20 CEST
Tried to test this on MGA2 x86_64.

Since I could not find POCs I was only doing regression testing and looked at the scripts to confirm the fixes. After installing packages built from groff-1.21-2.1.mga2.src.rpm I've found no regressions (still can view man pages, I've found a few bugs though, more on this later).

I could identify the fixes for insecure temp file creation in groffer, roff2pdf and eqn2graph but noticed that there is no change in pdfroff. The code in pdfroff already creates secure tempfiles by default but can fall back to insecure code if mktemp gives an error. The patch I used for reference (http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/groff/groff-1.20.1-owl-tmp.diff?rev=1.2;content-type=text%2Fplain) is for an older version and this part is different, what I saw may come from upstream.

As for the bugs:

- groffer does not work (the output does confirm the temp path fix though :-)):
$ xzcat /usr/share/man/man1/ls.1.xz | groffer --man
Can't exec "grog": No such file or directory at /usr/lib64/groff/groffer/func.pl line 432, <STDIN> line 267.
to_tmp(): grog error on /tmp/groffer_5975_SxfLPbRP2B/,file1; at /usr/lib64/groff/groffer/func.pl line 433, <STDIN> line 267.

- eqn2graph needs imagemagick but it's not required by the package:
$ echo 'G(z) ~=~ e sup { ln ~ G(z) }' | eqn2graph >test.png
/usr/bin/eqn2graph: line 90: convert: command not found

- xman cannot display xz compressed man pages

These are not regressions, they did not work previously so apart from the (unlikely) insecure fallback in pdfroff the updated package appears to fix what it should. I'd suggest to accept and release this update as is because it does fix security problems and create separate bugs about the problems found if needed. But I'm too lazy to do that so I leave the decision to someone more experienced in QA. :-)

CC: (none) => balaton

Comment 3 Dave Hodgins 2012-06-27 01:09:16 CEST
The groff package should require groff-perl.

Once it's installed, groffer is working on both my Magea 1 and 2 i586 tests.

CC: (none) => davidwhodgins

Comment 4 Zoltan Balaton 2012-06-27 10:21:50 CEST
Thanks for the comment, I did not notice grog is in groff-perl (somehow urpmf could not find that or I was too tired to find it). However, I think that instead of requireing groff-perl the proper fix is to move perl scripts such as groffer to the groff-perl package, otherwise there's not much point to have a subpackage if it's always required.
Comment 5 claire robinson 2012-06-27 13:41:07 CEST
Assigning David. Could you take a look David please.

Please reassign QA when you've had a chance.


CC: (none) => qa-bugs
Hardware: i586 => All
Assignee: qa-bugs => luigiwalser

Comment 6 Guillaume Rousse 2012-06-27 18:37:44 CEST
Zoltan solution seems the best option for me: move everything requiring stuff from groff-perl package there.

CC: (none) => guillomovitch

Comment 7 David Walser 2012-06-27 19:10:34 CEST
(In reply to comment #6)
> Zoltan solution seems the best option for me: move everything requiring stuff
> from groff-perl package there.

Yes, this makes sense.  The description for the groff-perl package would need to be updated in the process, but it does sound like that's exactly what that package is for.  Hopefully there aren't any other commands that need to move.

Guillaume, would you mind taking care of this?
Comment 8 Zoltan Balaton 2012-06-27 19:40:24 CEST
Just to make sure we are on the same page I did not mean to move stuff _from_ groff-perl _to_ groff package but the other way around: move stuff that requires perl _to_ groff-perl (unless it's not possible for some reason). This is to keep dependecies clean and avoid installing too many packages just for groff. Otherwise there's no reason to keep the groff-perl package if commands requiring perl are also in package groff. A quick search shows at least these commands need to be moved:

$ for f in `rpm -ql groff`; do file "$f"; done | fgrep Perl
/usr/bin/chem: Perl script, ASCII text executable
/usr/bin/groffer: Perl script, ASCII text executable
/usr/bin/roff2dvi: Perl script, ASCII text executable
/usr/bin/roff2html: Perl script, ASCII text executable
/usr/bin/roff2pdf: Perl script, ASCII text executable
/usr/bin/roff2ps: Perl script, ASCII text executable
/usr/bin/roff2text: Perl script, ASCII text executable
/usr/bin/roff2x: Perl script, ASCII text executable

And their man pages and /usr/lib64/groff/groffer/*
Comment 9 Marja Van Waes 2012-07-06 13:10:56 CEST
putting OK on whiteboard, because the assignee has been working on this

CC: (none) => marja11
Whiteboard: MGA1TOO => MGA1TOO OK

Comment 10 David Walser 2012-07-06 16:44:55 CEST
One thing we need to be careful of is the 4 packages that depend on groff:
- font-tools
- linuxdoc-tools
- mc
- task-printing

We need to be sure those don't need any of these Perl scripts.
Comment 11 David Walser 2012-07-06 16:53:04 CEST
(In reply to comment #10)
> One thing we need to be careful of is the 4 packages that depend on groff:
> - font-tools
> - linuxdoc-tools
> - mc
> - task-printing
> We need to be sure those don't need any of these Perl scripts.

For that reason, I'm not comfortable making this change in an update.  I'll do it in Cauldron, which will give us more time to determine any possible breakage.

Let's push this update as-is, please :o)

CC: qa-bugs => (none)
Assignee: luigiwalser => qa-bugs

David Walser 2012-07-06 16:53:24 CEST

Whiteboard: MGA1TOO OK => MGA1TOO

Comment 12 Zoltan Balaton 2012-07-06 18:22:52 CEST
I agree with that, added a whiteboard tag for successful regression testing on mga2 x86_64.

But what to do with the bugs found? Perhaps they should be noted in one (or two considering the xman bug) new tickets against Cauldron to have a place to track progress about them, but I cannot verify if they still exist in Cauldron so I won't create the tickets unless you ask for it. I'll assume you take care about them and create the tickets for Cauldron if needed. Let me know if this is not what you want. Thank you.

Whiteboard: MGA1TOO => MGA1TOO MGA2-64-OK

Comment 13 David Walser 2012-07-06 18:34:13 CEST
I moved the perl scripts to groff-perl in Cauldron.  Is there another bug?
Comment 14 Zoltan Balaton 2012-07-06 19:58:39 CEST
See bugs found during testing in Comment 2
Comment 15 David Walser 2012-07-06 22:52:56 CEST
OK, xman is in its own package (and own SRPM).  I guess it doesn't have xz support upstream.  I looked at it and there aren't any BuildRequires or configure options we're missing, so that's an upstream problem.

For the missing imagemagick, groff and imagemagick are both required by task-printing.  groff is only also required by a few other things, so it's unlikely for someone to not have both installed, but it is possible, so I'll just add the requires in the package.  It is needed by eqn2graph, grap2graph, and pic2graph.
Comment 16 Guillaume Rousse 2012-07-06 23:25:25 CEST
This bug was initially supposed to be related about a security issue, and now you're discussing about transitive closure of groff dependencies, which makes issue tracking a bit difficult...

Concerning the last change, congratulations, you're now forcing a full X11 stack on every server, as imagemagick is a dependency hog :) Remember than mandatory dependencies are supposed to be used only for mandatory stuff, and in ten years of mandrake-mandriva-mageia, no one ever complained about a broken groff package...
Comment 17 David Walser 2012-07-06 23:40:29 CEST
Well, let's be realistic.  If someone files a bug for these other issues, it'll never get fixed anyway.  So I'm fixing what can be fixed now.

Just because nobody ever complained doesn't mean it isn't broken, but you raise a fair point.  I've moved *2graph to the groff-x11 package.
Comment 18 Dave Hodgins 2012-07-08 04:34:13 CEST
Are there any more changes to be made, or is this now ready for
qa testing?  I realize it's assigned to qa, but with the above
comments, it isn't clear if it's actually ready.
Comment 19 David Walser 2012-07-08 15:13:09 CEST
This is good to go.  No changes are pending.
Comment 20 Dave Hodgins 2012-07-11 03:58:51 CEST
Testing complete on Mageia 1 i586

xzcat /usr/share/man/man1/gxditview.1.xz |groff -TX100-12 -man -rS12 -

I'll test Mageia 2 i586 shortly.
Comment 21 Dave Hodgins 2012-07-11 04:12:55 CEST
Note the groff-x11 package has to be installed for the test.

Testing complete on Mageia 2 i586.
Dave Hodgins 2012-07-11 04:13:24 CEST

Whiteboard: MGA1TOO MGA2-64-OK => MGA1TOO MGA2-64-OK, MGA2-32-OK, MGA1-32-OK

Comment 22 Deri James 2012-07-13 01:31:26 CEST
Testing on Mag 2 x86_64, did:-

man -t grops | okular - # tests the 35 fonts in grops
man -t groff_char | okular - # tests all named glyphs in groff (Ones marked N/A are expected)

CC: (none) => deri

Comment 23 claire robinson 2012-07-13 12:39:13 CEST
Testing complete mga1 using Daves xzcat and Deri's tests.

Thankyou for those Deri.


Please see comment 1 for advisory and srpm's for mga1 & 2

Could sysadmin please push from core/updates_testing to core/updates


Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs
Whiteboard: MGA1TOO MGA2-64-OK, MGA2-32-OK, MGA1-32-OK => MGA1TOO MGA2-64-OK, MGA2-32-OK, MGA1-32-OK mga1-64-OK

Comment 24 Thomas Backlund 2012-07-14 00:45:55 CEST
Update pushed:

CC: (none) => tmb
Resolution: (none) => FIXED

Note You need to log in before you can comment on or make changes to this bug.