[asterisk-bugs] [JIRA] (ASTERISK-28127) Buffer overflow for DNS SRV/NAPTR records

[Asterisk Team (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-28127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Asterisk Team updated ASTERISK-28127:
-------------------------------------

    Target Release Version/s: 17.0.0

> Buffer overflow for DNS SRV/NAPTR records
> -----------------------------------------
>
>                 Key: ASTERISK-28127
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28127
>             Project: Asterisk
>          Issue Type: Security
>      Security Level: None
>          Components: Core/DNS
>    Affects Versions: 16.0.0
>            Reporter: Jan Hoffmann
>            Severity: Blocker
>              Labels: patch, security
>      Target Release: 15.6.2, 15.7.0, 16.0.1, 16.1.0, 17.0.0
>
>         Attachments: patch.diff, patch.diff
>
>
> There is a possible buffer overflow in {{dns_srv_alloc}} and {{dns_naptr_alloc}} when a SRV/NAPTR record contains a compressed domain name. I am using Asterisk 16, but it looks like this issue exists since Asterisk 14.
> In both functions, {{dn_expand}} is used to expand a compressed domain name. The return value is used to calculate the size of the buffer for the {{ast_dns_srv_record}} / {{ast_dns_naptr_record}} struct, where the expanded domain name will be stored. However, the return value of {{dn_expand}} is actually the length of the compressed domain name, so this can lead to a buffer overflow.
> This can be fixed by using the actual string length of the expanded domain name instead of the return value of {{dn_expand}} to calculate the buffer size.
> The specific case where this bug occurred for me is {{_sip._udp.tel.t-online.de}}, which resolves to the following here:
> {noformat}
> _sip._udp.tel.t-online.de. 325	IN	SRV	10 0 5060 do-epp-801.edns.t-ipnet.de.
> _sip._udp.tel.t-online.de. 325	IN	SRV	20 0 5060 h2-epp-801.edns.t-ipnet.de.
> {noformat}
> For the first record, the first three labels of the name are encoded directly. Only the last label ({{de}}) is encoded as a reference. In this case, the length of the compressed name happens to be identical to length of the expanded name at 26 bytes. Contents of the data parameter (domain name starts at 7th byte):
> {noformat}
> 00 0A 00 00 13 C4 0A 64 6F 2D 65 70 70 2D 38 30 31 04 65 64 6E 73 07 74 2D 69 70 6E 65 74 C0 23
> {noformat}
> For the second record, only the first label ({{h2-epp-801}}) is encoded directly, and the rest is a reference. The expanded name has a length of 26 bytes, while the compressed name is only 13 bytes long. Contents of the data parameter (domain name starts at 7th byte):
> {noformat}
> 00 14 00 00 13 C4 0A 68 32 2D 65 70 70 2D 38 30 31 C0 48
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)