Linked by Thom Holwerda on Fri 28th Mar 2008 20:39 UTC, submitted by irbis
"An Apple Mac was the first victim in a hacker shoot-out to determine which operating system is the most secure. A former US National Security Agency employee has trousered USD 10000 for breaking into a MacBook Air at CanSecWest security conference's PWN 2 OWN hacking contest. The MacBook was lined up against Linux and Vista PCs - which have so far remained uncracked. Nobody was able to hack into the systems on the first day of the contest when contestants were only allowed to attack the computers over the network, but yesterday the rules were relaxed so that attackers could direct contest organisers using the computers to do things like visit websites or open email messages. The MacBook was the only system to be hacked by Thursday. Miller didn't need much time. He quickly directed the contest's organisers to visit a website that contained his exploit code, which then allowed him to seize control of the computer, as about 20 onlookers cheered him on. He was the first contestant to attempt an attack on any of the systems." There is more bad news for Apple: "If you have Apple and compare it to Microsoft, the number of unpatched vulnerabilities are higher at Apple." Update: The contest is over. Vista got hacked using Adobe's Flash, Ubuntu was left standing.
Thread beginning with comment 307157
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-07-06
If that is true, the following observations come to mind:
1) telnet itself is obsolete because of security reasons, and sshd should be off by default in desktop systems (and regular user should not be able to turn it on).
1) telnet itself is obsolete because of security reasons, and sshd should be off by default in desktop systems (and regular user should not be able to turn it on).
The telnet service is obsolete sure. Telnet as a client is an easy way to connect to an arbitrary service on an arbitrary port. Taking as a random example it is a good way to connect to an exploit that is listening on a port...
2)Only root should be able to open a port.
Uh... you are aware that if an Linux distro were so ill advised as to do this it would break many things? The idea is only root should be able to open privileged ports.
3) Even if arbitrary code is executed as regular user, it shouldn't be able to get root account, except, maybe , by privilege escalation.
That is the definition of privilege escalation yes...
Privilege escalation is an issue in Linux as well (as discussed in the "fakesudo" thread in Ubuntu forums),
This has nothing to do with privilege escalation. this is malware.
but I think the risk can be avoided if you never su or sudo from your regular user account. Instead, create a new user from whom you su or sudo, and run a lightweight DE with this user in another tty, just to run synaptic and things like that. I'm assuming a user program can run a fake kde session fullscreen, but it can't capture CTRL+ALT+f8. I have to check that one, though.
So, even if it was a vulnerability in Safari, it was the OS fault if this led to a remote root login without the user entering its password. Not to mention that Safari is an Apple program, installed by default in OS-X, so there are no palliatives.
So, even if it was a vulnerability in Safari, it was the OS fault if this led to a remote root login without the user entering its password. Not to mention that Safari is an Apple program, installed by default in OS-X, so there are no palliatives.
It in theory will stop some privilege escalation attacks, but not all. In general setting up your system like that would be too inconvenient for most normal users (especially of OS X).
Member since:2006-09-27
Uh... you are aware that if an Linux distro were so ill advised as to do this it would break many things? The idea is only root should be able to open privileged ports.
Well, I was assuming some firewall beyond iptables (something like firestarter) was present. I don't know how much safer it makes the system, but I tend to use them. It doesn't come by default in Ubuntu, though.
" Privilege escalation is an issue in Linux as well (as discussed in the "fakesudo" thread in Ubuntu forums),
This has nothing to do with privilege escalation. this is malware.
"
Right, maybe my usage of "privilege escalation" was incorrect, but "malware" is too general. What I meant is dialog spoofing and similar strategies, where you first control the user account and then get the root password from the user input. That's what the fakesudo thread was about.
It in theory will stop some privilege escalation attacks, but not all. In general setting up your system like that would be too inconvenient for most normal users (especially of OS X).
I've been using this setup for a few months in Linux.I expected OSX to have something more convenient and about as safe. I haven't heard of a better way to avoid dialog spoofing attacks, but I'm open to suggestions.
Recent Original Stories
Recent Comments
Headlines
Random Comments
Random Stories
Random OS Link
Member since:
2006-09-27
The exploit involved getting an end user to click on a link, which opened up a port that he was then able to telnet into. Once connected, he was able to remotely run code of his choosing. "
If that is true, the following observations come to mind:
1) telnet itself is obsolete because of security reasons, and sshd should be off by default in desktop systems (and regular user should not be able to turn it on).
2)Only root should be able to open a port.
3) Even if arbitrary code is executed as regular user, it shouldn't be able to get root account, except, maybe , by privilege escalation. Privilege escalation is an issue in Linux as well (as discussed in the "fakesudo" thread in Ubuntu forums), but I think the risk can be avoided if you never su or sudo from your regular user account. Instead, create a new user from whom you su or sudo, and run a lightweight DE with this user in another tty, just to run synaptic and things like that. I'm assuming a user program can run a fake kde session fullscreen, but it can't capture CTRL+ALT+f8. I have to check that one, though.
So, even if it was a vulnerability in Safari, it was the OS fault if this led to a remote root login without the user entering its password. Not to mention that Safari is an Apple program, installed by default in OS-X, so there are no palliatives.