RE: [cobalt-security] RAZOR advisory: Linux 2.2.xx /proc/<pid>/mem mmap() vulnerability

["Eric Frisch" <ericf@xxxxxxxxxxx>]

Eugene wrote:

>
> For those who love adventures, note that it is possible to install 2.4
> kernel on a RaQ3/4 without touching the rest of the system (aside from
> obligartory BIOS reflashing); kernel RPMs are somewhere on ftp-eng.

Not that I love adventures but I did this to one machine because some sort
of network based Denial of Service thing was knocking over my fully patched
Raq4r machine several times a day.  It was running an updated BIND and
gShield/IPchains was used to block all other access, there were no public
web services or anything.  Only the 2.4.19C1_III-1 kernel works if you have
more than one disk (i.e. Raq4r), the earlier kernel will not let you see the
'hdc" drive due to an IRQ detection problem.  With this kernel I was able to
install the RH 7.2 IPtables RPM and the latest gShield to firewall the box.
The machine has been stable for 12 days now, life appears to be good again.
I suspect that there are "other issues" with the 2.2 kernel but have no hard
data to prove it other than I made the problem go away by going to 2.4.

Some other notes; the "storage" start-up script doesn't work very well with
the 2.4 kernel.  I had to disable it as it caused in the order of a 15-20
minute delay booting the machine.  The script is probably not required
unless you have external SCSI drives and in that case you could probably
work around the issue easily by populating fstab.  I have not tried any
other services on the box besides BIND and IPtables, I have no idea if there
is other collateral damage.  Drastic DNS problems required drastic measures
and I didn't care what else I broke on that machine.  You also have to do
a --force on all the Kernel and module RPM installs as they scribble on the
old files.  I keep a few 20G drives around as spares and just used dd to
move my good filesystems onto a spare drive to play with.  I would never go
with this upgrade route if I didn't have extra Raqs laying around, extra
disks, a Linux PC to mount the Cobalt drives in, a serial console and a UPS
on the machine being flashed.  The whole thing falls into the fairly high
risk category.

I have no idea where I am going next, by doing this I have created issues
related to the application of future packages on the box.  I have a bunch of
these Raq4r machines and they are making me VERY nervous.  I am toying with
the idea of just turning them into generic Linux servers with a minimal
install and hand building all the critical daemons with no extraneous
modules and such.  I don't like the ancient kernel aspect of the Raq4, the
old libraries and the myriad of other outdated software.  The slow release
of updates for published vulnerabilities compounds the issue.  I have
learned my lesson, open source software is good, open source software with a
proprietary layer is bad, very bad . . .  This issue is not unique the Raq,
I have seen the same thing played out with some other commercial solutions
in my environment in the past year.  Big vendors with too much "Cathedral"
in their development process, while they are ensuring that they don't
release a patch that breaks every customers server, half of the customers
servers have been burned down by a worm.  There has got to be a balance
there someplace if they want to keep selling the product.  Okay I digressed
into a rant . . .  Sorry.

Eric

>
> Eugene
>
> _______________________________________________
> cobalt-security mailing list
> cobalt-security@xxxxxxxxxxxxxxx
> http://list.cobalt.com/mailman/listinfo/cobalt-security
>