Created attachment 632589 [details]
upstream commit ad4a8ff7d9097008d7623df8543df435bfddeac8

Via rh#1215747

Dnsmasq does not properly check the return value of the setup_reply() function called during a tcp connection (by the tcp_request() function). This return value is then used as a size argument in a function which writes data on the client's connection. This may lead, upon successful exploitation, to reading the heap memory of dnsmasq.

This issue is fixed in dnsmasq-2.73rc4:

ML discussion:
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2015q2/009382.html

> From: Nick Sampanis nicksampanis at gmail.com
> Date: Tue Apr 7 08:49:30 BST 2015
> Subject: [Dnsmasq-discuss] dnsmsaq potential vulnerability
> 
> Dear sirs,
>              I discovered one potential vulnerability in dnsmasq.
> More specifically, in tcp_request(), setup_reply() gets called and the
> returned value
> is used as a size argument in a write function.
> 
> m = setup_reply(header, (unsigned int)size, addrp, flags,
> daemon->local_ttl);
> read_write(confd, packet, m + sizeof(u16), 0))
> 
> Although, setup_reply can't return a size variable greater than
> packet[65535+ MAXDNAME + RRFIXEDSZ + sizeof(u16))],
> an ignored error value(NULL) of  skip_questions() might lead to a negative
> pointer
> value(-header)
> 
> size_t setup_reply(struct dns_header *header, size_t qlen,
> struct all_addr *addrp, unsigned int flags, unsigned long ttl)
> {
>    unsigned char *p = skip_questions(header, qlen)
>    return p - (unsigned char *)header
> }
> 
> read_write checks if the size argument is positive. In case of a 32 bit
> system
> size_t m would be 4 bytes and read_write will automatically exit. In case
> of 64 bit
> system size_t m is 8 bytes and may turn to positive if the sign bit of the
> 32 bit value is 0.
> 
> If m is less than 0xffffffff80000000, dnsmasq will be exploited
> by a potential attacker who will remotely read dnsmasq heap until it
> crashes.
> If the above condition is not met, dnsmasq  exits properly.


Advisory:
https://www.obrela.com/home/security-labs/advisories/osi-advisory-osi-1502/

> Dnsmasq does not properly check the return value of the setup_reply()
> function called during a tcp connection (by the tcp_request() function).
> This return value is then used as a size argument in a function which writes
> data on the client’s connection.  This may lead, upon successful
> exploitation, to reading the heap memory of dnsmasq which will result to
> information disclosure such as performed DNS queries, encryption keys etc.
>  
> In more detail:
> Function tcp_request() calls setup_reply() and the returned value is used as
> a size argument in a write function.
>  
> m = setup_reply(header, (unsigned int)size, addrp, flags, daemon->local_ttl);
> read_write(confd, packet, m + sizeof(u16), 0));
>  
> The m variable is determined by a subtraction between the
> return of  skip_questions() and header pointer.
> The return value of skip_question doesn't checked for error(NULL).
> As a result the negative value of pointer(-header), might returned.
>  
> size_t setup_reply(struct dns_header *header, size_t qlen,
> struct all_addr *addrp, unsigned int flags, unsigned long ttl)
> {
>        unsigned char *p = skip_questions(header, qlen)
>        return p - (unsigned char *)header
> }
>  
> read_write checks if the size argument is positive. In case of a 32 bit
> system size_t m would be 4 bytes and read_write will automatically exit. In
> case of 64 bit system size_t m is 8 bytes and may turn to positive if the
> sign bit of the 32 bit value is 0.
>  
> If m is less than 0xffffffff80000000, dnsmasq will be exploited by a
> potential attacker who will remotely read dnsmasq heap. If the above
> condition is not met, dnsmasq exits properly.

Commit with fix:

commit ad4a8ff7d9097008d7623df8543df435bfddeac8
Author: Simon Kelley <simon@thekelleys.org.uk>
Date:   Thu Apr 9 21:48:00 2015 +0100

    Fix crash on receipt of certain malformed DNS requests.


References:
https://bugzilla.redhat.com/show_bug.cgi?id=1215747
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-3294
http://people.canonical.com/~ubuntu-security/cve/2015/CVE-2015-3294.html
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3294