[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4FFAE8CF.9040005@redhat.com>
Date: Mon, 09 Jul 2012 16:21:03 +0200
From: Jan Lieskovsky <jlieskov@...hat.com>
To: "Steven M. Christey" <coley@...us.mitre.org>
CC: oss-security@...ts.openwall.com, David Woodhouse <dwmw2@...radead.org>,
Daniel Berrange <berrange@...hat.com>,
Daniel Veillard <veillard@...hat.com>
Subject: Re: CVE Request -- dnsmasq: When being run by libvirt open DNS proxy
(reachable out-of the virtual network set for the particular guest domain
too) is created
Steve,
some kind of strange request (since I have requested
the CVE id originally), but didn't previously think of
it that following way -- which component would the CVE id be
actually assigned to, dnsmasq or libvirt?
From my understanding it's a combination of both of them,
which is making it a security flaw (libvirt has announced
to provide DNS masquerade and due to a bug in one component,
actually providing that functionality, this allowed a DDoS
attacks).
Once libvirt announced the separation, is it it's
responsibility to handle it? And as such security flaw in
libvirt?
For the dnsmasq package, it doesn't look like a security
flaw (rather as bug, when handling certain CLI option -- it
would not ignore packets as instructed).
I am not completely sure, there has been similar enough
example in the past, which could help us to decide which
component the particular CVE identifier should be assigned
to.
Could you clarify / help us to understand Mitre's opinion
here?
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team
On 07/09/2012 02:04 PM, Jan Lieskovsky wrote:
> Hello Kurt, Steve, vendors,
>
> David Woodhouse reported a deficiency in the way dnsmasq,
> a lightweight, easy to configure DNS forwarder and DHCP server,
> when being run under libvirt, a library providing simple
> virtualization API, performed processing of packets coming
> outside of virtual network set for the particular guest domain.
>
> When libvirt was configured to provide a range of public
> IP addresses to its guest domains and dnsmasq was instructed
> to discard packets originating from other interfaces, than
> specified on the command line via the --bind-interface option,
> those packets (coming from 'prohibited' interfaces) were not
> dropped properly and subsequently processed.
>
> A remote attacker could use this flaw to cause a distributed
> denial of service, as demonstrated in the report [1] via "stream
> of spoofed DNS queries producing large results".
>
> References:
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=833033
>
> Could you allocate a CVE id for this?
>
> Thank you && Regards, Jan.
> --
> Jan iankko Lieskovsky / 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.
