lkml.org 
[lkml]   [2003]   [Jul]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectPROBLEM: tcp_parse_options() reading one byte off the packet limit
[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 (bhcompile@stripples.devel.redhat.com) (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.
--
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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:46    [W:0.140 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site