netdev - Re: [PATCH net 1/3] netfilter: synproxy: Fix out of bounds when parsing TCP options

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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 10 Jun 2021 10:56:07 +0200
From:   Florian Westphal <fw@...len.de>
To:     Maxim Mikityanskiy <maximmi@...dia.com>
Cc:     Florian Westphal <fw@...len.de>,
        Mat Martineau <mathew.j.martineau@...ux.intel.com>,
        Matthieu Baerts <matthieu.baerts@...sares.net>,
        Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Pablo Neira Ayuso <pablo@...filter.org>,
        Jozsef Kadlecsik <kadlec@...filter.org>,
        Toke Høiland-Jørgensen <toke@...e.dk>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Jiri Pirko <jiri@...nulli.us>,
        Patrick McHardy <kaber@...sh.net>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Paolo Abeni <pabeni@...hat.com>,
        Christoph Paasch <cpaasch@...le.com>,
        Peter Krystad <peter.krystad@...ux.intel.com>,
        Young Xiao <92siuyang@...il.com>, netdev@...r.kernel.org
Subject: Re: [PATCH net 1/3] netfilter: synproxy: Fix out of bounds when
 parsing TCP options

Maxim Mikityanskiy <maximmi@...dia.com> wrote:
> On 2021-06-09 17:51, Florian Westphal wrote:
> > Maxim Mikityanskiy <maximmi@...dia.com> wrote:
> > > The TCP option parser in synproxy (synproxy_parse_options) could read
> > > one byte out of bounds. When the length is 1, the execution flow gets
> > > into the loop, reads one byte of the opcode, and if the opcode is
> > > neither TCPOPT_EOL nor TCPOPT_NOP, it reads one more byte, which exceeds
> > > the length of 1.
> > > 
> > > This fix is inspired by commit 9609dad263f8 ("ipv4: tcp_input: fix stack
> > > out of bounds when parsing TCP options.").
> > > 
> > > Cc: Young Xiao <92siuyang@...il.com>
> > > Fixes: 48b1de4c110a ("netfilter: add SYNPROXY core/target")
> > > Signed-off-by: Maxim Mikityanskiy <maximmi@...dia.com>
> > > ---
> > >   net/netfilter/nf_synproxy_core.c | 2 ++
> > >   1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/net/netfilter/nf_synproxy_core.c b/net/netfilter/nf_synproxy_core.c
> > > index b100c04a0e43..621eb5ef9727 100644
> > > --- a/net/netfilter/nf_synproxy_core.c
> > > +++ b/net/netfilter/nf_synproxy_core.c
> > > @@ -47,6 +47,8 @@ synproxy_parse_options(const struct sk_buff *skb, unsigned int doff,
> > >   			length--;
> > >   			continue;
> > >   		default:
> > > +			if (length < 2)
> > > +				return true;
> > 
> > Would you mind a v2 that also rejects bogus th->doff value when
> > computing the length?
> 
> Could you elaborate? The length is a signed int calculated as `(th->doff *
> 4) - sizeof(*th)`. Invalid doff values (0..4) lead to negative length, so we
> never enter the loop. Or are you concerned of passing a negative length to
> skb_header_pointer?

Yes, negative length to skb_header_pointer.  For other usage (mptcp for
example) tcp stack validated th->doff already, but thats not the case for synproxy.