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."

temporary work-around

[mzs]

Disable mDNSResponder:

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSRespon der.plist

Re:temporary work-around

[dch24]

Very good. That might disable the security hole, if what has been disclosed so far is 100% accurate. If not, well, all you lose is Bonjour (useful for discovering iChat and iTunes connections on your local subnet).

Re:Apple Coded

[Trillan]

mDNSResponder is open source.

Re:Is mDNS even routable?

[anticypher]

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

Have mDNSresponder run without root privileges

[e. boaz]

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.]

% sudo launchctl unload /System/Library/LaunchDaemons/com.apple.mDNSRespon der.plist
% sudo chown nobody:wheel /usr/sbin/mDNSResponder
% sudo chmod 4750 /usr/sbin/mDNSResponder
% sudo launchctl load /System/Library/LaunchDaemons/com.apple.mDNSRespon der.plist

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.

Re:Root Account Disabled...

[Mr2001]

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.

Re:Tipping the scales?

[v1]

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.

Re:Root Account Disabled...

[v1]

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.

Re:Have mDNSresponder run without root privileges

[QuantumG]

If something is remote exploitable, you turn it off. If you do what he is suggesting you're only making it slightly harder for your box to get owned. Oh, and this won't stop a worm.. as the worm almost surely doesn't need root.

Re:Surprise, sur-bloody-prise

[Anonymous Coward]

Sigh.

The code for mDNSResponder is open source [apple.com] already (under an Apache 2.0 license).

Enjoy [apple.com].

Learn to read.

[argent]

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.

Re:Have mDNSresponder run without root privileges

[gotw]

You might want to try 'ps -ax | grep mDNS'. HFS+ != case sensitive, grep == case sensitive.

Oops