Safari hacked to root machine
 

From this article

http://computerworld.com/action/arti...&intsrc=kc_top

So the moral is try not to open urls you do not trust in emails. ?

I wonder if the latest Security Update fixes this. It seem to be about this sort of thing.

I just want to ask... some of you know security pretty well right? Is Apple an inherently more stable platform?

Just to clarify:
The exploit did not (as erroneously suggested by tlarkin's title for this thread) provide 'root' access to the machine. It provided access to the user account that Safari was running under.

I didn't know this website before.
Is it serious?

I ask this because, in my opinion, this section of the article doesn't add to its credibility.
I don't deny the facts presented, but to say that Macs aren't a big target because there are few, is a interpretation I disagree strongly.

What are your thoughts?

One more reason to not use an admin account for your day-to-day operations.

It seems like the user logged in as an admin and thus had access to run things at the root level, at least that is what I am guessing. The details will not be disclosed to anyone so we won't exactly know what all they had access to.

I saw it as, access to anything meant that he had rooted the machine, just my guess from the article though.

There was a second Mac that was not hacked. The rules on that one were that you had to get to root. The rules were relaxed on the second day to allow the hackers to surf to a malicious site using Safari. This gave them physical access to the machines, yet no one made it to root.

Recall that they are talking about remote access - i.e. shell access (command-line).
As you know, a user logged in as an admin does not have 'root' access in the shell until he or she uses 'sudo' and supplies their password. The exploit did not provide the users password, hence there was no 'root' access.

The usual level of reporting regarding security exploits on OS X is such that your best guess should be that the report is garbled and exaggerative if not actually completely inaccurate.

"Physical access" means that you are in front of the machine and can touch it.
That obviously was not the case here. The Safari exploit did not provide them with a teleportation device!

I really wish more details were available - not the specifics of the exploit necessarily, but of what behaviours should for the time being be considered risky.

The picture I am getting is that since nobody managed to exploit the machines remotely, the conditions of the contest were relaxed so that participants could send urls to the organizers, who would then access the site from the machine - ie. physical access by proxy. Apparently it is some sort of vulnerability in Safari's handling of javascript allowing the execution of arbititrary code. Sure, under these conditions, the exploit requires "local access" insofar as the user has to do something, but since all that the local user has to do is click a link, I would consider this to be fairly serious.

The admin vs standard question is very relevant here. The contest rules said something about the target machines being fully patched but otherwise "default Apple installations". This implies that the accounts were "admin" since the default account is "admin". If this is the case, since it is well known that an admin can easily get system level privileges without a password in OS X, it is quite possible that the machine was rooted. But again, the details are lacking so we can't be sure if that is really what has happened.

hayne-

I fully agree that it sounds very fishy, and overall it is not an exploit with OS X but rather safari. Also, they forget to mention since web browsers are designed to send and receive requests from remote hosts that it is a lot of times easier to exploit that feature over anything else.

I guess what I want to know is, what does "Access to everything on the computer" really mean?

The caption for the picture in the article below.
http://news.com.com/2100-7349-6178131.html?tag=tb

Sure looks like he was there. In fact, Dino Dai Zovi wasn't there, and Shane was his partner at the event. This article attempts to bolster the security by obscurity myth, but it does give facts about where you had to be to take part in the contest.

Yes he (Shane MacCauley) was there (at the conference) - the contest was only open to conference participants.
But as far as I understand it, the way it worked was you (as a participant) supply a URL (to a server that you control and where you have set up the malicious web page) to the conference organizers and the organizers use Safari to go to that URL.
If the server-side software (that you control) can get shell access to the Mac, then you have won the contest.

The objective of the first contest was to get shell access to the Mac under the account where Safari was running. That contest was won.
The objective of the second contest was to get shell access with 'root' privileges. The second contest has not (yet) been won. Hence it is easy to deduce that the access achieved by Shane MacCauley was not 'root' access.

By the way, the exploit apparently involves Java (not JavaScript) so if you want to feel safe while venturing into the darker reaches of the web, you might consider disabling Java in your Safari preferences.
And it seems that this is not just a Safari vulnerability - it has been reported that Firefox and Camino are probably also vulnerable to this exploit.
Reference: http://daringfireball.net/

I went to the edge of the internet once, it was scary and I barely made it back alive. If you have to go, bring weapons.

Right, the new exploit didn't -- in-and-of-itself -- gain 'root' access.

However... the few so-called "local" exploits left unpatched by Apple
(vis-a-vis MOABs #5, #15 and #21 to name a few), are some of the
ways an 'admin' intruder can run commands as root ... without any
user typing (or even knowing) a single password!!!

This is a good example of how hilarious it is when people scoff at "local" exploits,
arguing that *physical access* trumps everything... and so therefore [supposedly]
it isn't worth the bother to fix such types of vulnerabilities.

HA! As soon as someone finds some other remote entry-point, they instantly have
a tool-chest available to them for acquiring pwnership.

Am I correct... MOABs #5, #15 and #21 still remain intact and ready to go?

-HI-

Hey Hal,

I was reading up on some of the exploits, and I admit I am not guru of Unix but I definitely understand some of the foundations. Correct me if I am wrong, but haven't command paths always been somewhat of a problem with Unix and Linux in the past? I am not saying a problem like the exploits we see in other operating systems. I remember when I was first learning linux the tutorials I was going through always told me to use the full path of the command, incase there was some sort of command path put onto my machine by something else.

So, for an exploit to install a new set of commands in a different directory containing something like sudo and other commands that would require root, would that not require some sort of user interaction to be installed in the first place?

I am not trying to excuse any kind of flaw or lack of security apple may have, a flaw is a flaw, but I think that perhaps there are precautions you can take as a user to avoid these such things.

I used bash in linux so I my terms may be a bit off here for OS X, but mostly commands are stored in /bin /sbin and /usr/bin etc to my understanding. With the exception of some third party commands that store themsevles in a directory like /opt or what not (I am sure it is different in os x).

So, when I use a package that runs as root from like the /opt directory (like DRBL for example) what is stopping that set of tools from using its own commands? The package itself, if I recall correctly, installs and runs form the /opt directory in Linux.

I think social engineering would have to play a lot into it, which of course it does for windows no doubt. So, then a user with administrative rights, thus gaining sudo rights from /etc/sudoers would have to install said exploit correct? So where in lies the blame if third party applications may run at whatever level but use commands in totally different directories? Apple or the third party?

I guess I don't totally understand apple bash structure and what is put into the home directory under their .plists compared to what like some open source linux distro has. I know they are different operating systems, and its hard to learn everything about everything.

So there are definite precautions a user or administrator can take when running certain commands to avoid this type of situation. From what I gather though, a lot of these scripts, or exploits would require at least some user interaction?

Perhaps Apple's default permissions are not strong enough out of the box, but then again it is a consumer operating system. Perhaps, you, yourself could modify some of the permissions to make it stronger?

I support several mac servers and lots of mac clients at work, and we do some some things locked down. Now user has admin privledges, admin accounts are hidden, normal users can not view any unix directories, so on and so forth.

These exploits that are mentioned on the web concern me to a small point, but at the same time most of our users would never really get to the point of writing shell scripts or exploitng the bash command path, at least I would think not. I have not run into yet since I have worked here. Not to say that a malicious download couldn't do it, but that would require admin privledges in the first place to install somewhere that would matter. I am curious about exactly how these exploits work. I see a lot of technical docs on them, but I found nothing too in depth. I see a lot of possible and a lot of maybes, and maybe a proof of concept but I don't see anything doing any major damage that is out right now. This is no excuse either for the lack of security.

I guess what I am trying to say is, this exploit mentioned seems to be more of a safari exploit rather than the OS, and would require interaction of the user to click onto these URLs and it transfers itself via java.

Now, one strange thing I have seen at work, is that safari just plain doesn't work. every other browser works fine (camino, firefox, etc) but safari doesn't. When this happens a quick fix we found was to just replace the java and the webkit frameworks (can't remember if those were exact, have only seen the problem like 3 or 4 times total) from a working machine just over the network and safari works again.

Also, are there not precautions an administrator can take to avoid these exploits? I mean we are talking about a default permissions settings out of the box right? I see a lot of people saying fix this, or look at this, but I don't see anyone speaking up (the media probably has a place in this) saying hey, yeah there may be this exploit but it is avoidable by doing this.

Got any links anyone so I can learn more about it?

thx

its late and im tired but can't sleep so if this makes no sense I appollogize.

This is based solely on the amount of credit given to Shane, but I get the feeling that more needed to be done on the client side than just surf to the site. Maybe we'll know more in a few weeks.

At least the 3Com people are dealing with this somewhat professionally, unlike the MOAB guys.

If this is a Java sandbox bug, as has been suggested, it likely reaches beyond Safari. Apple does their own builds of the Java VM, but hopefully someone will inform Sun too, so they can test for it.

Actually, last week's SecUpd2007-004 supposedly did patch MOAB #21. Like you, I had already implemented the suggested workaround so I can't test it directly.
http://docs.info.apple.com/article.html?artnum=305391
But there are still other ways to go from admin to root without a password so your argument still holds.

Remember the poll on here a while ago that showed (albeit with a puny sample size) >80% of respondents of people on this site (i.e. a population that I would expect to at least have a bit of a clue) indicated that they routinely used an admin account.

So I think the fact that under the conditions of "pwn to own", nobody "got root" is somewhat academic since someone was able to get user level privileges, and >80% of users use an admin.

In fact, I'm wondering if that was the difference between the two machines - one logged in to admin and one logged in to standard, and noone was able to pull off the standard -> root escalation.

But I think click to pwn exploits (conditional on admin login) have been described at least a couple of times in the past (one for sure) so it wouldn't surprise me if this represented another example...

tlarkin!

Egads, many good questions. I'll rearrange the text a bit and try to answer
what I can as best I can. Your specific inquires mostly centered around #21,
so I will tackle that first. Then I'll address #15 and #5 together, since those
two are somewhat related (via Disk Utility and permissions). Links will fill in
where I feel lazy or incompetent.


•1• Yes absolutely. One of the more concise yet complete summaries I have found
thus far is: "Enhancing Security of Unix Systems"



•2• No and none.

No root access required to *install* and no user interaction needed to *install*.
I mean... obviously, a web page containing this Java exploit needs to be visited
to kick things off. It can't slip through firewalls by some port scanning bot, or
enter via osmosis from the ethers... so we do stipulate that much interaction.

/Users/Shared is an ideal installation location (drwxrwxrwt). The only potentially
slippery part is that poisoning the user's $PATH requires write access to both their
home folder and their active ".profile" (.bash_login, .bash_profile, .bashrc, etc).

But the Java/browser hack does get beyond both those barriers so, hi-ho, hi-ho...

Here's a typical user-configured path:
Thus the intruder script checks for a pre-existing ".profile" type (and
creates one if need be), and then does something like:
That creates a hidden folder ".badbin" wherein they can store custom
commands, and places that folder **first** in the path search queue:

/Users/Shared/.badbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:~/bin

Ouch.

We could perhaps have "echo $PATH" as the last line of .bash_login to give
Terminal users an immediate clue, but that won't help scripts which run by
themselves (cron, launchd, etc.) that don't declare their paths explicitly.



•3• Not a thing, AFAIK.



•4• Sometimes. The path problem presents many variations. #21 specifically pointed
its finger at /sbin/service, because that Apple shell script does run as root... AND
does NOT specify a $PATH variable. So it inherits its path from the "environment".

Therefore, the level of user interaction required for the specific #21 example was
for the user to open System Preferences and click on some button which results in
execution of the /sbin/service script. At that point, any command called by service
(excluding shell built-ins) could be hijacked (substituted), and they'd run as root.

This one I found by myself a while back: Does /usr/sbin/periodic declare a path?
Not the last time I checked it didn't. Does it run as root? Yes... every single time.
[I don't think enough people appreciate that one]. And finally, do the daily-weekly-
monthly maintenance tasks require "user interaction"? No, thanks. (Double ouch).

Naturally, $PATH also affects Terminal. Okay YES, "user interaction" *is* required.

But imagine this: let's say you type 'date' in Terminal, and then -- along with the date
appearing on the screen -- your entire Documents folder were to disappear behind the
scenes... only on even numbered dates (for example). Is there some consolation in the
fact that "user interaction" was required? That example might seem silly, because the
admin intruder already could delete your docs. The point there would be about pulling-
off pranks which might be hard to track down. (Unless the Documents folder was open
at the time so we *saw* when it occurred, such weirdness could persist ad-infinitum).

All that hassle from a simple command (date), and it needn't even involve sudo.
[had the user typed the full pathname '/bin/date' then no nonsense would occur]

More likely, the hijacked commands would test privileges to see if sudo was used
and then do much more dastardly deeds. [That article also describes another little-
known customization method: defaults write ~/.MacOSX/environment Shell /bin/bash]

What I have done is: to lock down all ".profile" type files in my home, and I even
created blank ones that I didn't have and secured all those, as well as that hidden
environment.plist above. [All via chmod 444; sudo chown 0:0; sudo chflags 2.]
Paranoid? You bet. (I like being logged in as an admin so I need to be paranoid).



•5• Yes but, that's what users do right? They interact with their computer.
They do open System Prefs; they do run Terminal; they do "browse".
Servers may just sit there and serve... but clients continuously click.

Anyway, *my* whole point is that there shouldn't be these "MOAB" flaws
on everyone's Mac, weakly waiting for scripts to use them for escalation.

I understand the other side of the argument as well: don't surf any place you
never been, don't download anything you don't trust, don't open anything you
don't know, don't login as an admin user. That prophylactic is too tight for me.



•6• Yes to that one. First, let me point out a permissions peculiarity: Save this page from Safari
as an html document on your desktop. Guess what the doc's "group" is... admin? yourname?

No. Safari saves docs with the group wheel (and Script Editor too). How absurd. Why so strict?
Yet... there are sensitive files (the setuids from #15 and the boms from #5) which DON'T get
membered to wheel: *they* are 'admin'!!! WHY?? That's so totally bass-ackwards.



•7• Right.

And in fact, that's part of the secret to how both #5 and #15 work their magic.
They edit an admin-writable file (or create one) and then "repair" permissions
on it from their intruder script. That "repair" is what upgrades their other script
to root status. (It's an insidiously clever idea). And that *also* means we can't
merely tweak the *perms* on the files (from #5 and #15) we want protected...
because any attempt that doesn't include *locking* them can all be undone by
the exploit, via an initial /usr/sbin/diskutil repairPermissions / :eek:

So the files (and probably their parents) need to be locked with chflags.
Group everything to wheel, read-only too. Set sticky bits on the parents.

I also posted an article showing how to tweak perms in the bom files, but
that's an impractical approach. I am almost finished writing another script
which simply secures the entire receipts folder... but, there already exists
such a solution, over at carrel.org (written in Python).



•8• And *that's* why this latest Safari hack is so significant IMO. It achieves the initial
step of going from nothing at nowhere to being a secret admin in the house. And
all the real user needed to do was land on the wrong web site by clicking a link...
not knowingly "downloading a file." I find that a scary situation. How do you know
the links in my post are safe? Is Java turned off in your browser? Or do you just
trust my judgement and/or values? [I could always say "I didn't know either".]



•9• I've tried to provide some depth, and linked to examples. If you ask more specific
(and a limited number of) questions, I'll try to help if I can.

Interesting point about the media. idunno. The reasons could be numerous:
First, the MOAB folks came off so completely assedelic that no "reputable"
organization wants any perceived association with MOAB's public persona.

Second, my 3 pet MOABs seem to be viewed by most in a totally "local exploit"
context... and not considered as potential tools for *other* (remote) exploits to
employ. Out comes the 'physical access' argument, further down the priority list
they get moved, end of "story".

Third, there may also be a lack of understanding on the one hand, and also a full
comprehension/appreciation on the other... both which tend to decrease incentives
to publish: It's 'yesterday's news' to the former, and 'mum's the word' for the latter.

Forth, as you aptly point out: evidence of these exploits in the wild are all but nil.
[With luck, maybe one will bite a member of Apple's BOD, or something like that.]



•10• As rude as MOAB was, I believe they did offer some advice to users about avoidance.
Here are three links:
[but, I don't think removing suid from the DiskManagementTool is anything for me]



•11• This one goes back to the mid-90s (c.a. System 7.6.1?)
Secure Programming for Linux and Unix HOWTO

There are probably tons of similar pages. I have a cool pdf (no link) called:
"How Attackers Attack Programs, and How to Write More Secure Programs".
It could probably be found quickly by googling on the author "Matt Bishop".

Anyway -- like you said -- some of these are well-known lessons already learned.
Apple does so amazingly well in other aspects of security, I just don't get how or
why certain fundamentals have been overlooked here and there for so long now.

And seeing as how 10.4.9 plus 3 Security Updates have all emerged *after* MOAB,
yet these issues still weren't patched, I find the whole situation to be quite odd.

I suppose if the iPhone can postpone Leopard for a fiscal quarter, we can attribute
our current status to the (money-making) iPod & iTMS development.

:rolleyes:

-HI-

Must have been very sneaky about it. When I view the package with Pacifist,
I don't see any files there relating to /sbin/service (or /usr/sbin/periodic ;) ).

They need to add PATH=blah:blah:blah to those scripts.
The modified dates don't reflect any change here either.

I need help now... HOW did they conquer #21 ?

(Anyway, users will need to secure their own ".profiles" too.)

It's really a conundrum...

SecUpd2007-004 did update 'writeconfig'. The result of running 'diff' on the 'strings' output from the old and new versions only turns up a difference of two lines - the new one has:Since '/sbin/service' inherits its path from 'writeconfig', fixing 'writeconfig' would be one way to approach the problem. So could it be that the update fixed the problem (as pointed out by MOAB #21) of 'writeconfig' lacking "path sanitization"?

Hmm, you know I guess I never thought of someone exploiting disk utility to repair permissions on a machine returning it to apple's default permissions for attack....interesting....

I typically browse the net with my linux box or on my PC. I really don't do lots of web browsing on my macbook pro. Its mainly a work machine, I mainly do work things on it, and I do some research with it.

My two desktop Macs at home are a server and a workstation for my little OD test environment so they are pretty much just storage boxes.

I did turn java off on safari though.

More info has been released about the nature of the exploit - it involves QuickTime functionality being invoked via a Java applet on a web page.
It affects other web browsers (not just Safari) and probably also affects Windows if QuickTime has been installed.
See: http://www.matasano.com/log/812/brea...32-apple-code/

wow thanks for the link hayne. I actually never use apple's quicktime on my windows machines, I use the quick time alternative, not sure if the exploits work the same with the alternative.

[corrections & clarifications]

A few tests show that -- when periodic auto-runs at the behest of launchd -- it gets its
environment from the "System-wide" /etc/profile, rather than from the user currently
logged in. So -- when the maintenance tasks auto-run -- the user's $PATH has no effect.

I.e., no "ouch" for system-run instances of periodic.

While that much is great news, the path problem would potentially surface if users
themselves run "sudo periodic daily weekly monthly" in Terminal or via one of their
scripts. Therefore, the advice I gave above is *still* an excellent precaution to take:

> What I have done is: to lock down all ".profile"-type files in my home, and I even
> created blank ones that I didn't have and secured all those, as well as that hidden
> environment.plist above. [All via chmod 444; sudo chown 0:0; sudo chflags 2.]


Okay biovizier... we were both right: it is fixed... and they were sneaky.

I thoroughly searched the entire SecUpd2007-004 package, and
I still don't see *where* that change to /sbin/service came from.

[/corrections & clarifications]


--


#21 addendum

It may be of interest to note that -- while it's factual to say that
"#21" was fixed -- that's really only true by 'the letter of the law',
but not in *spirit* IMO. There exist more shell scripts which do
not declare paths either. Good practice would entail setting their
paths as well. Here is a *partial* listing...
Inheritance is the default mechanism, but it's nigh impossible to
test for every possible combination of how something might get
called. A specific declaration renders such tests unnecessary and
eliminates all exploitation along that avenue. Of the partial listing
shown there, I find periodic, apropos and whatis most troubling.

I get the feeling that -- unless someone finds a precise example
where an exploit does occur -- those files (there are actually about
100 of them) will never be updated to explicitly declare their paths.

My point of view is this: okay, #21 was fixed... but what about #21a?,
#21b?, etc. I.e., why not globally implement a known safe programming
technique from the get-go, instead of waiting for someone to find a way
of taking advantage of the issue? Why not fix that **general** defect
**everywhere** it exists right NOW, so that such available weak-points
are totally eliminated?

Not doing so simply further increases the possibility that they (or some of
them) will become part of a **future** round of "MOAB". Instead of taking
a full-on preemptive approach, what we got seems more like Plug-And-Pray.

At the end of the day however, it is still up to (security-conscious) users
to secure their "purveyors of $PATH" everywhere they could be attacked.

[i.e., the '.profile lock-down' inside our home, mentioned above]

-HI-

In an interview with Zdnet, Dino Dai Zovi explains that this hack required help from Shane Macaulay at the conference, so he apparently did have physical access to the Mac and that access was critical to cracking it.

I won't be turning off Java in my browsers. ;)

HAL,

I am no marketing genius or anything, but I would think the reason that Apple doesn't reinvent the wheel in every aspect of the OS is because they do not have the resources for it at the moment. I can only assume a good number of their developers were and are still working on the embedded OS X that will be loaded on the iPhone, and I can only imagine it won't be long until we start seeing it on other devices, ipods, and perhaps maybe even an OS X palm device, who knows? Apple is a company and they need to making money first and foremost otherwise they cannot develope their products and pay their employees.

As for the exploit in question the more I read about it, the more I think its not really totally related to OS X and its an exploit that could be used in many different OSes and browsers or perhaps even applications that are java like Hayne mentioned few posts back.

I just wish they would explain the nature of these exploits so I would have an idea of exactly what was going on, but that will never happen.

As mentioned above, the exploit in question is one that involves QuickTime and Java and so could be present on any platform where those software components are installed. At the moment, QuickTime is only available for Windows and OS X as far as I know.

I think the exploit will be explained as soon as Apple has fixed the problem - that is the usual case with properly reported security issues.

well FWIW, and it may be a bit off topic, but I use this on non mac platforms instead of actually running quick time

http://www.free-codecs.com/download/...lternative.htm

I think you are misinterpreting what has been said. It is indeed very confusingly written, but I'm fairly confident in my understanding (from reading that interview and all other articles that I've found) that the exploit merely required the person in front of the Mac to visit a specified URL. After that, the rest can be done remotely - and was done by Shane on some other machine at the conference.

Yep that was it, 100%. Thanks *AGAIN*.

I spaced out there... that was MY fix. (does no one check what i write? :p )
I simply forgot I had put those "# [moab#21]" comments in there long ago.


--


Well you got the spelling of their names right looks like,
but missed the point entirely. It's a "drive-by" attack...
land on a bad guy's web page and it's curtains for you.

Ok, maybe I just don't understand. Can someone explain why it is that the hack is able to take over the machine, yet requires the user to 1) connect to the shell and 2) follow instructions (plural) to succeed? That just doesn't seem like a "drive-by" to me.

I've pieced this together from various news accounts:

Dai Zovi [who has previously been credited by Apple for finding flaws in Mac software],
did not attend the conference... but found a Safari vulnerability. He wrote the exploit...
but since he wasn't a contestant, didn't qualify for the prize. So he contacted (emailed?
called?) his friend Shane -- who WAS an attendee -- and either gave him the url of his
booby-trapped website, or sent him the code to set up on a server at the conference.

Seems like it was the rule-constraints of the contest which may be part of the mixup.
[Judges probably needed to see the source to verify that a password wasn't leaked.]

If you read the interview with ZDnet, Zovi states that he wrote the code, but Macaulay "ran the actual attack." That sounds to me like much more than simply surfing to the site.

Well... so?

That might mean he could do more than just jam a script on the target
Mac. Maybe he was able to open a full session and attain real time I/O!

idunno.

Look what's your point? You think they paid him $10,000 for something
that **wasn't** a bonafide hack? I wasn't there either... and they have
not released all the details, step-by-step. If you want to keep Java on,
I can't stop you.

:rolleyes:

The original article does a pretty good job of explaining how it was done:
So it looks like since people couldn't get into the machines to do anything by being there they opened it up to people getting email (on the computers) and clicking on a link to a web site that had an exploit loaded on it.

From what i read it takes the user of the comptuer going to the web site but once at the web site nothing stops it from doing its nasty voodoo on the machine.

Again, just how I read the article.

I think an article written by a journalist counts for less than the words of the guy who actually wrote the hack. I'm not saying it doesn't technically qualify as a break in for this contest. I'm just saying that based on what Dino actually said about it, I feel pretty safe since I don't think I'm likely to take the steps that Shane did, in the event that some one duplicates this feat in the wild.

But if you read further down in the interview you linked to, Dino Dai Zovi is quoted as saying
http://blogs.zdnet.com/security/?p=176

But still it's all speculation at this stage. I personally will be erring on the side of caution.

Yes, I saw that but after saying what he already had, it seems like he was trying to minimize the user's actions to make the hack appear to be more than it was, which was enough to win the contest within its rules, but probably not much more.

I'd like to see this hack tested by sending the link to a computer not touched by anyone trying to hack it. An impartial 'judge' would click the link and do no more. If it works under those circumstances, then I'd believe it.

It is clearly stated that the contest is only open to attendees of the conference. What I am guessing that means is that the Mac in question was not accessible via the wide Internet but was only accessible via the local area network of the conference. Hence the malicious web site was running on one of the attendees machines that was physically present at the conference. So what Shane needed to do was to set up the web site and perhaps to manually react when the web site was visited. Shane did not need to do anything on the Mac in question - all that was required was that the organizers visited the supplied URL on that Mac.

In all honesty it is not that unbelievable, the sole purpose of a web browser is to send and receive requests over the internet/network. If this exploit was done through java and the browser had java enabled, and all that was needed was a visit, then boom your rooted/infected/whatever seems possible to me.

I mean how does safari initially react to java applets, scripts, and the like when hitting a web page?

By itself it is very believable. In the context of a contest that was set up from the begining to find a winner by relaxing the rules over the course of the contest, it's suspect. Just how much did they relax the rules? Nobody seems to know, which makes me more suspicious.

You think... $10,000 for a gag... something Mac users will simply laugh at later?
Sounds like a stretch. How do you figure that one? [explain]


Do you know anything about shell scripts?

Do you actually believe there's something a human can do (in this context)
that a script can't do a *million* times faster. What could that be I wonder?
I don't see what more anyone here can say that hasn't been said already.

Anyway, I saw reference to a line saying the objective was to get a "shell".

So the person doing the typing was playing the hacker's role, typing as he
wreaked havoc on the remote Mac. (I already said as much... but it seems
you conveniently ignored that explanation). How do we know YOU'RE real?

:p

As I pointed out above, this whole affair has been very badly reported. And cwtnospam has been confused by the reporting about what Shane did.

Here's what happened as far as I can piece it together.
There are two machines on a local wireless network:
Machine A is the Mac that is the target of the attack. Machine A is in the possession of the conference organizers and is not physically accessible to anyone else.
Machine B is some other arbitrary machine that Shane Macaulay has in his possession. (There is no requirement that this machine is a Mac.)

Dino Dai Zovi communicated his idea for the exploit to Shane Macaulay. He gave step by step instructions to Shane on how to set up the malicious web site on Machine B and then what to do once the attack was triggered (via the specified URL).

Shane told the organizers the URL for the malicious web site and the organizers used Safari on Machine A to go to that URL.
This provided shell access on Machine A to Shane who was on Machine B.

www.securityfocus.com/archive/142/464216/30/0/threaded

There's the 'progressive' rules part.
[move up to read the whole thread]

I don't know anything about the shell he connected to, or even if he connected to it without first physically accessing the test computer, so I don't know what could be accomplished in it. I do believe that there are many things a user with physical access to the computer might be able to do that the shell might not.

Once again, I'm not saying that he didn't succeed according to the rules of the contest. I'd just like to know exactly how far those rules were relaxed. I guess I trust this Dino guy more than I do the organizers of the event, who are after all part of the same 'security' industry that's been doing everything it can to scare Mac users into using AV software for years.

Hmmm, I must have been typing my previous post while you were posting this one. I guess that answers my question then.

As long as we got this far, there are a pair of articles at roughlydrafted,
one at arstechnica, two (so far) at rixstep... one of which leads to these:

http://security-protocols.com/sp-x45-advisory.php
http://security-protocols.com/sp-x46-advisory.php

Apparently two flaws reported by one Tom Ferris, first one over a year old.

[Not sure they're what was used the other day, but it seems to be implied]

--

Admittedly: it's not too likely anyone will actually run across an
example of this... and (by itself!) root was never attained... and
(by itself!) it contains no worm characteristics... so we don't need
any tin foil hats.

But neither should we take away from it that which it does deserve.

At this point, it must get patched... or it would be the the beginning
of much bigger headaches. No doubt.

Check your "Software Update" - "Security Update 2007-004 v1.1" and "QuickTime 7.6.1" are up...

Edit:
Just to clarify, the QuickTime update addresses the vulnerability that is the topic of this thread.
The security update is for something else.

so I am confused still, so the media just basically reported this it a totally FUBAR'd way?

So, did the guy really get the 10,000 dollars (haha reminds me of the simpsons when they had that film festival!)??????

Well, one consequence of the QuickTime update appears to be killing a class of animated ads, including the ones we display here. They must have depended on some QTforJava 'feature' that was changed in closing the security hole. Or maybe the Flash plugin used it?

They must not be in the audible.com ad, because I see the animation in that.

All I see is the QuickTime logo with a question mark through it. The Apple site, by comparison, behaves normally.

This is in Safari, by the way. I have not tried other browsers yet.

Have you changed your Quicktime settings? Maybe turned off Java? I'm using Safari, I've applied the patch, and I see the ad.

Hadn't changed them lately, but I fixed this display problem by going into the QuickTime prefpanel and under Advanced->Mime Settings->Miscellaneous telling QuickTime to not handle Flash media. I must have set that at some point. Now, all is back to normal.