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.