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.
