netdev - Re: [PATCH nf 1/1] netfilter: h323,sip: Fix possible dead loop in nat_rtp_rtcp and nf_nat_sdp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+6hz4qO2Le_DCyuFt9zGnq2+TcR_GaDxXvSN_=1KOXYZti+iQ@mail.gmail.com>
Date:   Thu, 2 Mar 2017 18:18:44 +0800
From:   Gao Feng <fgao@...ai8.com>
To:     Liping Zhang <zlpnobody@...il.com>
Cc:     Pablo Neira Ayuso <pablo@...filter.org>,
        Jozsef Kadlecsik <kadlec@...ckhole.kfki.hu>,
        David Miller <davem@...emloft.net>,
        Netfilter Developer Mailing List 
        <netfilter-devel@...r.kernel.org>, coreteam@...filter.org,
        Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: [PATCH nf 1/1] netfilter: h323,sip: Fix possible dead loop in
 nat_rtp_rtcp and nf_nat_sdp_media

Hi Liping,

On Thu, Mar 2, 2017 at 4:50 PM, Liping Zhang <zlpnobody@...il.com> wrote:
> Hi,
>
> 2017-03-02 15:57 GMT+08:00  <fgao@...ai8.com>:
>> From: Gao Feng <fgao@...ai8.com>
>>
>> When h323 and sip try to insert expect nodes, they would increase
>> the port by 2 for loop, and the loop condition is that "port != 0".
>> So when the start port is odd number, port never increases to zero.
>
> This seems will never happen, since the RTP port has been ensured to
> be even.
>
> For example, at expect_rtp_rtcp():
>    ...
>    /* RTP port is even */
>    rtp_port = port & ~htons(1);
>    rtcp_port = port | htons(1);
>
> And at set_expected_rtp_rtcp():
>    ...
>    base_port = ntohs(tuple.dst.u.udp.port) & ~1;
>    rtp_port = htons(base_port);

Thanks your point, I actually did not attention these codes you mentioned.
But I checked the other codes, I think the dangerous may exist.

The expect class is NF_CT_EXPECT_CLASS_DEFAULT, and proto is
IPPROTO_UDP at the function "expect_rtp_rtcp",
And it makes sure the port is even number.

But look at the process_gcf, the port is got from the packet data at
function get_h225_addr.
So it may be odd number.
It also would add one expect node whose class is
NF_CT_EXPECT_CLASS_DEFAULT, and proto is IPPROTO_UDP.

BTW, the loop in nat_rtp_rtcp and nat_rtp_rtcp depend on one potential
condition which is protected by other functions.
It doesn't seem a good style.

Regards
Feng