[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081028103843.1be41af1@redhat.com>
Date: Tue, 28 Oct 2008 10:38:43 +0100
From: Tomas Hoger <thoger@...hat.com>
To: taviso@....lonestar.org
Cc: oss-security@...ts.openwall.com, coley@...re.org
Subject: Re: CVE request: lynx (old) .mailcap handling flaw
Hi Tavis!
On Mon, 27 Oct 2008 18:38:19 +0000 Tavis Ormandy
<taviso@....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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
