Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG]: PCSX2 tries to access the Berkeley Packet Filter (bpf) on macOS #11090

Open
checktext00 opened this issue Apr 16, 2024 · 7 comments
Open

Comments

@checktext00
Copy link

Describe the Bug

After installing PCSX2 on macOS, I got this scary warning in Little Snitch with the Endpoint Security System Extension installed

PCSX2_bpf_issue

According to Little Snitch firewall documentation about the Berkeley Packet Filter:

BPF allows injection of data packets at the network interface. This means that a (privileged) app which opens a BPF device can send any data packet to any destination. The packet is injected directly at the network interface layer, circumventing all firewalls.

I even have the PCSX2 automatic update check option disabled, and this throws up a scary warning in Little Snitch

(this only seems to happen after opening the PCSX2 settings menu window the first time after launching the app - also PCSX2 won't actually let me access the settings menu until after I accept or reject the Little Snitch popup)

after running sudo opensnoop -n PCSX2 I saw that PCSX2 tried to access both /dev/bpf and /dev/bpf0

using
macOS Big Sur 11.7.10
PCSX2-v1.7.5708.app

I'm getting the warning without a pcap adapter enabled (I don't really know what a PCAP adapter would be), but just for maximum troubleshooting I will say that:

  1. I have Tunnelblick installed for accessing a VPN (all default option using the default utun device which is part of macOS - see info here) - but for testing I disconnected all VPNs and quit Tunnelblick and still got the bpf access issue with PCSX2
  2. I am using specifically the Endpoint Security System Extension of Little Snitch which is an extra option that needs to be enabled and installed (see info here)

In order to control access to file system objects (/dev/bpf), Little Snitch needs to register an Endpoint Security System Extension. This is an additional install. Choose Little Snitch > Preferences > Advanced > Install Endpoint Security

  1. Little Snitch does have a command line option to capture traffic in a pcap format but I have not enabled that (see info here)

Thanks for looking into this

Reproduction Steps

Launch PCSX2 and access the PCSX2 preferences/options menu

Expected Behavior

PCSX2 should not attempt to access /dev/bpf or /dev/bpf0

PCSX2 Revision

1.7.5708

Operating System

macOS 11 (Big Sur)

If Linux - Specify Distro

No response

Logs & Dumps

No response

@TheLastRar
Copy link
Contributor

Launch PCSX2 and access the PCSX2 preferences/options menu

My initial suspicion is that we trigger this when getting the list of adapters for the Network and HDD settings panel

We ask each network backend what adapters it supports here

for (const AdapterEntry& adapter : PCAPAdapter::GetAdapters())
AddAdapter(adapter);
#ifdef _WIN32
for (const AdapterEntry& adapter : TAPAdapter::GetAdapters())
AddAdapter(adapter);
#endif
for (const AdapterEntry& adapter : SocketAdapter::GetAdapters())
AddAdapter(adapter);

Which then calls pcap_findalldevs() here

if (pcap_findalldevs(&alldevs, errbuf) == -1)

I guess this function tries to access /dev/bpf and /dev/bpf0, and trips the Endpoint Security System Extension you are using.

I'm, however, not a MAC dev, so I'm not able to verify if my suspicion is correct, nor determine the best approach to resolve this.

@stenzek
Copy link
Member

stenzek commented Apr 16, 2024

I guess we could lazily populate the adapter list if ethernet isn't enabled.
Probably not the worst idea anyway.

I'd also say this isn't really a bug though, and such a change would be purely from a performance perspective. MacOS doesn't restrict access to this resource itself.

@TheLastRar
Copy link
Contributor

Can you give #11093 a shot
You will probably still get the Berkeley Packet Filter popup when you go to the Network and HDD settings panel, but the other settings panels won't trigger it

@checktext00
Copy link
Author

thanks guys

I'd also say this isn't really a bug though, and such a change would be purely from a performance perspective. MacOS doesn't restrict access to this resource itself.

I was looking at it more as a potential security issue (I've never seen another app try to access the bpf)

@stenzek
Copy link
Member

stenzek commented Apr 17, 2024

You will probably still get the Berkeley Packet Filter popup when you go to the Network and HDD settings panel, but the other settings panels won't trigger it

Is the dropdown disabled when ethernet is disabled? You could defer it until then (which is what I was thinking anyway).

I was looking at it more as a potential security issue (I've never seen another app try to access the bpf)

If it was, then I'd think that MacOS would require an entitlement. List of adapters is hardly sensitive/private information.

@TheLastRar
Copy link
Contributor

TheLastRar commented Apr 17, 2024

Is the dropdown disabled when ethernet is disabled? You could defer it until then (which is what I was thinking anyway).

Done

I was looking at it more as a potential security issue (I've never seen another app try to access the bpf)

If it was, then I'd think that MacOS would require an entitlement. List of adapters is hardly sensitive/private information.

Had a look though the libpcap source
pcap_findalldevs will check if the adapter can be used for capture by briefly opening it
See pcap-bpf.c, which sets the check_usable parameter of pcapint_findalldevs_interfaces to check_bpf_bindable().
check_bpf_bindable calls bpf_open_and_bind which (via bpf_open) opens /dev/bpf*.

I guess that's what we get when we ask a packet capture library what adapters we can use it with

I was looking at it more as a potential security issue (I've never seen another app try to access the bpf)

It's worth noting that (I believe) /dev/bpf* is by default only accessible when running sudo
You would need to chmod the file to allow non elevated processes to access it. PCSX2 won't do this, but other packages, such as wireshark, can

@TellowKrinkle
Copy link
Member

It's worth noting that (I believe) /dev/bpf* is by default only accessible when running sudo

Correct. On a normal install, applications cannot use bpf devices without root.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants