Hi Tom,
> About the linux kernel vuln, wonder how long its gonna take them
> to get out an update for it??
I'm puzzled about that as well. My money was on last Monday for an updated
RHEL5 kernel and 11 days later for a CentOS5 kernel. But it looks RH is taking
a different route this time. It appears they'll provide a fix during the next
"routine" kernel update and paying clients can request a "hotfixed" kernel.
> Even though they say its local user, we have been reading reports, far too
> many for our comfort level, that say hacktards are using xss and other
> methods remotely to get hacks for this kernel problem onto systems as a
> local user and hacking quite a few boxes already!?
Exactly so. It is always bad if lax security or an ill designed application
(PHP script, etc.) allows someone local and unprivileged access to the OS.
That shouldn't happen in an ideal world, but in the hosting business we see
this far too often for various reasons. In BlueOnyx we raised the bar for this
by adding some extra layers of protection beyond what BlueQuartz offers, but
still: It ain't Fort Knox and the admins might even choose to disable the
extra security. All that it then takes is another hole such as this kernel
vulnerability and the attacker can escalate his unprivileged local access to
gain root access.
> Has anybody tried the "workaround" they have listed on that redhat bug
> report by disabling some modules or know if that would actually help on our
> CentosBQ boxes?
For BlueOnyx and CentOS5 we rolled up a patched kernel. It's just one line of
code that's changed and the new kernel appears to be both stable and safe. For
CentOS4 it should be equally trivial to roll up a fixed kernel. I'd trust that
more than the other suggested work arounds, which I haven't tested.
> I ran lsmod and didn't think I saw any of the modules loaded??
Yeah, but they will be loaded if the kernel needs them. Unless you stop the
loading of kernel modules with a third party tool such as LCAP. But the way
this exploits works I'm not sure LCAP alone would prevent it. Haven't tested
that, though.
> We also read that disabling selinux was a good idea but I don't thing its on
> by default in CentosBQ??
SELinux is disabled by default on BlueQuartz and BlueOnyx. On a "normal"
CentOS it's typically set to enforcing mode, but that didn't stop the exploit
either in the default SELinux configuration used on RHEL and CentOS.
All in all I'm not a happy camper with this situation at hands. That CentOS is
late with handing down patches and that they never fix something that RedHat
doesn't fix upstream ... both of that ain't new. But that RedHat sits this one
out has me somewhat puzzled. Like said: The issue is trivial to patch and that
extra bit of Q&A should be easy to shake loose for a giant like RedHat. But
they leave the field to Debian, Fedora Core and other distributions, who
already jumped on it and pushed out fixed kernels as fast as one ought to
expect <shrug>.
--
With best regards,
Michael Stauber