[PATCH V2] netfilter: h323: avoid potential attack

[PATCH V2] netfilter: h323: avoid potential attack

[Zhouyi Zhou]

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>
---
 net/netfilter/nf_conntrack_h323_main.c |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/net/netfilter/nf_conntrack_h323_main.c b/net/netfilter/nf_conntrack_h323_main.c
index 9511af0..ccd08c5 100644
--- a/net/netfilter/nf_conntrack_h323_main.c
+++ b/net/netfilter/nf_conntrack_h323_main.c
@@ -110,6 +110,7 @@ int (*nat_q931_hook) (struct sk_buff *skb,
 
 static DEFINE_SPINLOCK(nf_h323_lock);
 static char *h323_buffer;
+#define CHECK_BOUND(p, n) ((void *)p + n - (void *)h323_buffer > 65536)
 
 static struct nf_conntrack_helper nf_conntrack_helper_h245;
 static struct nf_conntrack_helper nf_conntrack_helper_q931[];
@@ -247,6 +248,9 @@ static int get_h245_addr(struct nf_conn *ct, const unsigned char *data,
 		return 0;
 	}
 
+	if (CHECK_BOUND(p, len + sizeof(__be16)))
+		return 0;
+
 	memcpy(addr, p, len);
 	memset((void *)addr + len, 0, sizeof(*addr) - len);
 	memcpy(port, p + len, sizeof(__be16));
@@ -669,6 +673,9 @@ int get_h225_addr(struct nf_conn *ct, unsigned char *data,
 		return 0;
 	}
 
+	if (CHECK_BOUND(p, len + sizeof(__be16)))
+		return 0;
+
 	memcpy(addr, p, len);
 	memset((void *)addr + len, 0, sizeof(*addr) - len);
 	memcpy(port, p + len, sizeof(__be16));
-- 
1.7.10.4

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

[Eric Dumazet]

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.

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

[Zhouyi Zhou]

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

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

[Eric Dumazet]

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.

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

[Eric Dumazet]

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()

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

[One Thousand Gnomes]

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

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

[Sergei Shtylyov]

Hello.

On 1/28/2016 11:59 AM, 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>
> ---
>   net/netfilter/nf_conntrack_h323_main.c |    7 +++++++
>   1 file changed, 7 insertions(+)
>
> diff --git a/net/netfilter/nf_conntrack_h323_main.c b/net/netfilter/nf_conntrack_h323_main.c
> index 9511af0..ccd08c5 100644
> --- a/net/netfilter/nf_conntrack_h323_main.c
> +++ b/net/netfilter/nf_conntrack_h323_main.c
> @@ -110,6 +110,7 @@ int (*nat_q931_hook) (struct sk_buff *skb,
>
>   static DEFINE_SPINLOCK(nf_h323_lock);
>   static char *h323_buffer;
> +#define CHECK_BOUND(p, n) ((void *)p + n - (void *)h323_buffer > 65536)

    You have to enclose the macro parameters in parens when used in expression.

MBR, Sergei

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

[Florian Westphal]

Zhouyi Zhou <zhouzhouyi@gmail.com> 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;

Can you be more specific?

h323_buffer is backend storage for skb_header_pointer, i.e.
this will error out early when we ask for more data than is available in
packet.

I don't understand how this could overflow anything.
Even assuming 64k packet we'd still have enough room in h323_buffer
for an ipv6 address, no? (we skip the l3/l4 header when extracting
packet payload).

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

[Zhouyi Zhou]

Thanks for your advices.
I will take your advice if I could have the opportunity
to write the final code.

As matter of factor, I trigger this bug when I tried to 
migrate H323 code to other operating systems.

This could trigger a panic because get_h2x5_addr functions
is the first time we ever try to ask for potentially
out of range data because of H323 style decodings 
(the value taddr->ipAddress.ip is decoded in the midway between
calling skb_header_pointer and calling get_h2x5_addr)



> -----Original Messages-----
> From: "Florian Westphal" <fw@strlen.de>
> Sent Time: Thursday, January 28, 2016
> To: "Zhouyi Zhou" <zhouzhouyi@gmail.com>
> Cc: eric.dumazet@gmail.com, 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
> 
> Zhouyi Zhou <zhouzhouyi@gmail.com> 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;
> 
> Can you be more specific?
> 
> h323_buffer is backend storage for skb_header_pointer, i.e.
> this will error out early when we ask for more data than is available in
> packet.
> 
> I don't understand how this could overflow anything.
> Even assuming 64k packet we'd still have enough room in h323_buffer
> for an ipv6 address, no? (we skip the l3/l4 header when extracting
> packet payload).
>