View Issue Details

IDProjectCategoryView StatusLast Update
0005968unrealircdpublic2021-10-03 10:56
Reportersyzop Assigned Tosyzop  
Status resolvedResolutionfixed 
Product Version5.2.1.1 
Fixed in Version5.2.2 
Summary0005968: new c-ares version
Descriptionc-ares has released 1.17.2 due to a security advisory
Additional InformationAn example domain which has a cname including a zero byte:

``` $ adig

Answers: 0 CNAME\\ 0 A ```

When resolved via a vulnerable implementation, the CNAME alias and name of the A record will seem to be instead of\, a totally different domain.

This is a clear error in zero-byte handling and can potentially lead to DNS-cache injections in case an application implements a cache based on the library.
TagsNo tags attached.
3rd party modules



2021-08-10 16:45

administrator   ~0022107

Last edited: 2021-08-10 16:46

I have tried to reproduce this issue in UnrealIRCd with spoofing with \000 both in PTR and in CNAME records.

With spoofing in PTR, eg\000cnamezero2.testnet.
then it behaves just like PTR to
and thus the reverse DNS will fail to resolve to the ip ( obviously does not point to me)
No risk.

With spoofing in CNAME, so PTR somevalidname and then somevalidname CNAME\000dev2.testnet.^@cnamezero2.testnet A 192.168.etc..
Then it will "succeed" but the displayed host is taken from the first query (PTR) so the hostname on IRC ends up being "somevalidname".
I remember fixing something like that ages ago, and making it use the first name instead of the second ;)
So no risk either.

So seemingly just a regular c-ares update for us with no security fixes / hurry for us. Oh yeah, it does fix some OpenBSD issue and I think i saw someone complain about failing to compile on OpenBSD before, could be fixed now...

Issue History

Date Modified Username Field Change
2021-08-10 16:42 syzop New Issue
2021-08-10 16:45 syzop Note Added: 0022107
2021-08-10 16:45 syzop Status new => acknowledged
2021-08-10 16:46 syzop Note Edited: 0022107
2021-10-03 10:56 syzop Assigned To => syzop
2021-10-03 10:56 syzop Status acknowledged => resolved
2021-10-03 10:56 syzop Resolution open => fixed
2021-10-03 10:56 syzop Fixed in Version => 5.2.2
2021-10-03 10:56 syzop View Status private => public