linux-kernel - Re: [PATCH 1/1] netfilter: nat: add range checks for access to nf_nat

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: <20200731002611.GA1035680@google.com>
Date:   Fri, 31 Jul 2020 00:26:11 +0000
From:   William Mcvicker <willmcvicker@...gle.com>
To:     Pablo Neira Ayuso <pablo@...filter.org>
Cc:     security@...nel.org, Jozsef Kadlecsik <kadlec@...ckhole.kfki.hu>,
        Florian Westphal <fw@...len.de>,
        "David S. Miller" <davem@...emloft.net>,
        Alexey Kuznetsov <kuznet@....inr.ac.ru>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        netfilter-devel@...r.kernel.org, coreteam@...filter.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        kernel-team@...roid.com
Subject: Re: [PATCH 1/1] netfilter: nat: add range checks for access to
 nf_nat_l[34]protos[]

Hi Pablo,

Yes, I believe this oops is only triggered by userspace when the user
specifically passes in an invalid nf_nat_l3protos index. I'm happy to re-work
the patch to check for this in ctnetlink_create_conntrack().

> BTW, do you have a Fixes: tag for this? This will be useful for
> -stable maintainer to pick up this fix.

Regarding the Fixes: tag, I don't have one offhand since this bug was reported
to me, but I can search through the code history to find the commit that
exposed this vulnerability.

Thanks,
Will

On 07/29/2020, Pablo Neira Ayuso wrote:
> Hi Will,
> 
> On Mon, Jul 27, 2020 at 05:57:20PM +0000, Will McVicker wrote:
> > The indexes to the nf_nat_l[34]protos arrays come from userspace. So we
> > need to make sure that before indexing the arrays, we verify the index
> > is within the array bounds in order to prevent an OOB memory access.
> > Here is an example kernel panic on 4.14.180 when userspace passes in an
> > index greater than NFPROTO_NUMPROTO.
> > 
> > Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
> > Modules linked in:...
> > Process poc (pid: 5614, stack limit = 0x00000000a3933121)
> > CPU: 4 PID: 5614 Comm: poc Tainted: G S      W  O    4.14.180-g051355490483
> > Hardware name: Qualcomm Technologies, Inc. SM8150 V2 PM8150 Google Inc. MSM
> > task: 000000002a3dfffe task.stack: 00000000a3933121
> > pc : __cfi_check_fail+0x1c/0x24
> > lr : __cfi_check_fail+0x1c/0x24
> > ...
> > Call trace:
> > __cfi_check_fail+0x1c/0x24
> > name_to_dev_t+0x0/0x468
> > nfnetlink_parse_nat_setup+0x234/0x258
> 
> If this oops is only triggerable from userspace, I think a sanity
> check in nfnetlink_parse_nat_setup should suffice to reject
> unsupported layer 3 and layer 4 protocols.
> 
> I mean, in this patch I see more chunks in the packet path, such as
> nf_nat_l3proto_ipv4 that should never happen. I would just fix the
> userspace ctnetlink path.
> 
> BTW, do you have a Fixes: tag for this? This will be useful for
> -stable maintainer to pick up this fix.
> 
> Thanks.