Re: [ProgSoc] (forw) ophelia security check output

[Matt <matt@nospam.telesales.zip.com.au>]

On Fri, Mar 26, 1999 at 07:42:20AM +1100, Matt Beauregard wrote:


> Any FreeBSD types know what causes this? The kernel is almost the
> latest and there aren't really any hints in the logfiles...

from reading below looks like find was looking for setuid and setgid
programs on the disk (no suprises there for you i hope). and by
further examination it looks like the kernel faulted at page zero
(this is prolly caused by a bad pointer).  from the address of the bad
pointer (0x40) i would suspect it was trying to find an entry in a
struct or a table (ie something with an offset from a pointer). now to
the interesting part. it is mapped to the kernel segment (?? not
amazing sure because my knowledge of intel architecture (im assuming
intel here) isnt that good) 0x8 (the instruction pointer this is). i
hope this segment is where the kernel maps its code segment (if it is
the stack then it will be pretty hard to find out how things went
wrong). now that you know the instruction pointer address you can
figure out hwre ein the kernel the fault occured (ie in what
function). and if you have a kernel core dump (or even just a dump of
the kernel stack) you should be bale to get a backtrace of the
functions that called it. oh and another thing interrupts were enabled
which means it is very unlikely that it was in a device driver bottom
end (or some such). so it probably isnt a device driver that is
causing the problem (unless it passed bogus data that isnt checked).

have you got a copy of the kernel still? and a copy of the kernel
symbol table (i dont know if FreeBSD has hard copies of these i assume
it would make such during the kernel build at some stage
somewhere). the offsets in the kernel symbol table should also be able
to tell you what function it was executing at the time. and if you
plow into the kernel binary you should be able to calculate even what
instruction (and what source line) it was executing at the time.

mind you if the FreeBSD kernel is debuggable (using gdb or somethign
similar) you should be able to get the debugger to do all this in a few
commands.

	matt

p.s. the instruction pointer address looks sane so it looks like bad
data rather than the kernel jumping off to fishkill.

p.p.s. assuming the FreeBSD kernel maps the kernel code segment in at
0xf0000000 the code you are looking for should be at a 0x1b1cb4 offset
from the beginning of the code segment.


> ----- Forwarded message from Charlie Root <root@nospam.ophelia.marauder.tm> -----

> Date: Fri, 26 Mar 1999 02:00:22 +1100 (EST)
> From: Charlie Root <root@nospam.ophelia.marauder.tm>
> Message-Id: <199903251500.CAA01619@nospam.ophelia.marauder.tm>
> Subject: ophelia security check output

> checking setuid files and devices:


> checking for uids of 0:
> root 0
> toor 0


> ophelia kernel log messages:


>> Fatal trap 12: page fault while in kernel mode
>> fault virtual address	= 0x40
>> fault code		= supervisor read, page not present
>> instruction pointer	= 0x8:0xf01b1cb4
>> stack pointer	        = 0x10:0xefbffd48
>> frame pointer	        = 0x10:0xefbffde0
>> code segment		= base 0x0, limit 0xfffff, type 0x1b
>> 			= DPL 0, pres 1, def32 1, gran 1
>> processor eflags	= interrupt enabled, resume, IOPL = 0
>> current process		= 12327 (find)
>> interrupt mask		= 
>> panic: page fault

>> syncing disks... 50 50 46 39 30 19 6 1 1 1 1 1 1 1 1 1 1 1 1 1 giving up
>> Automatic reboot in 15 seconds - press a key on the console to abort
>> Rebooting...
>> Copyright (c) 1992-1998 FreeBSD Inc.
>> Copyright (c) 1982, 1986, 1989, 1991, 1993
>> 	The Regents of the University of California.  All rights reserved.

>> FreeBSD 2.2.8-STABLE #0: Wed Jan 20 13:46:34 EST 1999
>>     marauder@nospam.ophelia.marauder.tm:/usr/src/sys/compile/OPHELIA
> [etc]

> ----- End forwarded message -----

> -- 
> screen so pure and blue
> this computer is at peace
> control alt delete

> matthew beauregard
> viper communications
> systems programmer
> --
> You are subscribed to the progsoc mailing list. To unsubscribe, send a
> message containing "unsubscribe" to progsoc-request@nospam.progsoc.uts.edu.au.
> If you are having trouble, ask owner-progsoc@nospam.progsoc.uts.edu.au for help.

> This list is archived at <http://www.progsoc.uts.edu.au/lists/progsoc/>
--
You are subscribed to the progsoc mailing list. To unsubscribe, send a
message containing "unsubscribe" to progsoc-request@nospam.progsoc.uts.edu.au.
If you are having trouble, ask owner-progsoc@nospam.progsoc.uts.edu.au for help.

This list is archived at <http://www.progsoc.uts.edu.au/lists/progsoc/>