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
