Date: Tue, 4 May 1999 15:13:41 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Dag-Erling Smorgrav <des@ifi.uio.no> Cc: Jamie Rishaw <jamie@exodus.net>, security@FreeBSD.ORG Subject: Re: [Jamie Rishaw <jamie@exodus.net>] FreeBSD 3.1 remote reboot exploit Message-ID: <199905042213.PAA19927@apollo.backplane.com> References: <xzpwvyottqz.fsf@hrotti.ifi.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello Jamie. Well, I'm afraid you haven't given us much to go on. If
there is indeed an exploit, we probably won't be able to find it until
someone catches the panic message that caused the reboot or is otherwise
able to supply more information.
There are a number of ways to do this. You can compile up a kernel
configured to drop into DDB on panic rather then to simply reboot. Then,
from the DDB prompt, you can issue a 'trace' command to get a stack
trace and from there we can figure out the cause of the panic.
Another solution is to compile up a kernel configured with the console
on a serial port. You then connect the serial port to another machine
and log all the console messages. Using a serial console also allows
you to remotely manage the machine fairly easily.
It may also be possible to generate a crash dump. This does not require
a kernel recompile. The system must have at least as much swap space as
main memory and /var/crash must have enough space to fit the entire dump
(at least as much space as there is main memory, plus a tad more ). You
then enable dumps by specifying the dump device in /etc/rc.conf. If
dumps are enabled, there is a good chance that the panic will be able
to generate a crash dump before it reboots the machine.
For example, if the swap partition is /dev/sd0b, you would enable dumps
by placing 'dumpdev="/dev/sd0b"' in /etc/rc.conf and then either rebooting,
or running the 'dumpon /dev/sd0b' command manually. If you get a crash
dump, you can then use gdb to get a stack backtrace to determine what
caused the dump ( if you get that far, ask for help and people can give
you more detailed instructions ). Always be extremely careful when
enabling dumps, you do not want to accidently dump on a non-swap
partition!
-Matt
Matthew Dillon
<dillon@backplane.com>
:
:------- Start of forwarded message -------
:Message-ID: <19990501031840.A24252@dilbert.exodus.net>
:Date: Sat, 1 May 1999 03:18:40 -0500
:Reply-To: jamie@exodus.net
:From: Jamie Rishaw <jamie@exodus.net>
:Subject: FreeBSD 3.1 remote reboot exploit
:To: BUGTRAQ@NETSPACE.ORG
:
:Hi,
:
: Sorry to be so vague, but I wanted to let everyone know,
:
: It's been demonstrated to me by two people who will not reveal "how"
:that there is a remote bug exploit, almost certainly over IP, that will
:cause FreeBSD-3.1 systems to reboot with no warnings.
:
: The second box this was demonstrated on today had no open services
:besides ircd, and was remote rebooted. (The first box had open services
:such as smtp, ssh, pop, http, but did /not/ run ircd, eliminating ircd
:as the culprit).
:
: If anyone can shed some light on this (really bad) issue, it'd be
:greatly appreciated, especially since I am(was) in the process of
:upgrading all of my boxes to 3.1. (3.1-REL).
:
: Regards,
:
:-jamie
:--
:jamie rishaw (efnet:gavroche) -- Exodus Communications, Inc.
:>Sr. Network Engr, Chicago, SoCal Data Centers
:<jimmie> In an interesting move Exodus Communications annouced today that
: they have replaced all of their backbone engineers with furby's
:
:------- End of forwarded message -------
:
:
:To Unsubscribe: send mail to majordomo@FreeBSD.org
:with "unsubscribe freebsd-security" in the body of the message
:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905042213.PAA19927>