[lug] Linux sysctl() Kernel Memory Reading Vulnerability
D. Stimits
stimits at idcomm.com
Fri Feb 16 13:09:42 MST 2001
Justin wrote:
>
> So this sounds like something I would "activate" with like a modprobe
> or insmod right? I'll the compile a try this weekend and see what
> happens.
Yes. If you are familiar with module directory, the scheme is that all
Linux machines have a /lib/modules/"someversion"/ directory.
"someversion" is found with "uname -r", which is named after the kernel
major version, minor version, and "EXTRAVERSION". All of those versions
are visible at the top of the kernel toplevel Makefile. EXTRAVERSION is
typically for naming patch levels or vendor information. Anyway, assume
your kernel is just "2.4.0", though probably it is longer. You would
have /lib/modules/2.4.0/
Within that, you will have subdirectories, and modules can exist in most
any of them. The modules have a ".o" suffix. I don't know which
directory is best for this module, and it depends on if you use 2.2.x or
2.4.x as to the subdirectories available, but I would guess it goes in
either an i386/kernel/ (2.4.x) or misc/ (2.2.x) directory. Then try
either "depmod -a", or "insmod themodulename.o" (or modprobe), while
monitoring /var/log/messages (e.g., "tail -f -n 30 /var/log/messages"
will continuously monitor and display the log as it runs). If you don't
like the module, delete it or move it, no harm done. So in addition to
what you mentioned to activate it, you simply need to be sure it is
where it can be found first, in the right modules subdirectory.
>
> Justin
>
> >
> > Anyone with a real user account that logs in via ssh or telnet would
> be
> > local once logged in. Adding that as a module probably would not
> disrupt
> > your regular kernel, provided you have your kernel source available
> and
> > configured to match the installed system already. It wouldn't hurt to
> > try to compile it and see if it fails or not; the question then is
> > whether you want to install it or test it. Modules are just
> > that...separate plugin items that can extend the kernel and be added
> or
> > removed at will.
> >
> > >
> > > Justin
> > >
> > > > I didn't try to compile or use the fix, but here is what it looks
> > > like.
> > > > This is an independent module that does not require patching the
> > > actual
> > > > kernel. But for it to compile correctly, you'd need the current
> kernel
> > > > source to be both installed AND matching your running system.
> Then you
> > > > add the module somewhere within your module directory (depending
> on
> > > > version and preferences), followed by something like depmod -a to
> tell
> > > > it to update module info. It *looks* like this is a new module,
> and
> > > not
> > > > a replacement for anything existing. Since I haven't tested this,
> > > > consider it only advice. FYI, it does not appear to be a remote
> > > exploit,
> > > > so a user would need local access to use it.
> > > >
> > > > D. Stimits, stimits at idcomm.com
> > > > _______________________________________________
> > > > Web Page: http://lug.boulder.co.us
> > > > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> > > >
> > > >
> > >
> > > -----
> > > glow at jackmoves.com
> > > www.jackmoves.com
> > > _______________________________________________
> > > Web Page: http://lug.boulder.co.us
> > > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> > _______________________________________________
> > Web Page: http://lug.boulder.co.us
> > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> >
> >
>
> -----
> glow at jackmoves.com
> www.jackmoves.com
> _______________________________________________
> Web Page: http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
More information about the LUG
mailing list