While I'm in this part of the code, there is something that is
frightening me.
Imagine that you receive a DNS TXT reply with a packet that is crafted
with a sub-string length that is bigger than the record length. Here is
an example of such TXT RR:
0x04 "toto" 0xFF "crash?"
The first sub-string is fine, but with the second sub-string, the code
in ares_parse_txt.c (c-ares version 1.9.1) will have a bad behavior. The
loop line 146 will just compute a total length of 4+255=259 and the loop
line 164 can have two possible outcomes: crash or possible information leak.
IMHO, it's a security defect and I wonder how many other c-ares
functions are like that...
On 04/15/2013 10:29 AM, Patrick Valsecchi wrote:
> Hi,
>
> I'm using c-ares for doing DNS-SD. For that, I need to interpret TXT
> records formatted as specified in the DNS-SD spec [1]. Unfortunately,
> the ares_parse_txt_reply function just concatenates the sub-strings of
> the TXT record I get into a single string, loosing the information of
> the various key/value pairs contained in the TXT record.
>
> To fix that, I see two solutions:
>
> 1) provide a second function that parses the TXT records that doesn't
> parse the length+value sub-strings and lets the caller do this part of
> the parsing.
>
> 2) change ares_parse_txt_reply to return another ares_txt_reply node
> for each sub-string.
>
> I'd be happy to provide a patch for either solution.
>
> While I'm writing to this mailing list, I've seen some discussions in
> the archives about doing an implementation for mDNS. What is the
> status on that?
>
> Thanks for this nice library and have a nice day.
>
> [1]
> http://tools.ietf.org/html/draft-cheshire-dnsext-dns-sd-11#section-6.1
Received on 2013-04-15