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
| ||
|
Date: Thu, 28 Jan 2016 23:13:34 +0800 (GMT+08:00) From: "Zhouyi Zhou" <yizhouzhou@....ac.cn> To: "Florian Westphal" <fw@...len.de>, gnomes@...rguk.ukuu.org.uk, sergei.shtylyov@...entembedded.com Cc: "Zhouyi Zhou" <zhouzhouyi@...il.com>, eric.dumazet@...il.com, pablo@...filter.org, kaber@...sh.net, kadlec@...ckhole.kfki.hu, davem@...emloft.net, netfilter-devel@...r.kernel.org, coreteam@...filter.org, netdev@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: Re: [PATCH V2] netfilter: h323: avoid potential attack 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@...len.de> > Sent Time: Thursday, January 28, 2016 > To: "Zhouyi Zhou" <zhouzhouyi@...il.com> > Cc: eric.dumazet@...il.com, pablo@...filter.org, kaber@...sh.net, kadlec@...ckhole.kfki.hu, davem@...emloft.net, netfilter-devel@...r.kernel.org, coreteam@...filter.org, netdev@...r.kernel.org, linux-kernel@...r.kernel.or, "Zhouyi Zhou" <yizhouzhou@....ac.cn> > Subject: Re: [PATCH V2] netfilter: h323: avoid potential attack > > Zhouyi Zhou <zhouzhouyi@...il.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). >
Powered by blists - more mailing lists