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

Powered by Openwall GNU/*/Linux Powered by OpenVZ