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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:28:14 PDT