<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "http://bugs.gentoo.org/bugzilla.dtd">

<bugzilla version="2.22.7"
          urlbase="http://bugs.gentoo.org/"
          maintainer="bugzilla@gentoo.org"
>

    <bug>
          <bug_id>100398</bug_id>
          
          <creation_ts>2005-07-26 13:02 0000</creation_ts>
          <short_desc>media-libs/netpbm Arbitrary Postscript Code Execution Vulnerability</short_desc>
          <delta_ts>2005-08-15 22:02:46 0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>Gentoo Security</product>
          <component>Vulnerabilities</component>
          <version>unspecified</version>
          <rep_platform>All</rep_platform>
          <op_sys>Linux</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          <status_whiteboard>B2 [glsa]</status_whiteboard>
          
          <priority>P2</priority>
          <bug_severity>normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          
          <everconfirmed>1</everconfirmed>
          <reporter>folajimi@speakeasy.net</reporter>
          <assigned_to>security@gentoo.org</assigned_to>
          <cc>graphics@gentoo.org</cc>

      

      
          <long_desc isprivate="0">
            <who>folajimi@speakeasy.net</who>
            <bug_when>2005-07-26 13:02:14 0000</bug_when>
            <thetext>Max Vozeler has reported a vulnerability in netpbm, which can be exploited by
malicious people to compromise a vulnerable system.

The vulnerability is caused due to pstopnm not using the &quot;-dSAFER&quot; option when
calling GhostScript to convert a PostScript file into a PBM, PGM, or PNM file.
This allows a malicious PostScript file to execute arbitrary commands on a
vulnerable system.

The vulnerability has been reported in version 10.0. Other versions may also be
affected.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.




Solution:
Only use pstopnm on trusted files.

http://secunia.com/advisories/16184/</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>jaervosz@gentoo.org</who>
            <bug_when>2005-07-26 13:11:47 0000</bug_when>
            <thetext>graphics please advise. </thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>sekretarz@gentoo.org</who>
            <bug_when>2005-07-27 01:46:29 0000</bug_when>
            <thetext>Created an attachment (id=64419)
Fix by debian

Patch proposed by Debian</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>koon@gentoo.org</who>
            <bug_when>2005-07-29 03:12:44 0000</bug_when>
            <thetext>graphics herd, please apply Debian patch</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>sekretarz@gentoo.org</who>
            <bug_when>2005-07-30 13:55:57 0000</bug_when>
            <thetext>Bumped to 10.28 and patched ebuild is in portage. This release fixes also
insecure temp file in ppmtompeg.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>jaervosz@gentoo.org</who>
            <bug_when>2005-07-31 01:07:41 0000</bug_when>
            <thetext>Arches please test and mark stable. </thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>killerfox@gentoo.org</who>
            <bug_when>2005-07-31 03:03:37 0000</bug_when>
            <thetext>Stable on hppa</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>corsair@gentoo.org</who>
            <bug_when>2005-07-31 05:16:08 0000</bug_when>
            <thetext>stable on ppc64</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>ferdy@gentoo.org</who>
            <bug_when>2005-07-31 06:08:29 0000</bug_when>
            <thetext>Stable on alpha

Cheers,
Ferdy</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>dertobi123@gentoo.org</who>
            <bug_when>2005-07-31 09:51:39 0000</bug_when>
            <thetext>ppc stable</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>herbs@gentoo.org</who>
            <bug_when>2005-08-01 03:18:02 0000</bug_when>
            <thetext>Stable on amd64.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>gustavoz@gentoo.org</who>
            <bug_when>2005-08-01 07:46:14 0000</bug_when>
            <thetext>sparc stable
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>koon@gentoo.org</who>
            <bug_when>2005-08-02 02:06:33 0000</bug_when>
            <thetext>10.28 still misses hppa...
x86/maintainer: please also text and mark x86 stable</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>sekretarz@gentoo.org</who>
            <bug_when>2005-08-02 04:50:50 0000</bug_when>
            <thetext>x86 done</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>killerfox@gentoo.org</who>
            <bug_when>2005-08-02 09:09:26 0000</bug_when>
            <thetext>Stable on hppa again.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>koon@gentoo.org</who>
            <bug_when>2005-08-03 00:41:28 0000</bug_when>
            <thetext>We must decide if we issue a GLSA on this one.

The problem here is that we consider as unexpected behavior the fact that
pstotext or pstopnm execute blindly the PS (potentially honoring the pipe
commands to execute arbitrary stuff). A behavior that we consider &quot;as
documented&quot; when it&apos;s for Ghostscript itself.

