If you want on or off the Mac Ping List, Freepmail me.
Posted on 05/12/2005 1:43:51 PM PDT by Panerai
A security vulnerability in Mac OS X 10.4 Tiger allows a malicious .mov file to leak information to an external host. The exploit, which was discovered by David Remahl in Sweden, takes advantage "compositions," which have access to powerful tools known as "patches." Combining patches that provide advanced system information with patches that load information from the Internet allows an embedded .mov file to leak system details. A temporary workaround includes disabling the QuickTime plug-in and treating Quartz Composer files with suspicion. An alternative workaround involves disabling QTZ support in QuickTime by removing QuartzComposer.rcomponent in the QuickTime section of the system Library.
(Excerpt) Read more at macnn.com ...
Mac ping
Wow. This 'vulnerability' sounds a specious as the DHCP so-called vulnerability of about a year ago. That one only 'worked' as a security threat if the hacked had physical access to the DHCP server. Brother; if the hacker has physical access to your DHCP server, you've got big problems indeed!
If you want on or off the Mac Ping List, Freepmail me.
I agree. Note the concatention of steps and requirements for this exploit to be useful. No explanation of how these required steps are placed on the targeted computer... AND the necessity of someone placing the information to be leaked into a "patch"...
If the person has that information... why go through all these convoluted steps to "leak" it to another computer? Why not write it down on a sticky note, stick it in his wallet and walk out the door with it?
So the .mov file can leak... fix that potential... but don't claim this is a "security issue" unless you can explain how it can be placed on a computer remotely.
That's not at all how the DHCP exploit worked - the danger in that case was not to users on a stable, known network. In that case, you're right - you'd have to subvert the network's existing DHCP server. But the real danger was to wireless users promiscuously connecting to unknown networks - in that case, all the attacker had to do was have a machine that pretended to be a DHCP server, which would then exploit the LDAP bug when someone running an unpatched copy of OS X connected to it. Don't downplay the seriousness of that one - it's a true remote root exploit.
While I agree with you that the DHCP exploit did not require physical access to the targeted computer, it could only have been a "...true remote exploit" if the connecting user had activated and was operating in "root". In the Mac world this is extremely unlikely as the computers are shipped with root access de-activated.
In addition, IIRC, the DHCP spoofed server exploit required the user to log on to the network, encounter the fraudulent server, and then log off or restart the computer for the malicious fake server to gain access... another unlikely event.
That's (unfortunately) not true. Before it was patched, OS X implicitly trusted credentials it received from the LDAP server. Specifically, you could create your own root account, regardless of whether root was disabled or not, by feeding it info for a user with uid 0 and gid 0 - which is, of course, root. No reboot was required - merely a request to the DHCP server, which then provides the machine with the LDAP server, which in turn feeds it the root account with any username and password you want. And then you login via SSH, which is (was?) enabled by default. All this has since been patched, but it was a giant gaping hole while it existed, and still is on unpatched machines, unless they've specifically been configured to not take LDAP server info from DHCP servers, which is not the default setting.
Interesting that Carrel still has that particular claim on his web site.
Apple said that was not the case because activating root requires an administrator password (different from a root password that would be created when root is activated) ... and several other researchers also were not able to gain root access using this exploit. They apparently could gain Administrator access, the level below root.
No reboot was required - merely a request to the DHCP server, which then provides the machine with the LDAP server, which in turn feeds it the root account with any username and password you want.
We went all over this when this security issue was exposed. First of all, Carrel.org, the organization that kept pushing this exploit despite Apple's denials of much of what Carrel claimed says: "Anyone who can gain access to your network can gain administrator (root) access to your computer and therefore steal your data or launch attacks upon others as soon as you reboot your machine." That reboot had to occur while you were still connected to the network with the malicious DHCP server.
And then you login via SSH, which is (was?) enabled by default.
No, General, it is (was) OFF by default. It has to be activated with a password to allow the change.
All this has since been patched, but it was a giant gaping hole while it existed, and still is on unpatched machines, unless they've specifically been configured to not take LDAP server info from DHCP servers, which is not the default setting.
On another forum, another researcher posted that:
In order for someone to exploit this weakness, your setup with 10.2 or 10.3 has to:1) Have a network interface using DHCP to automatically obtain an IP address - pretty common2) SSH has to be active - off by default, the user has to turn this feature on
3) The root account is enabled - also off by defualt, the user has to turn this feature on
4) You re-boot your machine and the "weakness" is only exploitable during part of the boot process.
So while it is possible to hack into an OS X machine via this "Weakness" it's is extremely unlikely. Even if you had all of the above conditions, your computer would have to be singled out for attack as well.
"The new seed, which is marked build 8B13 of Mac OS X 10.4.1, fixes about a dozen new bugs, including issues with QuickTime Player, .Mac synchronization, Spotlight, and Mail."
Okay, yeah SSH is off by default - nevertheless, the rest stands. Why would you need to reboot to take up new LDAP settings? Are you supposed to reboot every time you connect to a new network? I don't think so.
I recall that it was because the targeted computer was already locked into the LDAP settings of the legitimate server... and reboot (restarting) withing the LAN or WAN was necessary for the targeted computer to latch onto the malicious server instead.
Was this a serious problem? Not really. Could it have been? Absolutely, if SSH were turned on... but it isn't and wasn't. No example of this affecting anyone in the wild was reported.
But General, this is not an intentional move from one network to another... it is not something the user would choose to do. If you want to discontinue one and move to another, you can... but this exploit did not do that. The user is not going to go up to the "GO" menu and select "Connect to Server..." choice and then willingly switch. The reboot apparently allowed this to happen in the background without user awareness. The point was that the user would then think he was re-connected to the original, trusted server but was instead being served by the malicious server.
Well, this is more of a privacy than security issue. I agree it's not a huge deal, but QuickTime movies shouldn't be able contact remote hosts without permission from the user.
But what I'm telling you is that the risk lies in the cases where you intentionally try to switch to another network. E.g., you're wardriving outside my house, spot my WLAN, and try to go to town on it. Or, you're at the local Starbucks, and you try to connect to their network. Any situation where you're intentionally trying to connect to someone else's network, basically. You can't seriously be telling me that OS X makes you reboot to do that. Right?
The point is not to surreptitiously hijack your wireless connection, the danger lies in when you intentionally connect to someone else's wireless net. At that point, on an unpatched box, the DHCP server on my network will assign you an IP addy, and give you the address of my local LDAP server, and then you're hosed.
No, of course you don't have to reboot to change network settings. But I believe hat user account information from an LDAP server would only be processed during startup. So if a rogue LDAP server tried to insert a root user, it won't take effect until the victim rebooted his machine.
Not quite... the LDAP server can change if the user elects to switch networks. By switching the LDAP setting is dropped and a DHCP address is requested from the new network and a new LDAP server is assigned. It requires a change. The reboot allowed this exploit to make the new DHCP request and be assigned the malicious LDAP setting.
What General_Re seems to be saying is that you can be in trouble if you connect to a malicious server... which is true. The point of this exploit was to place an unauthorized rogue server on an already trusted network and force the user to connect to the wrong server, not to have an unwitting roaming user connect willy-nilly to just any network he finds.
The point was made in a discussion forum for this issue that having a rogue server is not necessarily dangerous to the information on the user's computer. The data being sent through the rogue is at risk, but without the SSH being enabled the rogue server can only intercept what is being transferred to it or through it. Without SSH, the establishment of a rogue user, with whatever priveleges, cannot happen. Such a rogue server, lacking the SSH, could harvest passwords, credit card numbers, private information, etc., IF it was sent the data or the data was returned to the user from an external site. It could NOT search the user's computer for the data on its own.
This intercept capablility is not good... but hardly the compromise of the user's complete system. Apple estimated that fewer than 1/10th of 1% of OSX users have enabled SSH. Never-the-less, Apple released a work-around within a week and both a security patch and an OS update to address this issue in a short time.
Users who were computer literate enough to enable SSH (it's not needed for most internet activity) were probably literate enough to keep their systems updated. Are their some OSX users who have not updated? Probably... but very few. The chance of a hacker using this exploit finding a vulnerable OSX user is somewhere less than slim and close to none.
That makes sense, thanks for the clarification. So the victim could manually switch to the rogue LDAP server, but only by rebooting would it get picked up without their knowledge.
Apple estimated that fewer than 1/10th of 1% of OSX users have enabled SSH.
Interesting. I'd have expected that percentage to be higher since lots of geeks are running OS X now.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.