Attachment 16420 Details for Bug 50449

full vendor-sec discussion

ether.txt (text/plain), 12.68 KB, created by Thomas Biege on 2004-03-08 19:33:38 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Thomas Biege

Created: 2004-03-08 19:33:38 UTC

Size: 12.68 KB

patch

obsolete

>From s.esser@e-matters.de Mon Mar  8 12:28:48 2004
>Date: Sat, 6 Mar 2004 09:45:16 +0100
>From: Stefan Esser <s.esser@e-matters.de>
>To: vendor-sec@lst.de
>Subject: [vendor-sec] 10 x Ethereal Overflows
>
>Hi,
>
>I just wanted to pre-notify you. Yesterday I submitted the
>following 10 bugs (only shortname) to the ethereal devs
>and meanwhile 7/10 bugs are fixed in their CVS. The other
>3 need further investigation in the protocol specs for
>the correct way of fixing.
>
>[01] Netflow Protocol Dissector Overflow
>[02] IGAP Protocol Dissector Account Overflow
>[03] IGAP Protocol Dissector Message Overflow
>[04] EIGRP Protocol TLV_IP_INT Long IP Address Overflow
>[05] EIGRP Protocol TLV_IP_EXT Long IP Address Overflow
>[06] PGM Protocol NakList Overflow
>[07] IRDA Protocol Plugin IRCOM_PORT_NAME Overflow
>[08] BGP Protocol MPLS Label Overflow
>[09] ISUP Protocol INTERWORKING FUNCTION ADDRESS Overflow
>[10] TCAP Protocol TID Overflow
>
>All of these bugs are stackoverflows that are nearly all caused
>by missing boundary checks and in one case by an integer 
>underflow. With exception of [06][07][08] they allow code execution.
>In [06] and [08] the overflow is quite small and therefore it seems 
>not exploitable (in the sense of code execution) on atleast the x86)
>[07] was not further tested and is an off-by-two on the stack.
>")\0" are written.
>
>Due to the fact that not all bugs are fixed yet I cannot tell
>you when we are about to release. If you want details you can
>either contact me directly or look into the Ethereal CVS.
>
>Greetings,
>Stefan Esser
>
>-- 
>
>--------------------------------------------------------------------------
> Stefan Esser                                        s.esser@e-matters.de
> e-matters Security                         http://security.e-matters.de/
>
> GPG-Key                gpg --keyserver pgp.mit.edu --recv-key 0xCF6CAE69 
> Key fingerprint       B418 B290 ACC0 C8E5 8292  8B72 D6B0 7704 CF6C AE69
>--------------------------------------------------------------------------
> Did I help you? Consider a gift:            http://wishlist.suspekt.org/
>--------------------------------------------------------------------------
>
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
>
>From mjc@redhat.com Mon Mar  8 12:29:10 2004
>Date: Sat, 6 Mar 2004 10:02:31 +0000 (GMT)
>From: Mark J Cox <mjc@redhat.com>
>To: Stefan Esser <s.esser@e-matters.de>
>Cc: vendor-sec@lst.de, pknirsch@redhat.com
>Subject: Re: [vendor-sec] 10 x Ethereal Overflows
>
>> All of these bugs are stackoverflows that are nearly all caused
>> by missing boundary checks and in one case by an integer 
>> underflow. 
>
>Hello Stefan; do you have more detail of each issue (as per your last 
>advisory?).  Do you mean that all but one of the issues is an integer 
>underflow (and which one?).  That information will help me assign the 
>right number of CVE names to these issues.
>
>Thanks, Mark
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
>
>From s.esser@e-matters.de Mon Mar  8 12:29:21 2004
>Date: Sat, 6 Mar 2004 12:04:01 +0100
>From: Stefan Esser <s.esser@e-matters.de>
>To: Mark J Cox <mjc@redhat.com>
>Cc: vendor-sec@lst.de
>Subject: Re: [vendor-sec] 10 x Ethereal Overflows
>
>Hi Mark,
>
>> Hello Stefan; do you have more detail of each issue (as per your last 
>> advisory?).  Do you mean that all but one of the issues is an integer 
>> underflow (and which one?).  That information will help me assign the 
>> right number of CVE names to these issues.
>
>Here is a more detailed description.... The final text has yet to be
>written...
>
>[01] Netflow Protocol Dissector Overflow
>----------------------------------------
>
>Type: Stackoverflow
>
>Desc: When parsing the v9_template structure
>      a template_entry count > 64 will overflow
>      a stackbuffer and can lead to remote code
>      execution
>      
>File: packet-netflow.c
>Code: 
>
>static int
>dissect_v9_template(proto_tree * pdutree, tvbuff_t * tvb, int offset)
>{
>        struct v9_template template;
>	...
>        count = tvb_get_ntohs(tvb, offset);
> 	...
>        /* Cache template */
>        memset(&template, 0, sizeof(template));
>        template.id = id;
>        template.count = count;
>        template.source_addr = 0;       /* XXX */
>        template.source_id = 0;         /* XXX */
>        tvb_memcpy(tvb, (guint8 *)template.entries, offset,
>            count * sizeof(struct v9_template_entry));
>  	
>
>
>[02] IGAP Protocol Dissector Account Overflow
>---------------------------------------------
>
>Type: Stackoverflow
>
>Desc: When parsing a IGAP Protocol header an overlong
>      Accountstring (>17) will overflow a stack buffer
>      and can lead to remote code execution
>
>File: packet-igap.c
>
>Code:
>
>int
>dissect_igap(tvbuff_t *tvb, packet_info *pinfo, proto_tree *parent_tree, int offset)
>{
>    ...
>    guint8 type, tsecs, subtype, asize, msize, account[17], message[65];
>    ...
>    asize = tvb_get_guint8(tvb, offset);
>    proto_tree_add_uint(tree, hf_asize, tvb, offset, 1, asize);
>    offset += 1;
>
>    msize = tvb_get_guint8(tvb, offset);
>    proto_tree_add_uint(tree, hf_msize, tvb, offset, 1, msize);
>    offset += 3;
>
>    if (asize > 0) {
>        tvb_memcpy(tvb, account, offset, asize);   <--- [02]
>        account[asize] = '\0';
>        proto_tree_add_string(tree, hf_account, tvb, offset, asize, account);
>    }
>    offset += 16;
>
>    if (msize > 0) {
>        tvb_memcpy(tvb, message, offset, msize);   <--- [03]
> 
>
>[03] IGAP Protocol Dissector Message Overflow
>---------------------------------------------
>
>Type: Stackoverflow
>
>Desc: When parsing a IGAP Protocol header an overlong
>      Messagestring (>65) will overflow a stack buffer
>      and can lead to remote code execution
>
>File: packet-igap.c
>
>Code: see [03]
>
>
>
>[04] EIGRP Protocol TLV_IP_INT Long IP Address Overflow
>-------------------------------------------------------
>
>Type: Stackoverflow
>
>Desc: When parsing an EIGRP IP packet an overlong
>      IP Address will overflow a stack buffer and can
>      lead to remote code execution
>
>File: packet-eigrp.c
>
>Code:
>
>static void dissect_eigrp_ip_int (tvbuff_t *tvb, proto_tree *tree, proto_item *ti)
>{
>        guint8 ip_addr[4],length,addr_len;
> 	...
>        length=tvb_get_guint8(tvb,20);
>        ...
>        if (length % 8 == 0) addr_len=length/8 ; else addr_len=length/8+1;
>        ip_addr[0]=ip_addr[1]=ip_addr[2]=ip_addr[3]=0;
>        tvb_memcpy(tvb,ip_addr,21,addr_len);
>  
>
>
>[05] EIGRP Protocol TLV_IP_EXT Long IP Address Overflow
>-------------------------------------------------------
>
>Type: Stackoverflow
>
>Desc: When parsing an EIGRP Extended IP packet an overlong
>      IP Address will overflow a stack buffer and can
>      lead to remote code execution
>
>File: packet-eigrp.c
>
>Code:
>
>static void dissect_eigrp_ip_ext (tvbuff_t *tvb, proto_tree *tree, proto_item *ti)
>{
>        guint8 ip_addr[4],length,addr_len;
>	...
>        length=tvb_get_guint8(tvb,40);
>        proto_tree_add_text (tree,tvb,40,1,"Prefix Length = %u",length);
>        if (length % 8 == 0) addr_len=length/8 ; else addr_len=length/8+1;
>        ip_addr[0]=ip_addr[1]=ip_addr[2]=ip_addr[3]=0;
>        tvb_memcpy(tvb,ip_addr,41,addr_len);
> 	
>
>
>[06] PGM Protocol NakList Overflow
>----------------------------------
>
>Type: Integer Underflow -> Stackoverflow
>
>Desc: A possible integer underflow can result in a
>      small stackoverflow. Due to stacklayout this
>      does not seem to be exploitable.
>
>File: packet-pgm.c
>
>Code:
>
>static void
>dissect_pgmopts(tvbuff_t *tvb, int offset, proto_tree *tree,
>    const char *pktname)
>{
>		...
>                case PGM_OPT_NAK_LIST:{
>                        pgm_opt_nak_list_t optdata;
>                        nlong_t naklist[PGM_MAX_NAK_LIST_SZ+1];
>                ...
>                        optdata.len -= sizeof(pgm_opt_nak_list_t);   <--- opdata.len is uint8
>                        tvb_memcpy(tvb, (guint8 *)naklist, offset+4, optdata.len);
>                 
> 
>
>[07] IRDA Protocol Plugin IRCOM_PORT_NAME Overflow
>--------------------------------------------------
>
>Type: Stack-off-by-two
>
>Desc: When parsing an IRCOM_PORT_NAME packed
>      an overlong portname can overwrite up to
>      2 bytes on stack (NOT Tested)
>      
>File: packet-ircomm.c
>
>Code:
>
>static gboolean dissect_ircomm_parameters(tvbuff_t* tvb, unsigned offset, packet_info* pinfo _U_,
>                                          proto_tree* tree, unsigned list_index, guint8 attr_type)
>{
>	...
>	char        buf[256];
>	...
>        guint8  p_len = tvb_get_guint8(tvb, offset + 1);
>        ...
>        buf[0] = 0;
>
>        switch (tvb_get_guint8(tvb, offset))
>        {
>	...
>            case IRCOMM_PORT_NAME:
>                proto_item_append_text(ti, ": Port Name (\"");
>
>                tvb_memcpy(tvb, buf, offset+2, p_len);
>                strcat(buf, "\")");       <---- possible off by two
>                                          <---- also assumes that buf[255] is 0
>
>                proto_item_append_text(ti, buf);
>
>	
>
>[08] BGP Protocol MPLS Label Overflow
>-------------------------------------
>
>Type: Stackoverflow
>
>Desc: When parsing a BGP Packet with a MPLS IPv6 label
>      a 13 byte stackoverflow may happen. Exploitability
>      was not tested but could be possible depending
>      on stacklayout
>      
>File: packet-bgp.c
>
>Code:
>
>static int
>decode_prefix_MP(proto_tree *tree, int hf_addr4, int hf_addr6,
>    guint16 afi, guint8 safi, tvbuff_t *tvb, gint offset, char *tag)
>{
>    ...
>    case AFNUM_INET6:
>        switch (safi) {
>
>        case SAFNUM_MPLS_LABEL:
>            plen =  tvb_get_guint8(tvb, offset);
>            labnum = decode_MPLS_stack(tvb, offset + 1, lab_stk, sizeof(lab_stk));
>
>            offset += (1 + labnum * 3);
>            if (plen <= (labnum * 3*8)) {
>                proto_tree_add_text(tree, tvb, start_offset, 1,
>                        "%s IPv6 prefix length %u invalid", tag, plen);
>                return -1;
>            }
>            plen -= (labnum * 3*8);
>                             <---------- plen must be <= 128 to not overflow
>            length = (plen + 7) / 8; 
>            memset(ip6addr.u6_addr.u6_addr8, 0, 16);
>            tvb_memcpy(tvb, ip6addr.u6_addr.u6_addr8, offset, length);
> 
>      
>
>[09] ISUP Protocol INTERWORKING FUNCTION ADDRESS Overflow
>---------------------------------------------------------
>
>Type: Stackoverflow
>
>Desc: When parsing an ISUP Packet an oversized IWFA will
>      overflow a stack buffer and can lead to remote 
>      code execution
>
>File: packet-isup.c
>
>Code:
>
>static void
>dissect_bat_ase_Encapsulated_Application_Information(...
>{
>	...
>        guint8 iwfa[32], diagnostic_len;
>	...
>        switch ( identifier ){
>        case INTERWORKING_FUNCTION_ADDRESS :
>            tvb_memcpy(parameter_tvb, iwfa, offset, content_len);
>            
>            content_len can be any 12 bit value __________|
>
>
>
>[10] TCAP Protocol TID Overflow
>-------------------------------
>
>Type: Stackoverflow
>
>Desc: When handling the ASN.1 encoded Transaction ID
>      it may overflow a stack buffer and can lead to 
>      remote code execution
>      
>File: packet-tcap.c
>
>Code:
>
>static int
>dissect_tcap_tid(ASN1_SCK *asn1, proto_tree *tcap_tree, proto_item *ti, int type)
>{
>    ...
>    guint len;
>    ...
>    guchar *poctets;
>    guint32 val;
>    ...
>    dissect_tcap_len(asn1, subtree, &def_len, &len);
>
>    saved_offset = asn1->offset;
>    ret = asn1_string_value_decode(asn1, len, &poctets);
>    val = 0;
>    memcpy(&val, poctets, len);
>
>             |__________ copy whatever supplied into our 4 byte "buffer"    
>
>     
>
>Have a nice rest weekend
>Stefan
>
>-- 
>
>--------------------------------------------------------------------------
> Stefan Esser                                        s.esser@e-matters.de
> e-matters Security                         http://security.e-matters.de/
>
> GPG-Key                gpg --keyserver pgp.mit.edu --recv-key 0xCF6CAE69 
> Key fingerprint       B418 B290 ACC0 C8E5 8292  8B72 D6B0 7704 CF6C AE69
>--------------------------------------------------------------------------
> Did I help you? Consider a gift:            http://wishlist.suspekt.org/
>--------------------------------------------------------------------------
>
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
>
>From mjc@redhat.com Mon Mar  8 12:29:56 2004
>Date: Sat, 6 Mar 2004 16:32:44 +0000 (GMT)
>From: Mark J Cox <mjc@redhat.com>
>To: Stefan Esser <s.esser@e-matters.de>
>Cc: vendor-sec@lst.de
>Subject: Re: [vendor-sec] 10 x Ethereal Overflows
>
>Cool, they all look like they'd be covered under the same CVE 
>name (as long as they're all getting fixed at the same time). 
>Use CAN-2004-0176.
>
>Cheers, Mark
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec

Actions: View

Attachments on bug 50449: 16420 | 16421 | 16422 | 17022