Re: CVE request: lynx (old) .mailcap handling flaw

[Tomas Hoger <thoger () redhat com>]

Hi Tavis!

On Mon, 27 Oct 2008 18:38:19 +0000 Tavis Ormandy
<taviso () sdf lonestar org> wrote:

> On Sat, Oct 25, 2008 at 08:27:51PM +0200, Tomas Hoger wrote:
> > There's one old lynx issue that seem to need a 2006 CVE id.  lynx
> > browser prior to 2.8.6rel.4 tries to open mailcap and mime type
> > definition files form the current directory.  If user can be
> > convinced to run lynx in a specially crafted directory, an attacker
> > controlling the directory may be able to run arbitrary code as the
> > victim running lynx.
>
> That reminds me, I recently noticed valgrind also does this.
>
> $ printf -- "--db-command=/usr/bin/id\n--db-attach=yes\n"
> > /tmp/.valgrindrc

Well, I'd say the situation with valgrind is slightly different.  For
lynx, there seem to be 2 obvious attack vectors:

1) User downloads tarball with bunch of htmls, with bundled
malicious .mailcap file.  When user cds to the directory and runs lynx,
he's owned.

2) Local social engineering attack - local attacker convinces victim to
run lynx in some specially crafted local directory.

For valgrind, 1) does not seem to make much sense (or is lot less
likely), as if you valgrind random binary downloaded form the net,
you're already running attacker's code.

Few other differences:
- valgrind behavior is known and well documented
http://valgrind.org/docs/manual/manual-core.html#manual-core.defopts
(lynx.cfg file comments suggested, that mailcap file is read from
user's home directory, no mention of CWD)

- valgrind's behavior seems more useful and used in the wild, so not
easily changeable

- you can suppress reading .valgrindrc files using
--command-line-only=yes , but this option does not seem to be very well
documented in commonly shipped man pages or --help output.
There seem to be some man page versions that mention this option:
http://linuxcommand.org/man_pages/valgrind1.html

Actually, gdb may be another target with its handling of .gdbinit:

   echo 'shell /usr/bin/id' > .gdbinit ; gdb

(gdb seems to have some checks in place though and refuses to open files
that world-writable or not owned by the user)

-- 
Tomas Hoger / Red Hat Security Response Team