[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <559AED44.2050307@debian.org>
Date: Mon, 06 Jul 2015 22:04:04 +0100
From: Simon McVittie <smcv@...ian.org>
To: oss-security@...ts.openwall.com
Subject: Re: TR : CVE request for dash 0.5.7-3 x86-64 local
buffer overflow
On 06/07/15 13:58, jean-marie.bourbon@...aturetech.com wrote:
> I discover it using bash who sent me a SIGKILL (no real crash) and
> closed my shell in certain circumstances:
>
> kmkz@...z:/tmp$ `perl -e '$i=0;while($i<= 500){print"DEAD"x10;}'`
> bash: xrealloc : ../bash/subst.c:5184 : impossible d'allouer 2097152
> octets (4460544 octets alloués)
>
> So I wanted to try using my /bin/dash and... I had a local crash !
You told dash to interpret a command 2 gigabytes long, and it failed to
do so; additionally, the failure was a crash, not a deterministic
semi-graceful exit. That sounds like a bug.
However, to be a security vulnerability rather than "just a bug", a
buffer overflow is not enough; to be a security vulnerability, it would
have to be an *attacker-triggerable* buffer overflow.
Is there any circumstance under which an attacker - not you - can cause
this to happen, other than via an arbitrary-code-execution vulnerability
in some other component?
(If you are already vulnerable to attacker-controlled arbitrary code
execution, then dash crashing is the least of your worries.)
S
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.