My position is that a vast majority of users won&apos;t know that pstotext and
pstopnm will execute Ghostscript in a way potentially allowing code execution,
so the GLSAs are justified. That said, they probably don&apos;t know that regular PS
files fed to Ghostscript also will. I would prefer -dSAFER enabled by default in
Ghostscript (which should come in a next version). Let&apos;s say GS is a
sufficiently low-level tool that its users know what they are doing, hence it&apos;s
not really considered a vulnerability ?</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>taviso@gentoo.org</who>
            <bug_when>2005-08-03 00:51:10 0000</bug_when>
            <thetext>I would normally vote no, but following the pstopnm issue we should probably 
glsa this one as well, so YES.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>kloeri@gentoo.org</who>
            <bug_when>2005-08-04 14:43:21 0000</bug_when>
            <thetext>Stable on ia64.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>jaervosz@gentoo.org</who>
            <bug_when>2005-08-05 01:10:13 0000</bug_when>
            <thetext>Yeah pstotext sets a (bad?) precedent so I tend to vote Yes. </thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>koon@gentoo.org</who>
            <bug_when>2005-08-05 01:12:38 0000</bug_when>
            <thetext>OK let&apos;s go then</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>koon@gentoo.org</who>
            <bug_when>2005-08-05 04:02:00 0000</bug_when>
            <thetext>GLSA 200508-04
arm and mips should mark stable to benefit from GLSA</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>ka0ttic@gentoo.org</who>
            <bug_when>2005-08-05 11:06:38 0000</bug_when>
            <thetext>Stable on mips.</thetext>
          </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>64419</attachid>
            <date>2005-07-27 01:46 0000</date>
            <desc>Fix by debian</desc>
            <filename>pstopnm_dsafer.diff</filename>
            <type>text/plain</type>
            <data encoding="base64">LS0tIG5ldHBibS1mcmVlLTEwLjAvcG5tL3BzdG9wbm0uY34JMjAwNS0wNi0wMiAxNjoyMDowMy4y
MDU2OTQxNzYgKzAyMDAKKysrIG5ldHBibS1mcmVlLTEwLjAvcG5tL3BzdG9wbm0uYwkyMDA1LTA2
LTAyIDE2OjI0OjI0Ljk3ODI2Mjg1NiArMDIwMApAQCAtNTY4LDExICs1NjgsMTEgQEAKICAgICAg
ICAgcG1fbWVzc2FnZSgiZXhlY2luZyAnJXMnIHdpdGggYXJncyAnJXMnIChhcmcgMCksICIKICAg
ICAgICAgICAgICAgICAgICAiJyVzJywgJyVzJywgJyVzJywgJyVzJywgJyVzJywgJyVzJywgJyVz
JyIsCiAgICAgICAgICAgICAgICAgICAgZ2hvc3RzY3JpcHRQcm9nLCBhcmcwLAotICAgICAgICAg
ICAgICAgICAgIGRldmljZW9wdCwgb3V0ZmlsZW9wdCwgZ29wdCwgcm9wdCwgIi1xIiwgIi1kTk9Q
QVVTRSIsICItIik7CisgICAgICAgICAgICAgICAgICAgZGV2aWNlb3B0LCBvdXRmaWxlb3B0LCBn
b3B0LCByb3B0LCAiLXEiLCAiLWROT1BBVVNFIiwgIi1kU0FGRVIiLCAgIi0iKTsKICAgICB9CiAK
ICAgICBleGVjbChnaG9zdHNjcmlwdFByb2csIGFyZzAsIGRldmljZW9wdCwgb3V0ZmlsZW9wdCwg
Z29wdCwgcm9wdCwgIi1xIiwKLSAgICAgICAgICAiLWROT1BBVVNFIiwgIi0iLCBOVUxMKTsKKyAg
ICAgICAgICAiLWROT1BBVVNFIiwgIi1kU0FGRVIiLCAiLSIsIE5VTEwpOwogICAgIAogICAgIHBt
X2Vycm9yKCJleGVjbCgpIG9mIEdob3N0c2NyaXB0ICgnJXMnKSBmYWlsZWQsIGVycm5vPSVkICgl
cykiLAogICAgICAgICAgICAgIGdob3N0c2NyaXB0UHJvZywgZXJybm8sIHN0cmVycm9yKGVycm5v
KSk7Cg==
</data>        

          </attachment>
    </bug>

</bugzilla>