what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

linux-2.2.0-DoS.txt

linux-2.2.0-DoS.txt
Posted Aug 17, 1999

Bug in Linux 2.2.0 kernel allows any local user to execute a Denial of Service attack, forcing system reboot.

tags | exploit, denial of service, kernel, local
systems | linux
SHA-256 | acac19e1d0819b1904e55e465fc6af4e73f78a959f4053daa624c8ef9e59b229

linux-2.2.0-DoS.txt

Change Mirror Download
Date: Wed, 27 Jan 1999 03:14:29 -0500
From: //Stany <stany@PET.NOTBSD.ORG>
To: BUGTRAQ@netspace.org
Subject: Re: 2.2.0 SECURITY (fwd)

Later on down the thread there are other people then Dan Burcaw who say
that the bug crashes their boxes too.

I suggest reading the thread on Linux Kernel archives for more
information. See information at the bottof of forwarded message for
information.

---------- Forwarded message ----------
Date: Tue, 26 Jan 1999 22:08:03 -0700 (MST)
>From: Dan Burcaw <dburcaw@terraplex.com>
To: Richard Gooch <rgooch@atnf.csiro.au>
Cc: linux-kernel@vger.rutgers.edu
Subject: Re: 2.2.0 SECURITY


This has been tested and causes crashes on:

AMD K6-2 350
AMD K6-2 400
Intel 486 SX25 w/ P90 Overdrive

On Wed, 27 Jan 1999, Richard Gooch wrote:

> Dan Burcaw writes:
> >
> > There is a bug that works only on the 2.2.0 kernel that will allow root
> > and non-root users to crash the machine (the system reboots).
> >
> > To replicate this bug do following:
> >
> > Take any core file, and as normal user or root run: ldd core
> >
> > The machine will reboot, saying that it cannot get execution permissions
> > for ./core
> >
> > As far as I can tell, this problem only affects x86 machines running
> > 2.2.0. I know that PPC is not affected.
>
> Just tried this on a dual PPro:
>
> % cat > try.c
> void main ()
> {
> * (unsigned int *) 0 = 0;
> }
> % cc -o try try.c
> % ./try
> Segmentation fault
> % ldd core
> % dmesg | tail -1
> perfmon: v0.4 (19990127) Richard Gooch (rgooch@atnf.csiro.au), 2 counters
>
> Nope, doesn't cause a reboot, panic, Oops or any problems
> here. Running as root makes no difference.
>
> Regards,
>
> Richard....
>


Dan

Terra Firma Design & Terra Soft Solutions, Inc.

voice (970) 416-9821 in Fort Collins
email dburcaw@terraplex.com
website http://www.terraplex.com/



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

--
+-----------------------------------------------------------------------------+
| Stanislav N. Vardomskiy - Procurator Odiosus Ex Infernis[TM] |
| This message is brought to you by letters jey, ow, el and tee. |
| Jolt! For all the sugar and twice the caffeine. |
+-----------------------------------------------------------------------------+

--------------------------------------------------------------------------------

Date: Wed, 27 Jan 1999 19:19:01 +0000
From: Alan Cox <alan@LXORGUK.UKUU.ORG.UK>
To: BUGTRAQ@netspace.org
Subject: Re: 2.2.0 SECURITY (fwd)

> Later on down the thread there are other people then Dan Burcaw who say
> that the bug crashes their boxes too.
>
> I suggest reading the thread on Linux Kernel archives for more
> information. See information at the bottof of forwarded message for
> information.

Yep its real bug. The relevant info for early adopters is:


>From: MOLNAR Ingo <mingo@chiara.csoma.elte.hu>
To: linux-kernel@vger.rutgers.edu, linux-smp@vger.rutgers.edu
cc: Linus Torvalds <torvalds@transmeta.com>, Alan Cox <alan@lxorguk.ukuu.org.uk>, "David S. Miller" <davem@dm.cobaltmicro.com>
Subject: [patch] 'coredump crash' fixed

it was a very subtle bug and has nothing to do with coredumps at all, but
it's very rare and the invalid coredump ELF layout accidentally triggered
the bug.

with the attached patch applied i get:

[root@moon /root]# ldd core
not a dynamic executable
[root@moon /root]#

just as expected. The reason why we crash and why it made the kernel
reboot in such a nasty way was that munmap() did just a tad more work than
necessary and we zapped 0xc0000000's page table entry ... that is a pretty
vital piece of 4M virtual space on Linux ;) (erm, just dont ask me how i
managed to debug this ;)

-- mingo, running a hopefully much safer kernel now ;)

--- linux/mm/mmap.c.orig Wed Jan 27 14:09:31 1999
+++ linux/mm/mmap.c Wed Jan 27 14:06:09 1999
@@ -558,7 +558,7 @@
unsigned long start, unsigned long end)
{
unsigned long first = start & PGDIR_MASK;
- unsigned long last = (end & PGDIR_MASK) + PGDIR_SIZE;
+ unsigned long last = ((end-1) & PGDIR_MASK) + PGDIR_SIZE;

if (!prev) {
prev = mm->mmap;

-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to majordomo@vger.rutgers.edu

--------------------------------------------------------------------------------

Date: Wed, 27 Jan 1999 05:41:59 +0000
From: Aaron Lehmann <aaronl@VITELUS.COM>
To: BUGTRAQ@netspace.org
Subject: 2.2.0 SECURITY (fwd)

A bug has been discovered in the recently released Linux 2.2.0. I suggest
going back to Linux 2.0.36 until this nasty bug is fixed.

It was later realized that this bug DOES also affect Linux 2.2.0ac1, but
only if the core file has permissions 600.


KeyID 1024D/73348CA0
Fingerprint 8EFC 7F10 F26C 55A8 458A 38B0 890F 384F 7334 8CA0
Public key available at http://www.vitelus.com/aaronl/pubkey.asc

Login or Register to add favorites

File Archive:

April 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Apr 1st
    10 Files
  • 2
    Apr 2nd
    26 Files
  • 3
    Apr 3rd
    40 Files
  • 4
    Apr 4th
    6 Files
  • 5
    Apr 5th
    26 Files
  • 6
    Apr 6th
    0 Files
  • 7
    Apr 7th
    0 Files
  • 8
    Apr 8th
    22 Files
  • 9
    Apr 9th
    14 Files
  • 10
    Apr 10th
    10 Files
  • 11
    Apr 11th
    13 Files
  • 12
    Apr 12th
    14 Files
  • 13
    Apr 13th
    0 Files
  • 14
    Apr 14th
    0 Files
  • 15
    Apr 15th
    30 Files
  • 16
    Apr 16th
    10 Files
  • 17
    Apr 17th
    22 Files
  • 18
    Apr 18th
    45 Files
  • 19
    Apr 19th
    8 Files
  • 20
    Apr 20th
    0 Files
  • 21
    Apr 21st
    0 Files
  • 22
    Apr 22nd
    11 Files
  • 23
    Apr 23rd
    68 Files
  • 24
    Apr 24th
    23 Files
  • 25
    Apr 25th
    0 Files
  • 26
    Apr 26th
    0 Files
  • 27
    Apr 27th
    0 Files
  • 28
    Apr 28th
    0 Files
  • 29
    Apr 29th
    0 Files
  • 30
    Apr 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close