Bugzilla Bug 132662

There's no maintainer for this. We should call for a maintainer, or mask the
ebuild.

See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=356988 and SA20012:
http://secunia.com/advisories/20012


Software:       pstotext 1.x

Description:
Brian May has reported a vulnerability in pstotext, which potentially can be
exploited by malicious people to compromise a vulnerable system.

The vulnerability is caused due to an error in sanitising the filename supplied
via the command line. This can be exploited to execute arbitrary commands when
pstotext is run with a specially crafted command line that contains shell
commands.

Sec team : someone can send an email requesting for a maintainer for
app-text/pstotext please ?

-dev mailed.

I have taken the patch from Debian and made a 1.9-r1 revision with that patch
(and added text-markup as herd).
As far as I can see the patch from Debian fixes the issue.
Now we only need it marked stable on all archs. There are currently no open
bugs open for this package (except this one), so... arch teams, please?

ok; go :)   Little respite for pstotext. Note that amd64 has no stable ebuild
and has no need to stabilize 1.9-r1.

not going to mark this stable on amd64- it can't accept postscript files from
stdin as it advertises on my amd64 systems. It works great if you give it a
path to a file, though.

btw, something seems odd; these are supposed to be the same:

$ pstotext -
ESP Ghostscript 815.02: Unrecoverable error, exit code 1
ESP Ghostscript 815.02: Unrecoverable error, exit code 1

$ pstotext
ESP Ghostscript 815.02: Unrecoverable error, exit code 1

$ cat /path/to/my.ps | pstotext -
ESP Ghostscript 815.02: Unrecoverable error, exit code 1
ESP Ghostscript 815.02: Unrecoverable error, exit code 1

from the --help text:
"-    read from stdin (default if no files specified)"

Good on sparc.

I've done some testing with app-text/pstotext-1.9-r1 on x86 and can conform
comment #5 and comment #6 with gostscript-(gnu/esp/afpl).

by the way: the bugs mentioned in comment #5 do not appear on x86 with the
currently stable version of pstotext (that is 1.8g-r1).

Portage 2203-svn (default-linux/x86/2006.0, gcc-3.4.5, glibc-2.3.6-r3,
2.6.16-gentoo-r6 i686)
=================================================================
System uname: 2.6.16-gentoo-r6 i686 AMD Athlon(tm) XP 2400+
Gentoo Base System version 1.6.14
dev-lang/python:     2.3.5-r2, 2.4.2
dev-python/pycrypto: [Not Present]
dev-util/ccache:     [Not Present]
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.1
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=athlon-xp -O2 -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env
/usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/
/usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/
/usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=athlon-xp -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig collision-protect distlocks sandbox sfperms strict test"
GENTOO_MIRRORS="http://gentoo.inode.at/ "
LANG="en_US.utf8"
LC_ALL="en_US.utf8"
LINGUAS="en de"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://192.168.0.1/gentoo-portage"
USE="x86 3dnow 3dnowext X a52 aac aalib acpi alsa apm audiofile avi berkdb
bitmap-fonts bonobo bzip2 cairo cdr cli crypt css cups curl dbus directfb dri
dts dvd dvdr dvdread eds emboss encode exif expat fam fbcon ffmpeg firefox flac
foomaticdb fortran gd gdbm gif ginac glut gmp gnome gphoto2 gpm gstreamer gtk
gtk2 gtkhtml guile hal icq idn imagemagick imlib ipv6 isdnlog java javascript
jpeg jpeg2k junit lcms libg++ libwww mad mikmod mime mmx mmxext mng motif
mozsvg mp3 mpeg msn nautilus ncurses nls nptl nsplugin nvidia offensive ogg
oggvorbis openal opengl pam pcre pdflib perl plotutils png posix pppd python
quicktime readline real reflection ruby sdl session slang sockets speex spell
spl sqlite sqlite3 sse ssl subtitles svg svga tcltk tcpd tetex theora tiff
truetype truetype-fonts type1-fonts udev unicode usb vcd vorbis win32codecs wma
xine xml xml2 xmms xorg xv xvid zlib linguas_en linguas_de userland_GNU
kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS,
PORTAGE_RSYNC_OPTS

Okay... I didn't check the stdin input option :-|

So I see to options:
1. Make a 1.8g-r2 with the patch and mark that stable.
2. Remove the package, since equivalent functionality is provided by ps2ascii
from ghostscript (valid point raised by genstef on -dev)

I tend to vote in favor of option 2, but I'm not 100% sure it dosen't have
additional functionality over ps2ascii (I just became familiar with the package
this evening).

Comments?

My vote is for option 2; HOWEVER it is important to note that this problem is
caused because of the pstotext-1.9-quote-chars-fix.patch. If you remove the
patch, everything works fine in 1.9. Take a look at the patch. If it's going to
be a hastle to fix, I say remove the package. If it will be easy to fix, I look
forward to 1.9-r1 soon.

We should tell debian about the stdin problems with this patch.

Even if I don't like nuking packages, I suggest p.mask'ing it, which would give
us some time to find a better solution or destroy it completely.

Also this vulnerability is a latent one, meaning it needs a cooperative
application (webapp) that acts quite weirdly on untrusted input. So I wouldn't
get overexcited on it and call a vote when it comes to GLSA or glsamask it.

For patching/masking, I leave the decision to the maintainers.

text-markup: so....what are we doing? :)

Back to ebuild and unccing arches.

You forgot to remove us :)

Sorry for the long wait (real life caught up with me this last week)
I have fixed the patch so it now works with stdin and commited it to a 1.9-r2
ebuild.
Hopefully pstotext-1.9-r2 can go stable?

sparc: When you mark it stable can you please remove the 1.9-r1 ebuild? It is
only there because it is the lastest stable sparc.

Dear arches,

please (try to) stabilize 1.9-r2. Report if any problems.

Dear SPARC,

please remove 1.9-r1 ebuild as soon as 1.9-r2 is SPARC'ed :)

(In reply to comment #18)
> Dear arches,
>
> please (try to) stabilize 1.9-r2. Report if any problems.
> 
> Dear SPARC,
> 
> please remove 1.9-r1 ebuild as soon as 1.9-r2 is SPARC'ed :)

Dammit!
I had the archs marked, just forgot to press that "Add Archs" button. :-)

Sparc stable.  And -r1.ebuild removed from repository.  In two steps.  Because
I am a slow reader, and missed the second part of your request the first time.

amd64 stable; I also assume that the updated patch has been sent to our Debian
friends?

(In reply to comment #21)
> amd64 stable; I also assume that the updated patch has been sent to our Debian
> friends?
> 

Sorry, no clue. Unfortunately, I don't have a lot of debian friends :( Feel
free to send it or tell me where to send it to and I'll do it.

Martin submitted it :)
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=356988

stable on ppc64

ppc stable

x86 done

Calling for a vote on a GLSA


i would vote a half-no. pstotext isn't often used and other distribs don't seem
to have considered this issue as being worthy of an advisory.

another weak no

Voting no and closing.