bugtraq - Re: Hot fix for do

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

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
------------------------------------------------------------------------