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.
I doubt they are nearly as worried as they could be. From the looks of it, it can only spread locally on your subnet. Internet worms like code red, that can infect 70% of the vulnerable machines in the world in eight minutes, vs this whic may infect up to 254 machines on the typical network. Anyone that even attempts to put those two exploits in the same timezone needs a beating with a ClueBat.
I work for the Department of Redundancy Department.
All unix requires the root account, it's not really that accurate to say disabled. More like "inaccessible", or to say that "logging in as root is disabled". The password hash starts set to a value to which nothing can hash to, and so there is no valid password to login as root. To "enable root" is simply to set a legal password for it so you can login as root. 99% of mac users will never enable root, and most of them don't even know it exists to enable.
To do root level things uses "su" (substitute user) - you can "su root" meaning do something with root's privs, so in that perspective root is always enabled, but only administrators can su, and that requires one to enter their administrator password, which a virus would have a tough time with.
So yes, it would have to take over an account that had aministrator rights, and use that to do whatever. For all practical intents, an administrator can be root anytime they want to, so there is no need to get root. Getting an admin would be enough.
The OS X Server (as opposed to the Client which many think is all that exists) has root enabled by default, with its password set to the same password as the first administrator you create. Not sure why they do this, it's not really necessary. They probably assume that almost every sysadmin will want root enabled and will be close to first on the order of business if it were not the default.
I work for the Department of Redundancy Department.
Sigh.
The code for mDNSResponder is open source already (under an Apache 2.0 license).
Enjoy.
From the things I read, Mac OS X is just as vulnerable and dangerous as Windows.
You need to read deeper.
OSX: No routed open ports by default. All services can be bound to localhost only. All IP-based services can be disabled. Conventional browser that requires applications to install extensions. Can be run securely with no firewall in place, the optional firewall is "defense in depth". It's not perfect, but the "surface area" exposed to remote attacks is small and can be eliminated.
Windows: Routed open ports by default, most services are promiscuous, and some listening services are required for normal operation of the OS. Browser built around embedded code, and the ability to run remotely provided embedded code can not be removed without disabling the browser and parts of required utilities. Firewall is enabled by default because it's required to close *most* direct remote attacks (but not all, and not attacks through the HTML control). Even with the firewall in place Windows has a larger surface area to exploits than any other OS in use, and you can't eliminate it without disabling basic OS functionality.