16

After the 10.11.1 update, I can not get access to some of encrypted data stored in my keychains with Keychain Access.app. Most notably, I can not see or copy passwords stored.

Normally, to do so, you'd have to:

  1. unlock a keychain with keychain password;
  2. unlock an item itself with keychain password.

During 2nd step, when password is typed in, you can select 2 options: "Allow" and "Always allow". The difference is that if you click "Always allow", you won't have to perform 2nd step for this item again.

Here's some things I was able to detect:

  • if I had clicked "Always allow" on an item before OS X update, I can access it fully;
  • if I haven't clicked "Always allow", I can not copy password from right click menu, nor see it when ticking "Show Password" checkbox on Info Screen.
  • if I add new item, I can not copy password from right click menu, but can still see it on Info Screen.

I get what seems to be mostly full keychain data using following command (though, I am not sure everything's there):

security dump-keychain -d elmigranto.keychain

UPD: After more detective work, I found following message appearing in Console.app when I click anything in password dialog:

26.10.15 10:19:52,345 SecurityAgent[770]: Ignoring user action since the dialog has received events from an untrusted source

UPD2: Pretty sure this is caused by HT205375, which among other changes lists the following:

SecurityAgent

Available for: OS X El Capitan 10.11

Impact: A malicious application can programmatically control keychain access prompts

Description: A method existed for applications to create synthetic clicks on keychain prompts. This was addressed by disabling synthetic clicks for keychain access windows.

CVE-ID

CVE-2015-5943

Improve this question
5
  • 2
    Do you have any third-party utilities running, like Alfred, KeyCue, TextExpander, etc?
    – Kent
    Commented Oct 28, 2015 at 1:16
  • 2
    @Kent Nice tip, looks like MagicPrefs causes this behaviour.
    – Aleksei Zabrodskii
    Commented Oct 28, 2015 at 4:27
  • 1
    Great! That's what I expected. I expanded on what is (probably) happening a little in the answer.
    – Kent
    Commented Oct 28, 2015 at 4:32
  • Not a duplicate, but maybe related: apple.stackexchange.com/questions/214834/…
    – WGroleau
    Commented Nov 10, 2015 at 3:31
  • Works fine now on 10.11.5, at least for installing signing certificates.
    – dbernard
    Commented Jun 27, 2016 at 14:48

5 Answers 5

Reset to default
19

Third-party utilities such as Alfred, TextExpander, or MagicPrefs might appear to take "control" of the window as far as the OS is concerned. You can find the culprit by disabling them all, and turning them on one by one until you find one (or more) which affects Keychain in that manner.

You can add the offending program to the list of approved apps ( System Preferences -> Security & Privacy -> Accessibility ) and this issue will go away. (hat tip to @elmigranto for this addenda)

Improve this answer
10
  • 4
    The solution to this is to add a program to the list under System Preferences / Security & Privacy / Accessibility — then you won't have to quit an app every time Keychain prompt pops up.
    – Aleksei Zabrodskii
    Commented Oct 28, 2015 at 4:54
  • Glad that there's a setting to change. I haven't upgraded anything to ElCap yet, so was not sure where to go about adding the trusted apps.
    – Kent
    Commented Oct 28, 2015 at 6:42
  • @elmigranto any way to determine what app cause such a malfunction of the keychain prompt? Is it triggers when suspicious app is running, or when found them on a disk? I've tried to add as much apps as I suspected in a using of global hooks [Flycut, Karabiner, MagicPrefs, PuntoSwitcher, Seil], but got no success.
    – std.denis
    Commented Oct 30, 2015 at 23:49
  • 1
    @std.denis I am not really sure, when I quit MagicPrefs, problem disappeared, but I imagine some apps may have daemons running in the background or something similar. Try quitting those apps and killing every process related to them, see if that helps. Maybe diff list of processes in safe boot and normal boot.
    – Aleksei Zabrodskii
    Commented Oct 31, 2015 at 8:40
  • @elmigranto it's kinda magical – after my comment I've gave up with no luck in fix of this issue, and put macbook into a sleep. In the morning, when I turned it on and tried once again – problem is disappeared =)
    – std.denis
    Commented Oct 31, 2015 at 8:49
3

I had this problem trying to edit the keychain while screen sharing. Even when I had direct access to the server, if the other computer was still screen sharing, it would fail in this way. After stopping the screen sharing and making the changes directly on the server, it worked.

Improve this answer
1
  • Even after we disconnected from Screen Sharing it still didn't work, we had to reboot the box and drive it directly.
    – opearmain
    Commented Dec 1, 2015 at 9:39
0

You will see this same issue if you are using Synergy screen sharing. Re-adding synergyd to the accessibility pane or re-installing will not solve the issue either.

Improve this answer
0

MagicPref causes the issue in my case. The problem disappeared once I uninstall MagicPref.

Improve this answer
1
  • a less drastic option is to simply quit it, do what you must and then relaunch it
    – Riccardo Cossu
    Commented Nov 21, 2015 at 18:36
0

Adding this here just in case. I did not have any kind of mouse-preferences software. But after carefully closing and opening many applications after a reboot, I found the culprit:

I was running Mumble (voip software)

After closing Mumble and reopening Xcode, everything went back to normal.

Edit: Wondering why I got a downvote. Mumble software uses screen overlay and virtual keyboard technologies, which macOS identifies as a potential security threat. Your down vote won't change that.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .