This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 214205 - (CVE-2006-7234) CVE-2006-7234 lynx: .mailcap and .mime.types files read from CWD
CVE-2006-7234 lynx: .mailcap and .mime.types files read from CWD
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
Brian Brock
http://bugs.debian.org/cgi-bin/bugrep...
source=debian,reported=20061106,impac...
: Security
Depends On: 468541 468542 468543 468544 468545 468546 833938
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-06 10:44 EST by Red Hat Product Security
Modified: 2012-06-20 10:22 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-28 04:18:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Lubomir Kundrak 2006-11-06 10:44:00 EST
Description of problem:

Lynx reads .mailcap and .mime.types from its CWD, making it
possible for a malicious person to make it execute arbitrairy
code when user launches lynx while its working directory
contains attacker-provided contents.

Steps to Reproduce:

$ cat .mime.types
application/x-bug       bug
$ cat .mailcap
application/x-bug; xmessage 'Hello, World!'
$ cat poc.bug
$ lynx poc.bug

( xmessage 'Hello, World!' ) < /home/lkundrak/L28618-1037TMP.bin

...

Fix:

Make lynx read files from ~ instead of CWD.
Debian patch is unusable here, they completly remove code
for reading the files in question.
Comment 1 Thomas E. Dickey 2006-11-06 19:02:14 EST
This is more accurate than the Debian report, which does not
distinguish between the starting directory and directories
which lynx may visit.

I prefer (unless someone can point out a flaw) to use IsOurFile()
to verify that the file is safe to read.
Comment 2 Thomas E. Dickey 2006-11-15 06:11:00 EST
Depending on the use, the Debian patch has some limited value.
As I noted, I added logic to use IsOurFile() to reduce the
scope (and that patch is easily resync'd to 2.8.5).  Properly
handling the user's mailcap/mime file settings is harder.
The effect of the Debian patch is to always append that setting
to the user's home-path.  It doesn't check if the global setting
is not a relative path.  I added a check for the latter, and chose
to address the user's settings by making tilde-expansion in those
work - and then enforcing absolute pathnames for the user's settings.
That's in lynx 2.8.7dev.4 (resyncing the tilde expansion stuff is
more work).  I'd suggest adding the 2.8.6rel.3 patch (for IsOurFile),
and combining that with the Debian patch for fixes to older releases.
Comment 3 Thomas E. Dickey 2006-11-15 07:55:49 EST
I'll work on this, this evening to put together a possible
patch to combine the different aspects.
Comment 7 Tomas Hoger 2008-10-25 14:10:56 EDT
For the sake of completeness...  This issue was fixed upstream in 2.8.6rel.4.  As of this version, lynx will not search current working directory for PERSONAL_MAILCAP (.mailcap by default) and PERSONAL_EXTENSION_MAP (.mime.types by default) files, but will only try to find those files in the user's home directory.

Patches for older versions:
ftp://lynx.isc.org/lynx2.8.5/patches/2.8.5rel.6.patch.gz
ftp://lynx.isc.org/lynx2.8.4/patches/lynx2.8.4rel.1e.patch
Comment 11 Tomas Hoger 2008-10-27 12:38:45 EDT
CVE id CVE-2006-7234 was assigned to this issue:

Untrusted search path vulnerability in Lynx before 2.8.6rel.4 allows
local users to execute arbitrary code via malicious (1) .mailcap and
(2) mime.types files in the current working directory.
Comment 12 Red Hat Product Security 2008-10-28 04:18:50 EDT
This issue was addressed in:

Red Hat Enterprise Linux:
  http://rhn.redhat.com/errata/RHSA-2008-0965.html
Comment 13 Red Hat Bugzilla 2009-10-23 15:05:32 EDT
Reporter changed to security-response-team@redhat.com by request of Jay Turner.

Note You need to log in before you can comment on or make changes to this bug.