Skip to contentSkip to conversation

PROBLEM: tcp_parse_options() reading one byte off the packet limit

DISCUSSION jp 1 participant 1 message Jul 7, 2003

lore
Share & tools
lore

jp

author
#0 lore raw

[1.] One line summary of the problem:
tcp_parse_options() reading one byte off the packet limit

[2.] Full description of the problem/report:
The tcp_parse_options() function from net/ipv4/tcp_input.c does not properly validate packet's end when reading the opsize of a variable length option:

void tcp_parse_options(struct sk_buff *skb, struct tcp_opt *tp, int estab) {
unsigned char *ptr;
struct tcphdr *th = skb->h.th;
int length=(th->doff*4)-sizeof(struct tcphdr);

   ptr = (unsigned char *)(th + 1);
   tp->saw_tstamp = 0;

   while(length>0) {
      int opcode=*ptr++;
      int opsize;
      switch (opcode) {
         case TCPOPT_EOL:
            return;
         case TCPOPT_NOP:  /* Ref: RFC 793 section 3.1 */
            length--;
            continue;
         default:
            opsize=*ptr++;                        /* XXX */

The line responsible of the problem is marked with a 'XXX' comment in the source code above. Depending on the length of the packet received, opsize may be forced to be loaded with:
a) one byte from packet's data
b) skbuff's padding if there's no data in the packet
c) skb_shinfo's first field if there's no data in the
packet and no padding in the skbuff's data

After a short analysis of the problem, we think this is not exploitable from a security standpoint, as there is always information after skb->end (both in 2.2 and 2.4 kernels). Also, leaking information from the read byte seem's not possible because of the checks performed after reading opsize.

[3.] Keywords (i.e., modules, networking, kernel):
networking

[4.] Kernel version (from /proc/version):
Linux version 2.4.18-19.8.0 ([email protected]) (gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) #1 Thu Dec 12 05:39:29 EST 2002

[5.] Output of Oops.. message (if applicable) with symbolic information
resolved (see Documentation/oops-tracing.txt)
N/A

[6.] A small shell script or example program which triggers the
problem (if possible)
N/A

[7.] Environment

[7.1.] Software (add the output of the ver_linux script here)
Linux vaiolator 2.4.18-19.8.0 #1 Thu Dec 12 05:39:29 EST 2002 i686 i686 i386 GNU/Linux

Gnu C                  gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Gnu make               3.79.1
util-linux             2.11r
mount                  2.11r
modutils               2.4.18
e2fsprogs              1.27
pcmcia-cs              3.1.31
PPP                    2.4.1
isdn4k-utils           3.1pre4
Linux C Library        2.2.93
Dynamic linker (ldd)   2.2.93
Procps                 2.0.7
Net-tools              1.60
Kbd                    1.06
Sh-utils               2.0.12

[7.2.] Processor information (from /proc/cpuinfo):
N/A
[7.3.] Module information (from /proc/modules):
N/A
[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem) N/A
[7.5.] PCI information ('lspci -vvv' as root)
N/A
[7.6.] SCSI information (from /proc/scsi/scsi)
N/A
[7.7.] Other information that might be relevant to the problem
(please look in /proc and include all information that you think to be relevant):
N/A
[X.] Other notes, patches, fixes, workarounds:
N/A

Thank you.

Signature · 10 lines
Juan Pablo Martinez Kuhn
CORE SECURITY TECHNOLOGIES

A26D E507 60F5 1B2C C30C
20DE 8240 3E28 3A2C D89D

 Florida 141 - 2º cuerpo - 7º piso
 C1005AAC Buenos Aires - Argentina
 Tel/Fax: (54 11) 5032-CORE (2673)
 http://www.corest.com