Kernel-hardening archive on lore.kernel.org
 help / color / Atom feed
* Re: [PATCH 12/26] netfilter: switch nf_setsockopt to sockptr_t
       [not found]     ` <20200727150601.GA3447@lst.de>
@ 2020-07-27 16:16       ` Jason A. Donenfeld
  2020-07-27 16:23         ` Christoph Hellwig
  0 siblings, 1 reply; 4+ messages in thread
From: Jason A. Donenfeld @ 2020-07-27 16:16 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: David S. Miller, Jakub Kicinski, Alexei Starovoitov,
	Daniel Borkmann, Alexey Kuznetsov, Hideaki YOSHIFUJI,
	Eric Dumazet, Linux Crypto Mailing List, LKML, Netdev, bpf,
	netfilter-devel, coreteam, linux-sctp, linux-hams,
	linux-bluetooth, bridge, linux-can, dccp, linux-decnet-user,
	linux-wpan, linux-s390, mptcp, lvs-devel, rds-devel, linux-afs,
	tipc-discussion, linux-x25, Kernel Hardening

On Mon, Jul 27, 2020 at 5:06 PM Christoph Hellwig <hch@lst.de> wrote:
>
> On Mon, Jul 27, 2020 at 05:03:10PM +0200, Jason A. Donenfeld wrote:
> > Hi Christoph,
> >
> > On Thu, Jul 23, 2020 at 08:08:54AM +0200, Christoph Hellwig wrote:
> > > diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
> > > index da933f99b5d517..42befbf12846c0 100644
> > > --- a/net/ipv4/ip_sockglue.c
> > > +++ b/net/ipv4/ip_sockglue.c
> > > @@ -1422,7 +1422,8 @@ int ip_setsockopt(struct sock *sk, int level,
> > >                     optname != IP_IPSEC_POLICY &&
> > >                     optname != IP_XFRM_POLICY &&
> > >                     !ip_mroute_opt(optname))
> > > -           err = nf_setsockopt(sk, PF_INET, optname, optval, optlen);
> > > +           err = nf_setsockopt(sk, PF_INET, optname, USER_SOCKPTR(optval),
> > > +                               optlen);
> > >  #endif
> > >     return err;
> > >  }
> > > diff --git a/net/ipv4/netfilter/ip_tables.c b/net/ipv4/netfilter/ip_tables.c
> > > index 4697d09c98dc3e..f2a9680303d8c0 100644
> > > --- a/net/ipv4/netfilter/ip_tables.c
> > > +++ b/net/ipv4/netfilter/ip_tables.c
> > > @@ -1102,7 +1102,7 @@ __do_replace(struct net *net, const char *name, unsigned int valid_hooks,
> > >  }
> > >
> > >  static int
> > > -do_replace(struct net *net, const void __user *user, unsigned int len)
> > > +do_replace(struct net *net, sockptr_t arg, unsigned int len)
> > >  {
> > >     int ret;
> > >     struct ipt_replace tmp;
> > > @@ -1110,7 +1110,7 @@ do_replace(struct net *net, const void __user *user, unsigned int len)
> > >     void *loc_cpu_entry;
> > >     struct ipt_entry *iter;
> > >
> > > -   if (copy_from_user(&tmp, user, sizeof(tmp)) != 0)
> > > +   if (copy_from_sockptr(&tmp, arg, sizeof(tmp)) != 0)
> > >             return -EFAULT;
> > >
> > >     /* overflow check */
> > > @@ -1126,8 +1126,8 @@ do_replace(struct net *net, const void __user *user, unsigned int len)
> > >             return -ENOMEM;
> > >
> > >     loc_cpu_entry = newinfo->entries;
> > > -   if (copy_from_user(loc_cpu_entry, user + sizeof(tmp),
> > > -                      tmp.size) != 0) {
> > > +   sockptr_advance(arg, sizeof(tmp));
> > > +   if (copy_from_sockptr(loc_cpu_entry, arg, tmp.size) != 0) {
> > >             ret = -EFAULT;
> > >             goto free_newinfo;
> > >     }
> >
> > Something along this path seems to have broken with this patch. An
> > invocation of `iptables -A INPUT -m length --length 1360 -j DROP` now
> > fails, with
> >
> > nf_setsockopt->do_replace->translate_table->check_entry_size_and_hooks:
> >   (unsigned char *)e + e->next_offset > limit  ==>  TRUE
> >
> > resulting in the whole call chain returning -EINVAL. It bisects back to
> > this commit. This is on net-next.
>
> This is another use o sockptr_advance that Ido already found a problem
> in.  I'm looking into this at the moment..

I haven't seen Ido's patch, but it seems clear the issue is that you
want to call `sockptr_advance(&arg, sizeof(tmp))`, and adjust
sockptr_advance to take a pointer.

Slight concern about the whole concept:

Things are defined as

typedef union {
        void            *kernel;
        void __user     *user;
} sockptr_t;
static inline bool sockptr_is_kernel(sockptr_t sockptr)
{
        return (unsigned long)sockptr.kernel >= TASK_SIZE;
}

So what happens if we have some code like:

sockptr_t sp;
init_user_sockptr(&sp, user_controlled_struct.extra_user_ptr);
sockptr_advance(&sp, user_controlled_struct.some_big_offset);
copy_to_sockptr(&sp, user_controlled_struct.a_few_bytes,
sizeof(user_controlled_struct.a_few_bytes));

With the user controlling some_big_offset, he can convert the user
sockptr into a kernel sockptr, causing the subsequent copy_to_sockptr
to be a vanilla memcpy, after which a security disaster ensues.

Maybe sockptr_advance should have some safety checks and sometimes
return -EFAULT? Or you should always use the implementation where
being a kernel address is an explicit bit of sockptr_t, rather than
being implicit?

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH 12/26] netfilter: switch nf_setsockopt to sockptr_t
  2020-07-27 16:16       ` [PATCH 12/26] netfilter: switch nf_setsockopt to sockptr_t Jason A. Donenfeld
