Hi, this thread has been posted before also in this mailing list. You can see solution provided by Gaurav Dhiman and me in the old postings. Search in the archive you will surely get whatever you want... thanks Sumit Sharma IBM, Bangalore. On Thu, 07 Oct 2004 Jirka Kosina wrote : >On Tue, 5 Oct 2004, Jon Masters wrote: > > > Personally I think it would be nice to be able to modify it more easily > > but that would require some redesign to add the various protections > > necessary. For example when the next exploit comes out which affects the > > vm syscalls I'd prefer a loadable module fix. (this is speaking as an > > occasional admin with production boxes kicking around that we rely upon > > not needed to be rebooted every 5 minutes - i.e. most so called "real > > world" users). > >In these "unusual" cases, it is still usually possible to find a way how >to code quick-and-dirty hotfix LKM, preventning the exploitation of the >bug. > >First thing is, that even without sys_call_table[] being exported to >modules, it is still possible to find the address where it resides, using >some heuristics (like finding adjacent exported modules, and look for >sys_call_table[] signature between these addresses, or even better, get it > from known offset). Second thing is, that usually it is possible to hotfix >those bugs even without messing with sys_call_table[] - for example with >latest do_brk() bug, it was not sufficient to replace sys_brk() with your >own version with added checks, because there were codepaths where do_brk() >was called not from this syscall. I have written module which directly >modified in memory instructions of do_brk() function with jmp to function >in my module, which performed needed checks, and then jumped back to >original do_brk(). > >-- >JiKos. > >-- >Kernelnewbies: Help each other learn about the Linux kernel. >Archive: http://mail.nl.linux.org/kernelnewbies/ >FAQ: http://kernelnewbies.org/faq/ >
