Waiting for changes to be applied

So far iOS 5 has been just fine on my iPhone 3GS (yes, still), but for one important exception: I don’t think the phone has ever completed a sync without my having to eject it.

The symptom is one of those things that gives long-term iTunes users pause: text in the iTunes status window that appears at the end of the sync, saying, “Waiting for items to copy,” or “Waiting for changes to be applied.” And stays there, pretty much indefinitely. Turns out it’s a common problem, with no consistent solution. I have tried leaving the phone syncing all night long (both wired and wireless), even tried turning off syncing of all content. Nothing.

So today I tried the ultimate: restore to factory settings, then restore from backup. And, as of right now, things areā€¦ “waiting for items to copy,” while syncing podcasts.

Sigh. Wonder how long I have until we can buy the 4S?

There is one note of wonderment though: as I was plowing through the console looking for clues as to what was going on, I found this:

Nov 10 07:11:44 iTunesHelper[248]: AMDeviceConnect (thread 0x7fff7c774960): This is not the droid you're looking for (is actually com.apple.mobile.restored). Move along, move along.

Heh.

UPDATE: Aaaand just as soon as I pushed Send to Blog, I found the answer: voice memos. Specifically, deleting all voice memos on the phone was sufficient to fix the problem and allow the sync to complete. Now, mind, this was after a restore to factory settings and restore from backup, so I don’t know if those steps were necessary, but it worked.

Snow Leopard: Initial thoughts

I did the Snow Leopard upgrade last night, and it went OK.

First step was to back up my MacBook. It’s an exaggeration to say that it had never been backed up–I do, or did, regularly back up files to my .Mac iDisk, but rarely if ever did a whole system back up. A $99 external USB hard drive let me use Time Machine for the first time and I let that run for about three hours. Once it ran, I kicked off the installer and went to bed. (Yes, tempting fate.)

In the morning, I came down to the login screen. After login, about five copies of Software Update popped up, prompting me to install Rosetta so that “HP IO Classic Proxy 2” could run. I cancelled all of them, and went to HP’s site, where I found a suggestion that I didn’t need that driver, or any of HP’s software. Seems that the printer drivers are included in Snow Leopard, and scan support has been added to the built in Apple Image Capture application. Um, yay. Scan support from pressing the printer button is gone, but I never used that.

I couldn’t get my Cisco VPN working, but I should be able to get a later version of the client from work on Monday. Even better, I’ll be able to try out the built in VPN support once I turn up my connection file (it’s in a directory that’s not indexed by Spotlight, apparently).

Best of all? The update did free up disk space. About 11 gigs. Now that’s what I call a good upgrade.

Followup: Mac OS X ARDAgent vulnerability advice

Various parties in the Mac community have weighed in and suggested the best way to address the issue highlighted in last week’s advisory regarding an escalation of privilege vulnerability in ARDAgent. While some have suggested that enabling the remote access service may actually correct the privilege escalation, there’s been enough evidence that it doesn’t really work. And a suggestion to clear the setuid bit that allows ARDAgent to act as root appears to kill it, for at least some commentators. That leaves only leave two options:

  1. If you don’t need to have anyone remotely manage your application, just delete or archive ARDAgent.app.
  2. Restrict ARDAgent from being able to perform do shell script (as described in Martin Kou’s blog)

It would be nice if Apple just closed the hole, wouldn’t it?

While you’re at it, don’t forget to update Ruby (it’s part of the default Mac OS X installation), if you’re using it, to close a whole bunch of holes–from numeric errors to buffer overflows–in the core Ruby runtime.

And can we stop pretending that the Mac OS X platform is magically secure?

Serious new Mac OS X escalation of privilege vulnerability

Slashdot is reporting a new escalation of privilege vulnerability in Mac OS X 10.4 and 10.5. The details are a little sparse, but it appears that calling the Apple Remote Desktop Agent (ARDAgent) from AppleScript allows execution of arbitrary code with root privilege. Bad, for sure.

The mitigation is that it requires execution as the currently logged in user from the UI session, and apparently can’t be initiated over an SSH or other remote connection unless the attacker can log in as an account that is currently physically logged in on the machine. However, at a minimum it allows brute-forcing root access on any kiosk or other restricted machine that can be physically accessed. And one intelligent poster points out that all it takes is a phishing exploit that gets the user to execute the code on their own machine to open things wide up for a remote assailant–or a buffer overflow in (Safari, QuickTime, Flash, Firefox) that allows starting a shell.

Incidentally, simply disabling remote access is insufficient to prevent the attack. The ARDAgent.app must physically be removed from the machine. (For those interested, it’s usually found in /System/Library/CoreServices/RemoteManagement/.)

Apple needs to close this pronto.