2009/8/14 Ewan MacMahon <[log in to unmask]>

> -----Original Message-----
> From: Testbed Support for GridPP member institutes [mailto:TB-
>

> The RedHat bug report for this:
> https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2009-2692
> has a workaround that looks suitable for deployment to a running
> system; it essentially consists of disabling the loading of the
vulnerable
> kernel modules, which should, I think, be harmless, but I've not tried
it as
> yet.
>

And now I have. Disabling the loading of pppox and bluetooth modules as
per the bugzilla entry does seem to stop the canned exploit from
working,
though I note that SL does seem to have the sctp module present as well.
While the exploit seem not to auto load it, if you load it manually
(which
does, of course, require root access) and then run the exploit code from

an unprivileged account it does then work and get root. I'm not sure if
there's a good in-principle reason that sctp.ko can't be loaded
automatically, or whether it's just a bug in this particular exploit,
but
since the same RH bugzilla suggests blocking it on RH MRG systems it
seems
prudent to block it on SL too.

I'd therefore suggest adding:

install pppox /bin/true
install bluetooth /bin/true
install sctp /bin/true

to /etc/modprobe.conf. This all assumes that you don't already have any
of
those modules loaded (and if you do, you might want to find out why).
I've
cfengine-d this across all of our machines.

Ewan