Only an admin user (so definitely not Guest) can add themselves to the access_bpf group.
BTW, the talk at USENIX is happening now.
But what if an admin user installs Wireshark? Will that still add "Guest" to access_bpf?
As an author of the attack presented at DefCon, let me make it clear.
First, the attack was performed on Safari on macOS, where WebSocket is used instead of native messaging.
Second, the attack could be done by any unprivileged user, including guest account. No admin/root access is needed.
Third, we don't use WireShark.
For what follows there are a couple of facts that will be useful to remind everyone of.
I probably should have edited irrelevant sections of the thing I quoted. The wireshark issue was only about reading bidirectional traffic between client and server. We took the opportunity when creating this ad-hoc protocol to obfuscate that traffic. Although we dislike obfuscation, there is a history of people getting very worried when they discover that an admin user can read that traffic. So as long was we were adding in a new protocol, we added that in as well. It is not relevant to either client or server impersonation.
The reason why we added the this "broken ad-hoc crypto protocol" (you are not wrong to call it that) was to defend against client impersonation on Windows. As you noted, on Mac the server checks the owner of the process behind the client. The analog of that check on windows was didn't work, as was pointed out to us by Tavis Ormandy in August 2016. This protocol didn't do anything on Mac other than to obfuscate the traffic to and from localhost.
You can read what we announced about it at the time. This was a defense against client impersonation.
Although we didn't set out to solve server impersonation, we again used the opportunity to make a dent in that problem. At the time that we rolled this out, non-first-use authentications would fail if the server couldn't prove its identity to the client. We still had the eavesdropable key exchange, but we forced the user to go through the verification dance.
But that turned out to be a usability nightmare. No one understand what it was. It would fail as an indication to the user of a potentially malicious server. So once we were able to move to things like native messaging with some browsers (particularly on Windows) we just dropped the user intervention everywhere. We left the protocol in place for the obfuscation gain.
So we left it in place, but without the user intervention. Thus it no longer served any purpose beyond the traffic obfuscation by the time you investigated it. After moving authenticating the named pipes on Windows (though we can improve that), the original problem went away. This is why I said it was moot. That whole protocol, while it once had a real job to do, only remains for the traffic obfuscation.
What is most interesting for me in @tienthanh411's work is the suggestion of user assisted key exchange. It is one of those things that is "obvious" once someone points it out. We already were (in the originally deployed version) prompting user interaction. Having the user manually enter a client generated key into the server would have made the key exchange work.
This still would have left server impersonation possible, but again our goal was to plug a gap on Windows that allowed for client impersonation. But this would have solved the key exchange issue.
But the question now, once we can kill off the web socket entirely, is whether we keep this obfuscation layer at all. It is probably better to just drop it (so that it isn't "news" when someone breaks the obfuscation) and this would allow for a simpler protocol.
I'd like to know WHY 1Password has added a access_bpf user inside the Users & Groups section of MacOS 10.13.6. As a SysAdmin I know that this was NOT in there before the latest update. Is this a needed User?
"access_bpf" is typically associated with Wireshark and perhaps other packet capture / network monitoring tools. I don't see any such user on any systems I don't have Wireshark installed on.
Just to be clear, 1Password is installing Wireshark? I just found an access_bpf group in Users & Groups which listed me, a second login account I use for troubleshooting, and Guest.
Hi @chiponline! Welcome to the forum!
1Password does not install Wireshark. Do you have Wireshark or any other network monitoring tools already installed on your machine, as Ben suggested in his latest comment?
I just checked my Users & Groups menu and I don't see an access_bpf group here, even though I am running 1Password.
Thanks for your response. It's a bit of a mystery. After upgrading to High Sierra the only app I installed was Office 365. I went to Users and Groups to re-enable Guest (for tracking) and try to figure out why root user wasn't showing up and found access_bpf group. I use BLOCK BLOCK and F-Secure XFENCE so my installs/permissions are pretty tightly regulated. Wireshark does not show up in any searches of my hard drive. Should I just delete it and not worry about it?
I really couldn't say. It wouldn't have anything to do with 1Password. Deleting the group wouldn't have any impact on 1Password but I wouldn't be in a position to comment on anything beyond that.
FWIW, there's a known issue(?) with Wireshark where if you install it and then uninstall it afterward, the access_bpf group is not automatically removed. I can't say whether it's relevant in @chiponline's case, but I thought I'd mention it...
Ah, that's good to know. Thank you for mentioning it!