netdev - Re: [PATCH nf-next 1/2] netlink: allow be16 and be32 types in all uint policy checks

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] [day] [month] [year] [list]

Date: Wed, 19 Jul 2023 09:19:24 +0200 (CEST)
From: Jozsef Kadlecsik <kadlec@...filter.org>
To: Florian Westphal <fw@...len.de>
cc: Jakub Kicinski <kuba@...nel.org>, netfilter-devel@...r.kernel.org, 
    Pablo Neira Ayuso <pablo@...filter.org>, Paolo Abeni <pabeni@...hat.com>, 
    Eric Dumazet <edumazet@...gle.com>, 
    "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH nf-next 1/2] netlink: allow be16 and be32 types in all
 uint policy checks

On Wed, 19 Jul 2023, Florian Westphal wrote:

> Jakub Kicinski <kuba@...nel.org> wrote:
> > On Tue, 18 Jul 2023 09:52:29 +0200 Florian Westphal wrote:
> > > __NLA_IS_BEINT_TYPE(tp) isn't useful.  NLA_BE16/32 are identical to
> > > NLA_U16/32, the only difference is that it tells the netlink validation
> > > functions that byteorder conversion might be needed before comparing
> > > the value to the policy min/max ones.
> > > 
> > > After this change all policy macros that can be used with UINT types,
> > > such as NLA_POLICY_MASK() can also be used with NLA_BE16/32.
> > > 
> > > This will be used to validate nf_tables flag attributes which
> > > are in bigendian byte order.
> > 
> > Semi-related, how well do we do with NLA_F_NET_BYTEORDER?
> 
> Looks incomplete at best.
> 
> > On a quick grep we were using it in the kernel -> user
> > direction but not validating on input. Is that right?
> 
> Looks like ipset is the only user, it sets it for kernel->user
> dir.
> 
> I see ipset userspace even sets it on user -> kernel dir but
> like you say, its not checked and BE encoding is assumed on
> kernel side.
> 
> From a quick glance in ipset all Uxx types are always treated as
> bigendian, which would mean things should not fall apart if ipset
> stops announcing NLA_F_NET_BYTEORDER.  Not sure its worth risking
> any breakage though.

Yes, ipset treats all uxx types as netorder.

It checks the presence of the NLA_F_NET_BYTEORDER, see the 
ip_set_attr_netorder() and ip_set_optattr_netorder() functions in 
include/linux/netfilter/ipset/ip_set.h which are then used at input 
validation.

The userspace tool also uses and checks the flag in lib/session.c, but it 
accepts hostorder as well.

> I suspect that in practice, given both producer and consumer need
> to agree of the meaning of type "12345" anyway its easier to just
> agree on the byte ordering as well.
> 
> Was there a specific reason for the question?
 
Best regards,
Jozsef
-
E-mail  : kadlec@...ckhole.kfki.hu, kadlecsik.jozsef@...ner.hu
PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics
          H-1525 Budapest 114, POB. 49, Hungary