Re: CVE request: ettercap GTK

[Dan Rosenberg <dan.j.rosenberg () gmail com>]

Based on this, I'd say the buffer overflow CVE-2010-3844 is probably
extraneous.  The only attack vector is due to the fact that the
configuration file is globally accessible, so I would argue that, just
like your example of SQL injection allowing XSS, the insecure
temporary file usage allows the buffer overflow.  Given that the
configuration file is hidden by default, I'd assume that there is no
intention of allowing users to share configurations - I think it's
only supposed to maintain settings between consecutive executions on
the same machine.

-Dan

On Thu, Oct 14, 2010 at 2:10 PM, Steven M. Christey
<coley () linus mitre org> wrote:
> If the config file is intended to be trusted, then any issues that can
> *only* be exploited through that trusted file, are not relevant for CVE
> inclusion - basically, it would be the admin attacking himself/herself.
>
> If you fix problem X, and it automatically fixes another problem Y (or, at
> worst, renders it as non-security-relevant) - then you would assign a CVE to
> X, and perhaps emphasize Y as one of potentially-many consequences.
>
> Maybe other attacks are possible through that config file; but would they be
> irrelevant if the config file was only accessible to the intended user?
>
> As a distinct example: you have a web-based application that stores content
> into a database, including user IDs that are validated to be alphanumeric
> before insertion into the database.  If an SQL injection vulnerability is
> exploited, maybe the attacker could injest XSS into the user ID.  But the
> user ID is "trusted" in the intended security model of the application, so
> the SQL injection would get the CVE, and the XSS would be listed as a
> consequence.
>
> So, in this case, it might be that CVE-2010-3844 is extraneous.
>
> But, if it's reasonable for configuration files to be shared between users
> or installations (just like pictures, packet captures, or MP3s) - then
> there's a reasonable exploit scenario where the temp file issue is
> irrelevant, but the format string still has an attack vector.
>
> Hope that makes sense.  This was a bane to us at CVE years ago, and was the
> source of a lot of confusion and inconsistency.  It happens in the web app
> world all the time.
>
> - Steve
>
>
>
> On Wed, 13 Oct 2010, Josh Bressers wrote:
>
> > > There are two issues here (insecure temporary file usage and
> > > stack-based buffer overflow), but they're probably only
> > > security-relevant when exploited in conjunction.  Not sure if it
> > > should get one CVE or two.
> > >
> > > Reference:
> > > https://bugs.launchpad.net/ubuntu/+source/ettercap/+bug/656347
> >
> > We'll use two:
> >
> > CVE-2010-3843 ettercap GTK insecure temporary file use
> > CVE-2010-3844 ettercap GTK format string flaw