Mac OS and Safari not that safe?
It appears that access can be gained through Safari to files to files on Mac OS.
http://www.news.com/8301-13579_3-990...g=2547-1_3-0-5
http://www.news.com/8301-13579_3-990...g=2547-1_3-0-5
Comments
It can only be done by visiting malicious sites and the guy had it set up and ready to go (thus the speed), so as long as users are careful about where they surf then they should be OK until Apple fixes this, which they had better do real soon.
I haven't seen any information if this only works with with Telnet/SSH enabled.
As for as the exploit not being that dangerous, needing to go to a particularly crafted site...yadda yadda, many Office/IE exploits are like that, but MS does not get any benefit of doubt, but people just assume since it's Microsoft...
While Apple may have the better 'base' OS, I find it amusing, that this same hacking event was also won last year, by using a QT/Java exploit to gain access to the Mac.
I wonder if a similar exploit exists on the Windows version too.
Well, apparently the exploit was achieved by clicking on a URL which opened a port number on the Mac, which in turn allowed them the telnet to the machine.
I haven't seen any information if this only works with with Telnet/SSH enabled.
Where did you find even this level of description? If true, its doubtful this would even be an issue behind a NAT router. I'd like to read more but haven't found anything specific. Also, is would be nice to know if this is just for the new 3.1 (therefore in the newest webkit) and if so, when it was found)
Where did you find even this level of description? If true, its doubtful this would even be an issue behind a NAT router. I'd like to read more but haven't found anything specific. Also, is would be nice to know if this is just for the new 3.1 (therefore in the newest webkit) and if so, when it was found)
I got it from The Register. Not exactly the greatest of news sources...
Well, apparently the exploit was achieved by clicking on a URL which opened a port number on the Mac, which in turn allowed them the telnet to the machine.
...
Go back and reread the link in the OP. Access to MacOS X could not be gained remotely. On the second day of the contest, contestants were given physical access to the target computers. They used this opportunity to install cooperative code on their targets. Aided by their cooperative code, the contestants used social engineering as their attack vector. Apparently, real people played the parts of social engineering victims who had no choice but to do as they were told.
There may be a real weakness in MacOS X, but nothing in this episode showed that these weaknesses can be exploited in the real world.
Go back and reread the link in the OP. Access to MacOS X could not be gained remotely. On the second day of the contest, contestants were given physical access to the target computers. They used this opportunity to install cooperative code on their targets. Aided by their cooperative code, the contestants used social engineering as their attack vector. Apparently, real people played the parts of social engineering victims who had no choice but to do as they were told.
There may be a real weakness in MacOS X, but nothing in this episode showed that these weaknesses can be exploited in the real world.
Nothing was installed on the Mac, besides what comes installed by default - it was simply a Safari exploit.
From the link:
No one was able to execute code on any of the systems on Wednesday, the first day of the contest, when hacks were limited to over-the-network techniques on the operating systems themselves. But on the second day, the rules changed to allow attacks delivered by tricking someone to visit a maliciously crafted Web site, or open an e-mail. Hackers were also allowed to target "default installed client-side applications," such as browsers.
The team had attack code already set up on a Web site, and was able to gain access to the MacBook Air and retrieve a file after judges were "tricked" into visiting the site. According to the TippingPoint DVLabs blog, a newly discovered vulnerability in Safari was used to gain control of the Air.
On the 3rd day, Vista was compromised due to a Adobe Flash exploit.
http://dvlabs.tippingpoint.com/blog/...ay-and-wrap-up
So at the end of the last day of the contest, only the Sony VAIO laptop running Ubuntu was left standing.
Nothing was installed on the Mac, besides what comes installed by default - it was simply a Safari exploit.
According to this post on MacNN.com, you are mistaken.
...
The team had attack code already set up on a Web site, and was able to gain access to the MacBook Air and retrieve a file after judges were "tricked" into visiting the site. ...
By "tricked," they mean required.
Go back and reread the link in the OP. Access to MacOS X could not be gained remotely. On the second day of the contest, contestants were given physical access to the target computers. They used this opportunity to install cooperative code on their targets. Aided by their cooperative code, the contestants used social engineering as their attack vector. Apparently, real people played the parts of social engineering victims who had no choice but to do as they were told.
From the link in the OP:
According to the TippingPoint DVLabs blog, a newly discovered vulnerability in Safari was used to gain control of the Air.
In other words, they did manage to gain access to Mac OS X remotely by getting the user to click on a ULR.
From the link I posted to The Register article (this was also quoted on Daring Fireball), it suggests that there was an exploit in Safari which let the attacker access the MacBook via telnet.
As kim kap sol points out, SSH access is off by default, which leads back to my original question if this exploit only works with it enabled... It could be possible that the Safari exploit allowed malicious code to be run on the MacBook which turned SSH on, but until we get full details on the exploit we won't know for sure.
From the link in the OP:
In other words, they did manage to gain access to Mac OS X remotely by getting the user to click on a ULR.
From the link I posted to The Register article (this was also quoted on Daring Fireball), it suggests that there was an exploit in Safari which let the attacker access the MacBook via telnet.
As kim kap sol points out, SSH access is off by default, which leads back to my original question if this exploit only works with it enabled... It could be possible that the Safari exploit allowed malicious code to be run on the MacBook which turned SSH on, but until we get full details on the exploit we won't know for sure.
Even IF that were the case, that ssh or telnet was able to be turned on, you would then still need to know a user name and password to get in which would require additional 'social engineering'. Also, for most typical users, they would be behind a router and a NAT and therefore would still not be vulnerable to this unless the router was also compromised to direct Port X (ssh, telnet, high number) to the system being attacked. Since I run with all ports open and with ssh enabled - behind a NAT - this 'attack' would have zero impact on my setup in any case.
His CanSecWest contest-winning exploit took advantage of an overflow bug in the PCRE regex library used by WebKit’s JavaScript engine.
Good news is this bug is already fixed in the latest build of WebKit.
...
In other words, they did manage to gain access to Mac OS X remotely by getting the user to click on a ULR.
...
There is an old saying: None is so blind as he who will not see.
There were three target computers--a MacBook Air, a Windows machine, and a Linux machine. On the first day, none of the machines were breached remotely.
On the second day, the rules were relaxed. Each contestant was given access to his target and was allowed to install an automated agent on it.
As I stated earlier, the contestants' chosen attack vector was social engineering. Their simulated victims were required to follow the contestants' instructions.
It is not my position that there was no bug in MacOS X. However, a bug is not the same as a vulnerability, and a vulnerability is not the same as an exploit. We don't know what the specifics of what the winner required his simulated victim to do.
The first line of defense of any system is the user, which was eliminated in this contest. Based on what we know about this contest, it was equivalent to a test of a bank's security that required the teller to accept forged checks.
There is an old saying: None is so blind as he who will not see.
There were three target computers--a MacBook Air, a Windows machine, and a Linux machine. On the first day, none of the machines were breached remotely.
On the second day, the rules were relaxed. Each contestant was given access to his target and was allowed to install an automated agent on it.
As I stated earlier, the contestants' chosen attack vector was social engineering. Their simulated victims were required to follow the contestants' instructions.
It is not my position that there was no bug in MacOS X. However, a bug is not the same as a vulnerability, and a vulnerability is not the same as an exploit. We don't know what the specifics of what the winner required his simulated victim to do.
The first line of defense of any system is the user, which was eliminated in this contest. Based on what we know about this contest, it was equivalent to a test of a bank's security that required the teller to accept forged checks.
Pretty much...and the forged check wasn't created on the spot, it was created almost 3 weeks in advance.
The time that it took to hack the Mac over the time it took to hack Windows or Linux is irrelevant given that the contestants had a chance to work on their hack for a seemingly indefinite amount of time beforehand. I think it just so happened that Miller worked harder for the 10k$ than the other contestants and his knack to find exploits in Safari (he and his team found a few Safari for iPhone exploits a few months ago) made Safari in OS X the best target.
But social engineering is social engineering. You can't patch social engineering. And although the Safari team has patched something that permitted Miller to escalate privileges, nothing is stopping anyone from releasing a seemingly innocent app (a trojan horse) that asks for an admin password to take over the computer.
Like Mr. Me has mentioned, no computers were hacked while under the rules that computers had to be exploited remotely. *That* is the most important thing considering that's how most attacks are made. But when social engineering is added to the rules or a hacker gaining physical access to the target computer, we're moving away from things that matter. Social engineering can't be stopped and physical access to a machine is a highly unlikely scenario. Vista and Linux could have fallen first in the case of social engineering or physical access...but Charlie Miller had a nice head start.
Mac OS X has very little open ports out-of-the-box. If someone is careful with his web surfing habits and if someone doesn't hastily type his admin password everytime Mac OS X asks for it, there's no way you can get nailed by Charlie Miller's exploit.
It should still get fixed but the contest means nothing and this exploit goes to show how far hackers need to go to gain access to a computer.
Pretty much...and the forged check wasn't created on the spot, it was created almost 3 weeks in advance.
The time that it took to hack the Mac over the time it took to hack Windows or Linux is irrelevant given that the contestants had a chance to work on their hack for a seemingly indefinite amount of time beforehand. I think it just so happened that Miller worked harder for the 10k$ than the other contestants and his knack to find exploits in Safari (he and his team found a few Safari for iPhone exploits a few months ago) made Safari in OS X the best target.
This is the downside to open source. He had access to the source code, he pored over it for three weeks to find the weakness and he exploited it for the contest. Just because open source can mean many eyes can look at the code doesn't guarantee they will all be white hats.