Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755054AbcCQGuP (ORCPT ); Thu, 17 Mar 2016 02:50:15 -0400 Received: from smtp25.cstnet.cn ([159.226.251.25]:56653 "EHLO cstnet.cn" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752728AbcCQGuM (ORCPT ); Thu, 17 Mar 2016 02:50:12 -0400 X-Greylist: delayed 416 seconds by postgrey-1.27 at vger.kernel.org; Thu, 17 Mar 2016 02:50:11 EDT Date: Thu, 17 Mar 2016 14:41:29 +0800 (GMT+08:00) From: "Zhouyi Zhou" To: "Pablo Neira Ayuso" Cc: "Zhouyi Zhou" , eric.dumazet@gmail.com, 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.org, fw@strlen.de, gnomes@lxorguk.ukuu.org.uk, sergei.shtylyov@cogentembedded.com Message-ID: <1b9fc79.23ab4.153834ebe7a.Coremail.yizhouzhou@ict.ac.cn> In-Reply-To: <20160312121902.GA2398@salvia> References: <1455984239-5807-1-git-send-email-zhouzhouyi@gmail.com> <20160312121902.GA2398@salvia> Subject: Re: Re: [PATCH V7] netfilter: h323: avoid potential attack MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Originating-IP: [159.226.43.96] X-Priority: 3 X-Mailer: Coremail Webmail Server Version XT2.1.11 dev build 20150107(58648.7033.6860) Copyright (c) 2002-2016 www.mailtech.cn cstnet X-SendMailWithSms: false X-CM-CTRLDATA: UAOrTGZvb3Rlcl90eHQ9MTc2Njo2 X-CM-TRANSID: SwCowJAbl_GZUepW9Q0aAA--.59785W X-CM-SenderInfo: x1l2x05x2k03g6lf3hldfou0/1tbiBgURAFNabuL7RAAAso X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VWxJw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1727 Lines: 45 Thanks Pablo for reviewing > From: "Pablo Neira Ayuso" > Sent Time: Saturday, March 12, 2016 > To: "Zhouyi Zhou" > On Sun, Feb 21, 2016 at 12:03:59AM +0800, Zhouyi Zhou wrote: > > I think hackers chould build a malicious h323 packet to overflow (iph->ihl * 4 + th->doff * 4); > You cannot trust the information that is available in the header. If > this is bogus this check will be defeated. That's why we pass this > protoff parameters to each function. The length of IP header is checked in the function nf_conntrack_in which calls get_l4proto hook to detect bogus ip header. There is no where in the call stack to the function set_addr to check bogus TCP header, and my code does the job: + th = (void *)iph + iph->ihl * 4; + datalen = skb->len - (iph->ihl * 4 + th->doff * 4); + /* check offset overflow */ + if (addroff > datalen) + return -1; if th->doff be too big addroff will greater than datalen. > > You also refer to get_h225_addr() in your description. That function > always copies 4 or 16 bytes, so I would appreciate if you can describe > the possible issue further. The problem of get_h225_addr lies in bogus taddr->ipAddress.ip, if this value is too big, it may make the pointer p point to no exist address. (gdb) list 686 681 struct h323_ct_state *ctstate) 682 { 683 const unsigned char *p; 684 int len; 685 686 switch (taddr->choice) { 687 case eTransportAddress_ipAddress: 688 if (nf_ct_l3num(ct) != AF_INET) 689 return 0; 690 p = data + taddr->ipAddress.ip; Thanks for your time and effort Cheers Zhouyi