Bug 112078

Summary: CAN-2003-0966 buffer overflow in frm command
Product: Red Hat Enterprise Linux 2.1 Reporter: Need Real Name <phr-redhat>
Component: elmAssignee: Karsten Hopp <karsten>
Status: CLOSED ERRATA QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 2.1CC: mjc
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: i686   
OS: Linux   
URL: http://www.nightsong.com/phr/spam-crash.txt
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-01-14 14:48:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
patch for CAN-2003-0966 none

Description Need Real Name 2003-12-14 03:16:11 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1)
Gecko/20030225

Description of problem:
The url above contains a piece of spam that I got with a very long
subject line, that crashes the frm command with a core dump.  This
sounds like a standard buffer overflow bug with the obvious possible
exploits of someone sending a maliciously crafted piece of mail that
takes over a user account when the recipient runs "frm".  The whole
elm package probably should be audited for bugs like this.  I've
opened a CERT incident report but didn't save the report number
(expected an email acknowledgement but haven't gotten one yet).

Version-Release number of selected component (if applicable):
elm-2.5.6-2

How reproducible:
Always

Steps to Reproduce:
1. Download file in that url, save it in filename
2. Run "frm filename" from the shell
3.
    

Actual Results:  frm command crashes and leaves a core dump

Expected Results:  frm should truncate over-long header lines when
reading them

Additional info:

frm|tail is my usual way of checking whether I have interesting (i.e.
non-spam) mail and I run it several times an hour.  So it makes a real
vulnerability.

Comment 1 Mark J. Cox 2003-12-16 11:06:39 UTC
Verified.  This is a standard static buffer overflow that could be
exploited.  Fortunately elm is quite old and is not included in any
Red Hat distribution since Red Hat Linux 8.0.

I've allocated CVE name CAN-2003-0966 for this issue.  I'd like to
share this with other Linux distribution vendor security teams in case
they still ship elm.  Please let me know if this is okay.




Comment 2 Mark J. Cox 2003-12-16 11:07:09 UTC
Created attachment 96552 [details]
patch for CAN-2003-0966

Comment 3 Need Real Name 2003-12-16 11:16:12 UTC
Yes of course feel free to notify other vendors, you shouldn't need my
permission.  Also, as mentioned, I opened a CERT report.  

The program with the bug is a useful one and if it's really removed
from new RH distributions, it'll cause me some nuisance since I'll
have to reinstall it when I upgrade to the next version.  On the other
hand, the many other programs in that suite probably should all be
audited, which may not be worth the hassle any more.

Comment 4 Mark J. Cox 2003-12-18 09:44:55 UTC
On a brief investigation the code to implement 'from' in the updated
(forked?) Elm-ME looked like it had been completely rewritten to avoid
anything relating to a strcpy and fixed sized buffers.  However it
would seem to me that the functionality of the 'frm' command could be
trivially written by a tiny perl or python script.

Comment 5 Mark J. Cox 2003-12-19 09:59:29 UTC
A number of other vendors are affected and some of them want time to
look for other issues in frm.  I've proposed a public release date of
Jan 14th 2004 for this issue.

Comment 6 Mark J. Cox 2003-12-31 10:11:54 UTC
CAN-2003-0966 Affects: 2.1AS 2.1AW        
CAN-2003-0966 Affects: 7.1 7.2 7.3 (now end of life, won't fix)



Comment 7 Mark J. Cox 2003-12-31 10:12:31 UTC
*** Bug 112356 has been marked as a duplicate of this bug. ***

Comment 8 Mark J. Cox 2004-01-07 12:22:09 UTC
When we update elm we'd like to acknowledge you in the advisory.  If
you'd like credits please let us know your name.

Comment 9 Need Real Name 2004-01-07 12:30:48 UTC
Thanks, name is Paul Rubin.

Comment 10 Mark J. Cox 2004-01-14 14:48:59 UTC
Fixed in http://rhn.redhat.com/errata/RHSA-2004-009.html