[Full-Disclosure] Re: Linux kernel scm_send local DoS

[gadgeteer@elegantinnovations.org]

On Wed, Dec 15, 2004 at 01:31:30PM +0100, Paul Starzetz (ihaquer@isec.pl) wrote:
> I don't think this is practicable, since the bugs reside in deep kernel
> functions. You can not fix it just by disabling a particular syscall. You
> have patch a running kernel binary, maybe someone comes up with this kind
> of utlility.

Not by disabling the syscall but by replacing it in the manner that a
rootkit replaces syscalls. Build a new kernel from the same
source/config except for patch. Replace syscalls where there is change.
Practical?
Stable?
No. Much easier to simply reboot to new kernel. If service(s) are so
critical as to not tolerate a reboot yet have a single point of failure
on this one component then there are greater problems at play.
--
Chief Gadgeteer
Elegant Innovations
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Pavel Kankovsky]

On Tue, 14 Dec 2004, Paul Starzetz wrote:

> The Linux kernel provides a powerful socket API to user applications.
> Among other functions sockets provide an universal way for IPC and user-
> kernel communication. The socket layer uses several logical sublayers.
> One of the layers, so called auxiliary message layer (or scm layer),
> augments the socket API by an universal user-kernel message passing
> capability (see recvfrom(2) for more details on auxiliary messages).

More nasties might be lurking nearby (at least in 2.4):

- additional, almost identical, copies of cmsg parsing code appear in
ip_cmsg_send() (net/ipv4/ip_sockglue.c) and datagram_send_ctl()
(net/ipv6/datagram.c)

- sys_sendmsg() (net/socket.c) is willing to allocate almost arbitrary
large blocks of kernel memory


--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."

[Valdis.Kletnieks@vt.edu]

--==_Exmh_-1704711040P
Content-Type: text/plain; charset=us-ascii

On Wed, 15 Dec 2004 13:31:30 +0100, Paul Starzetz said:
> I don't think this is practicable, since the bugs reside in deep kernel
> functions. You can not fix it just by disabling a particular syscall. You
> have patch a running kernel binary, maybe someone comes up with this kind
> of utlility.

Majorly scary. I've done similar patch-on-the-fly on many different systems
in the past 25 years. You *really* want to install a proper patch and reboot.

If you can't tolerate the 10-20 minutes of downtime a scheduled reboot will
take, you can't tolerate the hours of downtime you'll get if you get hacked.
So either bite the bullet and reboot, or get redundant gear so you have good
fail-over while you reboot.

(Note that *some* bugs in the Linux kernel can at least theoretically be
fixed on the fly with an rmmod of the buggy module and an insmod of a patched
version built against the same source tree. The bugs in question aren't in
code that's likely to be rmmod'able on a running production system....)

--==_Exmh_-1704711040P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFBykKPcC3lWbTT17ARAnn+AKCkZtP2pYAs8YiFJeOGbo IKFpbmbgCbBQkV
2qJ9YA2eclT9cNenZF4WMo4=
=dWbv
-----END PGP SIGNATURE-----

--==_Exmh_-1704711040P--