@ 2020-07-27 16:23         ` Christoph Hellwig
  2020-07-28  8:07           ` David Laight
  0 siblings, 1 reply; 4+ messages in thread
From: Christoph Hellwig @ 2020-07-27 16:23 UTC (permalink / raw)
  To: Jason A. Donenfeld
  Cc: Christoph Hellwig, David S. Miller, Jakub Kicinski,
	Alexei Starovoitov, Daniel Borkmann, Alexey Kuznetsov,
	Hideaki YOSHIFUJI, Eric Dumazet, Linux Crypto Mailing List, LKML,
	Netdev, bpf, netfilter-devel, coreteam, linux-sctp, linux-hams,
	linux-bluetooth, bridge, linux-can, dccp, linux-decnet-user,
	linux-wpan, linux-s390, mptcp, lvs-devel, rds-devel, linux-afs,
	tipc-discussion, linux-x25, Kernel Hardening

On Mon, Jul 27, 2020 at 06:16:32PM +0200, Jason A. Donenfeld wrote:
> Maybe sockptr_advance should have some safety checks and sometimes
> return -EFAULT? Or you should always use the implementation where
> being a kernel address is an explicit bit of sockptr_t, rather than
> being implicit?

I already have a patch to use access_ok to check the whole range in
init_user_sockptr.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* RE: [PATCH 12/26] netfilter: switch nf_setsockopt to sockptr_t
  2020-07-27 16:23         ` Christoph Hellwig
@ 2020-07-28  8:07           ` David Laight
  2020-07-28  8:17             ` Jason A. Donenfeld
  0 siblings, 1 reply; 4+ messages in thread
From: David Laight @ 2020-07-28  8:07 UTC (permalink / raw)
  To: 'Christoph Hellwig', Jason A. Donenfeld
  Cc: David S. Miller, Jakub Kicinski, Alexei Starovoitov,
	Daniel Borkmann, Alexey Kuznetsov, Hideaki YOSHIFUJI,
	Eric Dumazet, Linux Crypto Mailing List, LKML, Netdev, bpf,
	netfilter-devel, coreteam, linux-sctp, linux-hams,
	linux-bluetooth, bridge, linux-can, dccp, linux-decnet-user,
	linux-wpan, linux-s390, mptcp, lvs-devel, rds-devel, linux-afs,
	tipc-discussion, linux-x25, Kernel Hardening

From: Christoph Hellwig
> Sent: 27 July 2020 17:24
> 
> On Mon, Jul 27, 2020 at 06:16:32PM +0200, Jason A. Donenfeld wrote:
> > Maybe sockptr_advance should have some safety checks and sometimes
> > return -EFAULT? Or you should always use the implementation where
> > being a kernel address is an explicit bit of sockptr_t, rather than
> > being implicit?
> 
> I already have a patch to use access_ok to check the whole range in
> init_user_sockptr.

That doesn't make (much) difference to the code paths that ignore
the user-supplied length.
OTOH doing the user/kernel check on the base address (not an
incremented one) means that the correct copy function is always
selected.

Perhaps the functions should all be passed a 'const sockptr_t'.
The typedef could be made 'const' - requiring non-const items
explicitly use the union/struct itself.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH 12/26] netfilter: switch nf_setsockopt to sockptr_t
  2020-07-28  8:07           ` David Laight
