Looks like I was incorrect, and all three CVEs affect both distros.

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

Advisory:
========================

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).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-5044
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-5080
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-5081
http://lists.fedoraproject.org/pipermail/package-announce/2012-June/081977.html
========================

Updated packages in core/updates_testing:
========================
groff-1.20.1-6.1.mga1
groff-for-man-1.20.1-6.1.mga1
groff-perl-1.20.1-6.1.mga1
groff-x11-1.20.1-6.1.mga1
groff-doc-1.20.1-6.1.mga1
groff-1.21-2.1.mga2
groff-for-man-1.21-2.1.mga2
groff-perl-1.21-2.1.mga2
groff-x11-1.21-2.1.mga2
groff-doc-1.21-2.1.mga2

from SRPMS:
groff-1.20.1-6.1.mga1.src.rpm
groff-1.21-2.1.mga2.src.rpm

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

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

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

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.

Assigning David. Could you take a look David please.

Please reassign QA when you've had a chance.

Thanks!

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

Zoltan solution seems the best option for me: move everything requiring stuff from groff-perl package there.

CC: (none) => guillomovitch

(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?

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/*

putting OK on whiteboard, because the assignee has been working on this

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

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.

(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

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

I moved the perl scripts to groff-perl in Cauldron.  Is there another bug?

See bugs found during testing in Comment 2

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.

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

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.

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.

This is good to go.  No changes are pending.

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.

Note the groff-x11 package has to be installed for the test.

Testing complete on Mageia 2 i586.

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

Testing complete mga1 using Daves xzcat and Deri's tests.

Thankyou for those Deri.

Validating

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

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

Thanks!

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

Update pushed:
https://wiki.mageia.org/en/Support/Advisories/MGASA-2012-0164

Status: NEW => RESOLVED
CC: (none) => tmb
Resolution: (none) => FIXED