[9010] in bugtraq
Summary: security and multicast
daemon@ATHENA.MIT.EDU (Donald McLachlan)
Sat Jan 9 15:17:23 1999
Date: Fri, 8 Jan 1999 12:24:34 -0500
Reply-To: Donald McLachlan <don@MARS.DGRC.CRC.CA>
From: Donald McLachlan <don@MARS.DGRC.CRC.CA>
To: BUGTRAQ@NETSPACE.ORG
First of all thanks for all the replies. In case people would rather
not have their email addresses published I will not list them here.
The purpose of the question (echoed by some responders) is the lack of
documented multicast probes/attacks/vulnerabilties. Seeing as the
underpinnings are udp datagrams it was assumed most udp attacks were
possible.
[ I've not had a chance to verify any of the following claims so don't take
them as gospel ... ]
The assumed udp vulnerabilites were supported by responders who claimed
multicast is susceptible to the usual ICMP/UDP/IP attacks (e.g. smurf, pepsi,
and teardrop) and the associated D.O.S. due to overloaded hosts/links.
One report said NIS and YP would happily send requests to multicast
addresses, but has not seen these sorts of probes.
One reported mrouted tunnels as convenient holes in firewalls.
I've been pointed to an IEEE Security & Privacy 97 paper (by TIS?) about
multicast proxy security issues. I've not had time to search for it yet.
There were 2 reports of multicast ports on routers being attacked. In the
first instance no details were given, but as they don't use multicast they
simply turned them off. In the second case a router was being flooded with
PIM join/prunes for every group. Their solution was to shut down the mbgp
peering.
I was given a copy of a paper which was aimed at providing secure communications
over multicast through authentication, key management and encryption.
Interesting, but no attacks/probes/workarounds were listed.
One individual reported the following ideas on possible exploits ...
I would have checked if the poster would rather not have had the following
posted but couldn't check as the message was sent to me via an anonymous
remailer. so ...
> One idea we've come up with, though it's theoretical only (so
> far):
>
> 1) Build buffer overflow exploit for a popular multicast client
> for Windows (perhaps CU-SeeMe) that can be triggered by values
> in the multicast data or control stream.
>
> 2) In order to get the attention of clients, announce a free
> "live sex" video feed best viewed by the client for which you
> have the exploit.
>
> 3) Feed the exploit to each client that connects, and have your
> way with their machine.
>
>
> I've looked at other possible mechanisms involving running a
> bogus mrouted or other IGMP peer to take over delivery of
> existing streams, in order to inject exploit bits or provide
> disinformation. However, I haven't considered the details of
> splicing into the IGMP fabric without the help of peers
> elsewhere -- that appears to be the most interesting part of the
> problem at first blush.
>
>
> I'm looking forward to your summary. If others are thinking
> along similar lines, or are further along elsewhere, I may well
> need to get my organization's security policy adjusted to
> restrict multicast sooner rather than later.
A collegue offered to dig up a paper. If it is relevent and not
proprietary I'll post it as a follow up.
Once again, thanks for the input,
Don
