Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 09 Jul 2012 16:21:03 +0200
From: Jan Lieskovsky <>
To: "Steven M. Christey" <>
CC:, David Woodhouse <>,
        Daniel Berrange <>,
        Daniel Veillard <>
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


   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

   Once libvirt announced the separation, is it it's
responsibility to handle it? And as such security flaw in

   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

   Could you clarify / help us to understand Mitre's opinion

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]
> 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.