Slashdot Mirror
Worm Claimed For Apple OS X
SkiifGeek writes "Controversy is slowly building over the development of a claimed new worm that targets OS X systems, dubbed by its inventor Rape.osx. Using a currently undisclosed vulnerability in mDNSResponder, the worm is said to give access to root as it spreads across the local network. As with a number of recent Apple-related security discoveries, the author, InfoSec Sellout, is delaying reporting the vulnerability to Apple until after completing full testing of the worm. While the worm has yet to leave a testing environment (with 1,500 OS X systems), it is bound to join the likes of Inqtana and Leap as known OS X malware."
Disable mDNSResponder:
/System/Library/LaunchDaemons/com.apple.mDNSRespon der.plist
sudo launchctl unload -w
mDNSResponder is open source.
Multicast packets are routable, if the upstream routers support dealing with multicast packets correctly.
mDNS/bonjour/zeroconf detects if a packet has crossed a router by setting the originating TTL to 255. If a multicast packet crosses a router, the TTL is supposed to be decremented, and zeroconf is supposed to ignore the packet as it is no longer considered local. Many suppositions there, as implementations vary.
Worse, starting with a TTL of 255 means that the packets will be able to go anywhere on the internet where multicast packets can get routed. Better protected carriers will drop multicast packets with TTLs greater than 64 or 128, specifically to limit mDNS/zeroconf traffic while allowing reasonable traffic to flow. Most ISPs don't have the technical competence to deal with multicast, so they just block it, which will limit any spread of an mDNS worm.
However, just because mDNS/zeroconf will ignore packets with TTL less that 255, doesn't mean that a buffer overflow bug isn't being treated by the protocol stack. Take a wait and see attitude on this disclosure, as it appears to be an extortion attempt rather than something from legitimate sources.
the AC
Hemos is like...sci-fi fans;he thinks technology is cool, but he hasn't bothered to understand the science it's based on
If this is a real concern, there is a workaround to have mDNSResponder run without root privileges. Part of the claim is that they can deliver root payloads - this is likely because mDNSResponder runs as the root user and they might be using a buffer overflow exploit [NOTE: I have not analyzed the mDNSResponder code - this is a guess.]
/System/Library/LaunchDaemons/com.apple.mDNSRespon der.plist /usr/sbin/mDNSResponder /usr/sbin/mDNSResponder /System/Library/LaunchDaemons/com.apple.mDNSRespon der.plist
% sudo launchctl unload
% sudo chown nobody:wheel
% sudo chmod 4750
% sudo launchctl load
If someone wants an explanation of what the above commands accomplish, please read further.
1. launchctl is used to unload and load the mDNSResponder daemon.
2. We change the owner of the mDNSResponder to nobody and ensure that wheel is the group. The group is used to ensure that members of the wheel group may launch mDNSResponder and not other users of the system (with the exception of root and anything else running as nobody.)
3. We change the permissions of the mDNSResponder program to be setuid nobody. This means that mDNSResponder will run as nobody and only be able to affect files owned by that account or by files it may happen to have write privileges against.
No, just because you can't log into the account doesn't mean it doesn't exist. Type "sudo sh" and enter your password - presto, you're running a shell as root. Exploit any service running as superuser and you can do the same thing.
Visual IRC: Fast. Powerful. Free.