Tag: macosx

MacBook Pro shenanigans: FaceTime, the Keychain, and TouchID

Work bought me a new MacBook Pro at the beginning of the year. Because I’ve grown to value portability over the years, I asked for a 13″ model. Because I have a reputation as a geek, they got me the new model with the Touch Bar.

It’s been mostly great, but starting mid-summer there have been a series of odd things that have been extremely frustrating. At this point I’ve resolved all but one of them, so I thought I’d write it up.

Crashing while asleep: This one isn’t Apple’s fault. We use a corporate endpoint protection system that … has challenges keeping up with new OS versions, and sometimes causes things to really misbehave. For instance, it’s been causing our MacBooks to crash when attempting to wake from sleep. And that went on for about a year. They finally issued a compatibility patch that fixed the issue, but the (sometimes daily) crashes appear to have taken a toll on the system. For instance…

FaceTime and Messages problems: After every crash, I’d have to sign back into iCloud and re-log in to my Google profile on Chrome. A hassle, but doable. But after one crash and re-login, I noticed I couldn’t log into Messages: it gave me the message “An error occurred during authentication.” FaceTime had the same problem. I ended up calling Apple support, and their Tier 2 advised that it was likely a corrupt keychain. He suggested that I delete the login keychain and then recreate it. I decided that before I did that, I’d move all my local passwords to the iCloud keychain for safety. Which took a while, because I had to enter my password for every password entry it moved.

Then I took the plunge and deleted the keychain. The OS, thankfully, tried to recreate the keychain… and failed. Now I had a primary login account with no keychain, which is not a happy state. Logging into iCloud just gave me error messages when it tried to save things to the nonexistent keychain. Fortunately, after logging back in, I could recreate the keychain, log into iCloud, and finally get logged into FaceTime and Messages.

Touch ID. After these shenanigans, my fingerprints started to be unrecognized for login. So I deleted the fingerprint records in System Preferences and re-created them. But login was still failing. This one was easy to fix; I just logged out and logged back in, and my fingerprints started being recognized again.

iCloud Keychain. That brings us to the part that still isn’t working. All those passwords that I moved to my iCloud Keychain are there, because I can see them on other devices—but even after I’ve turned it off and back on, they aren’t syncing back to my Mac. Nor are any of the other passwords or secure notes I’ve stored there. Apparently one fix path is to turn off iCloud Keychain syncing on all my Macs and then turn it back on, the prospect of which fills me with a certain amount of dread. But we’ll give it a go, after I figure out how to back up the passwords, and we’ll see what happens. Look for an update soon.

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.