@ 2020-07-28  8:17             ` Jason A. Donenfeld
  0 siblings, 0 replies; 4+ messages in thread
From: Jason A. Donenfeld @ 2020-07-28  8:17 UTC (permalink / raw)
  To: David Laight
  Cc: Christoph Hellwig, David S. Miller, Jakub Kicinski,
	Alexei Starovoitov, Daniel Borkmann, Alexey Kuznetsov,
	Hideaki YOSHIFUJI, Eric Dumazet, Linux Crypto Mailing List, LKML,
	Netdev, bpf, netfilter-devel, coreteam, linux-sctp, linux-hams,
	linux-bluetooth, bridge, linux-can, dccp, linux-decnet-user,
	linux-wpan, linux-s390, mptcp, lvs-devel, rds-devel, linux-afs,
	tipc-discussion, linux-x25, Kernel Hardening

On Tue, Jul 28, 2020 at 10:07 AM David Laight <David.Laight@aculab.com> wrote:
>
> From: Christoph Hellwig
> > Sent: 27 July 2020 17:24
> >
> > On Mon, Jul 27, 2020 at 06:16:32PM +0200, Jason A. Donenfeld wrote:
> > > Maybe sockptr_advance should have some safety checks and sometimes
> > > return -EFAULT? Or you should always use the implementation where
> > > being a kernel address is an explicit bit of sockptr_t, rather than
> > > being implicit?
> >
> > I already have a patch to use access_ok to check the whole range in
> > init_user_sockptr.
>
> That doesn't make (much) difference to the code paths that ignore
> the user-supplied length.
> OTOH doing the user/kernel check on the base address (not an
> incremented one) means that the correct copy function is always
> selected.

Right, I had the same reaction in reading this, but actually, his code
gets rid of the sockptr_advance stuff entirely and never mutates, so
even though my point about attacking those pointers was missed, the
code does the better thing now -- checking the base address and never
mutating the pointer. So I think we're good.

>
> Perhaps the functions should all be passed a 'const sockptr_t'.
> The typedef could be made 'const' - requiring non-const items
> explicitly use the union/struct itself.

I was thinking the same, but just by making the pointers inside the
struct const. However, making the whole struct const via the typedef
is a much better idea. That'd probably require changing the signature
of init_user_sockptr a bit, which would be fine, but indeed I think
this would be a very positive change.

Jason

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, back to index

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20200723060908.50081-1-hch@lst.de>
     [not found] ` <20200723060908.50081-13-hch@lst.de>
     [not found]   ` <20200727150310.GA1632472@zx2c4.com>
     [not found]     ` <20200727150601.GA3447@lst.de>
2020-07-27 16:16       ` [PATCH 12/26] netfilter: switch nf_setsockopt to sockptr_t Jason A. Donenfeld
2020-07-27 16:23         ` Christoph Hellwig
2020-07-28  8:07           ` David Laight
2020-07-28  8:17             ` Jason A. Donenfeld

Kernel-hardening archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/kernel-hardening/0 kernel-hardening/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 kernel-hardening kernel-hardening/ https://lore.kernel.org/kernel-hardening \
		kernel-hardening@lists.openwall.com
	public-inbox-index kernel-hardening

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/com.openwall.lists.kernel-hardening


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git