[<prev] [next>] [day] [month] [year] [list]
Message-ID: <200312091959.hB9JxiOr006857@pookie.nersc.gov>
Date: Tue, 09 Dec 2003 11:59:44 -0800
From: canon@...sc.gov
To: bugtraq@...urityfocus.com
Subject: Re: Hot fix for do_brk bug
I had a similar approach working, but was still tweaking the implementation. You beat
me to the punch. Doh! My working version did an objdump of vmlinux to determine the
opcode boundaries.
One potential flaw in this approach is the instructions that are
over-written by the jump and copied to the assembler routine (dobrk2)
can't include any operations that have relative addresses or offsets.
Fortunately, this seems quite rare from a brief scan of various kernel
routines. However, its probably worth checking the assembler routine
before issuing the module load. I still think this is a better approach than
my initial version that "fixed" calls and jumps.
Nice work.
--Shane
> > It would be less intrusive to the kernel to supply a fixed do_brk()
> > and replace the do_brk with a jump to your version.
>
> I've written similar patch few days ago. The patch only modifies first
> instructions of do_brk() (it replaces them with jmp to function in LKM.
> It can be downloaded from http://wizard.ath.cx/fixbrk.tar.gz
>
> But beware, I wrote it in rush and it's pretty odly written :-) But it
> worked on my two servers (both were running 2.4.21 kernel with grsecurity
> patch).
>
> Greetings
>
> Pavel Palát
>
> --
> Pavel "harry_x" Palát
> harry_x@...ylon5.cz
> irc: #mistral.cz on IRCnet
>
> The only way of finding the limits to the possible is by going beyond them to the impossible
> Arthur C. Clark
>
------------------------------------------------------------------------
Shane Canon voice: 510-486-6981
PSDF Project Lead fax: 510-486-7520
National Energy Research Scientific
Computing Center
1 Cyclotron Road Mailstop 943-256
Berkeley, CA 94720 canon@...sc.gov
------------------------------------------------------------------------
Powered by blists - more mailing lists