Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1320673 > unrolled thread

Re: Re: [PATCH V2] netfilter: h323: avoid potential attack

Started by"Zhouyi Zhou" <yizhouzhou@ict.ac.cn>
First post2016-01-28 14:30 +0100
Last post2016-01-28 15:20 +0100
Articles 4 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Re: [PATCH V2] netfilter: h323: avoid potential attack "Zhouyi Zhou" <yizhouzhou@ict.ac.cn> - 2016-01-28 14:30 +0100
    Re: Re: [PATCH V2] netfilter: h323: avoid potential attack Eric Dumazet <eric.dumazet@gmail.com> - 2016-01-28 15:10 +0100
      Re: Re: [PATCH V2] netfilter: h323: avoid potential attack Eric Dumazet <eric.dumazet@gmail.com> - 2016-01-28 15:10 +0100
      Re: [PATCH V2] netfilter: h323: avoid potential attack One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-01-28 15:20 +0100

#1320673 — Re: Re: [PATCH V2] netfilter: h323: avoid potential attack

From"Zhouyi Zhou" <yizhouzhou@ict.ac.cn>
Date2016-01-28 14:30 +0100
SubjectRe: Re: [PATCH V2] netfilter: h323: avoid potential attack
Message-ID<qVUO6-3Yo-27@gated-at.bofh.it>
Thanks Eric for replying
> -----Original Messages-----
> From: "Eric Dumazet" <eric.dumazet@gmail.com>
> Sent Time: Thursday, January 28, 2016
> To: "Zhouyi Zhou" <zhouzhouyi@gmail.com>
> Cc: pablo@netfilter.org, kaber@trash.net, kadlec@blackhole.kfki.hu, davem@davemloft.net, netfilter-devel@vger.kernel.org, coreteam@netfilter.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.or, "Zhouyi Zhou" <yizhouzhou@ict.ac.cn>
> Subject: Re: [PATCH V2] netfilter: h323: avoid potential attack
> 
> On Thu, 2016-01-28 at 16:59 +0800, Zhouyi Zhou wrote:
> > Thanks Eric for your review and advice.
> > 
> > I think hackers chould build a malicious h323 packet to overflow
> > the pointer p which will panic during the memcpy(addr, p, len)
> > 
> > For example, he may fabricate a very large taddr->ipAddress.ip;
> > 
> > Signed-off-by: Zhouyi Zhou <yizhouzhou@ict.ac.cn>
> > ---
> 
> Except you did not address my feedback about potentially reading not
> initialized memory.
> 
> if the frame length was 1000 bytes, then surely accessing memory at
> offset 8000 will either read garbage, or read data from a prior frame
> and leak secrets.
My patch is intend to prevent kernel panic, to prevent reading garbage
or read data from a prior frame and leak secrets, the prototypes of the 
get_h2x5_addr functions and the functions that call get_h2x5_addr should
be changed, should we do this? 
> 
> 
> 
Cheers 
Zhouyi

[toc] | [next] | [standalone]


#1320707

FromEric Dumazet <eric.dumazet@gmail.com>
Date2016-01-28 15:10 +0100
Message-ID<qVVqO-4wq-7@gated-at.bofh.it>
In reply to#1320673
On Thu, 2016-01-28 at 21:14 +0800, Zhouyi Zhou wrote:

> My patch is intend to prevent kernel panic, to prevent reading garbage
> or read data from a prior frame and leak secrets, the prototypes of the 
> get_h2x5_addr functions and the functions that call get_h2x5_addr should
> be changed, should we do this? 

In term of security, panics are better than allowing attacker to read
data from other people, like a password.

BTW, are you able to trigger any panic ?

I am not familiar with this code, it is not obvious.

If a fix is needed, better doing it right.

[toc] | [prev] | [next] | [standalone]


#1320713

FromEric Dumazet <eric.dumazet@gmail.com>
Date2016-01-28 15:10 +0100
Message-ID<qVVqP-4wq-29@gated-at.bofh.it>
In reply to#1320707
On Thu, 2016-01-28 at 06:00 -0800, Eric Dumazet wrote:
> On Thu, 2016-01-28 at 21:14 +0800, Zhouyi Zhou wrote:
> 
> > My patch is intend to prevent kernel panic, to prevent reading garbage
> > or read data from a prior frame and leak secrets, the prototypes of the 
> > get_h2x5_addr functions and the functions that call get_h2x5_addr should
> > be changed, should we do this? 
> 
> In term of security, panics are better than allowing attacker to read
> data from other people, like a password.
> 
> BTW, are you able to trigger any panic ?
> 
> I am not familiar with this code, it is not obvious.
> 
> If a fix is needed, better doing it right.
> 


BTW, this module is protected by a lock (nf_h323_lock)

So adding a variable like 'h323_buffer_valid_bytes' that would contain
the number of valid bytes would not require to change prototypes.

This variable would be written when skb_header_pointer() is used in
get_tpkt_data() / get_udp_data()

[toc] | [prev] | [next] | [standalone]


#1320716

FromOne Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Date2016-01-28 15:20 +0100
Message-ID<qVVAt-4Ce-3@gated-at.bofh.it>
In reply to#1320707
On Thu, 28 Jan 2016 06:00:50 -0800
Eric Dumazet <eric.dumazet@gmail.com> wrote:

> On Thu, 2016-01-28 at 21:14 +0800, Zhouyi Zhou wrote:
> 
> > My patch is intend to prevent kernel panic, to prevent reading garbage
> > or read data from a prior frame and leak secrets, the prototypes of the 
> > get_h2x5_addr functions and the functions that call get_h2x5_addr should
> > be changed, should we do this?   
> 
> In term of security, panics are better than allowing attacker to read
> data from other people, like a password.
> 
> BTW, are you able to trigger any panic ?

We have a smattering of panics in this code in bugzilla going back years.

https://bugzilla.kernel.org/show_bug.cgi?id=12473

etc

Alan

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web