PSA: Bluetooth vulnerability and PS3 Controllers on Linux in 2024
In late 2023 a Bluetooth vulnerability CVE-2023-45866 was discovered and patched in Bluez. By now, this vulnerability should be fixed on all Linux distributions. The fix has one compatibility implication: support for insecure legacy devices is now disabled by default. The Sony PlayStation 3 Controller (AKA DualShock 3 or DS3) is probably the most notable device affected by this change.
What to do if you have a PS3 Controller
The PS3 Controller should still be plug-and-play on Linux when used wired, this change only affects wireless use.
Wireless use is now disabled by default. It should still be possible to use the controller wirelessly with a configuration change, but that will make your PC vulnerable when Bluetooth is in discoverable mode — that’s when you’re pairing a device; in GNOME that’s when you just have the Bluetooth settings open; easy to have on by accident.
It’s painful for me to say this (I own several PS3 Controllers), but the DS3 is reaching its end-of-life, and we should start to consider moving on from it as a gamepad for PC.
How to re-enable Bluetooth support for the PS3 Controller
This is insecure: It will make your PC an easy target for remote code execution attacks from anyone in close proximity whenever your Bluetooth is in pairing/discoverable mode. It’s usually hard to notice when Bluetooth is in discoverable mode, and it’s very easy to accidentally leave it on. You have been warned.
TL;DR: The following commands should do it, tested on Fedora 39:
sudo sed -Ei~ -e 's/^#ClassicBondedOnly=.*/ClassicBondedOnly=false/' /etc/bluetooth/input.conf
sudo systemctl restart bluetooth
Long version: Use the configuration file at /etc/bluetooth/input.conf, under the [] section, add the option ClassicBondedOnly=false, then restart the bluetooth service or reboot the computer. Your config file should look like the following:
# Configuration file for the input service
# This section contains options which are not specific to any
# particular interface
[General]
# Set idle timeout (in minutes) before the connection will
# be disconnect (defaults to 0 for no timeout)
#IdleTimeout=30
# Enable HID protocol handling in userspace input profile
# Defaults to false (HIDP handled in HIDP kernel module)
#UserspaceHID=true
# Limit HID connections to bonded devices
# The HID Profile does not specify that devices must be bonded, however some
# platforms may want to make sure that input connections only come from bonded
# device connections. Several older mice have been known for not supporting
# pairing/encryption.
# Defaults to true for security.
ClassicBondedOnly=false
# LE upgrade security
# Enables upgrades of security automatically if required.
# Defaults to true to maximize device compatibility.
#LEAutoSecurity=true
I’m posting this PSA on !linux@lemmy.ml and !linux_gaming@lemmy.world. Please forward this message to other interested Linux communities.
So just to clarify, there’s no way to support the DualShock 3 without introducing a security hole? Or is the security hole only a problem with the current driver which could eventually be fixed, rather than something inherent to the device? Also, is there a list of affected devices outside the DualShock 3? Will the Wiimote still work, for instance?
The DualShock is old, but I’ve always appreciated how I could have all of my gamepads just work on Linux, from the Wiimote to the DualSense. On Windows, most of them needed third party unofficial drivers to be installed and/or would be missing functionality, like motion controls or Bluetooth support. Would be a big shame if it just stopped working wirelessly. Still, I have a lot of significantly better gamepads by now, including a DualSense, so DualShock 3 support isn’t something I really need anymore unless I have a lot of people over and need to connect a lot of controllers.
The controller itself is insecure, it doesn’t exactly conform to Bluetooth standard. There’s no indication Sony ever planned cross-compatibility, the DualShock 3 was made to be used only on the PS3 console, where the lack of authorization supposedly wouldn’t be a problem.
Of course, you can still use it on a system where you can accept the risk, as well as on the PS3, or wired. The controllers are not e-waste yet.
What is the risk and how can it be exploited?
deleted by creator
Can you whitelist your controller Mac address and close the vulnerability?
Also maybe filter input events to only what the ds3 should be sending?
deleted by creator
Good to know. Maybe there’s a need for this type of device pairing and filtering in general, like over USB, PCI, and I2C as well. We already carry around device rules for driver assignments, it wouldn’t be too far of a stretch to define expected behavior for device IDs and provide a mode to filter behavior, like SELinux for devices 🙃🤮
udev does a little protection to some extent (locking user sessions out of device access based on rules), and so does Thunderbolt/USB4 because of its DMA properties, but if you want full protection, you’ll need something like Qubes.
Of course, you could always compile your own kernel with just the drivers you need and nothing more.
Definitely for you to decide, but if you’re on a desktop in a single family home you’re probably fine. A laptop that you bring around with you I would highly advise against. I would probably also evaluate what other functions the computer serves. Just gaming or also do you do your job on that machine. What else does that machine have access to?
This explains it! I thought it didn’t connect any more due to my system being weird, but it’s sad to see that isn’t the case 😢
I loved the plug and play on Linux. Guess I’ll use it wired from now on, disappointing…
Honestly wired seems to be more reliable long term.
Thanks a ton for sharing this! I thought it was a bug that would’ve been fixed, so I was going to be waiting for awhile.
There wasn’t an input.conf file in Manjaro, so we had to add it and the appropriate line.
Cross comment to cross post: It seems that you are vulnerable during pairing which is for like a minute. What am I missing?
deleted by creator
Do you have recommendations for a new controller? I’ve been looking at 8bitdos: https://www.8bitdo.com/ultimate-2.4g-wireless-controller/
I think its best to move past bluetooth, if we can. I dont think it was ever a great protocol. But things like phones can’t always have dongles either, so it’s necessary.
I am very happy with the 8bitdo Pro 2 and the Gulikit King Kong 2 The dpad is a similar diameter but feels more rigid.
For the 8bitdo: The 4 buttons are spaced a bit further, and the buttons have a more prominent corner on them. All of the buttons have a satisfying action and travel. I like that the battery is easily removed.
Only wishlist item would be for hall joysticks.
The Gulikit King Kong 2:
Feels like a very high quality Xbox styled controller. I am wary of the shoulder buttons of Xbox styled controllers but these do feel like a different type of switch internally so maybe it’ll last longer.
Both Bluetooth and BLE are perfectly fine protocols. You won’t be able to design much for short distance with that much power savings otherwise. The main issue is that for any protocols like this you would most likely need to put it in the 2.4ghz unlicensed band. And that’s predominantly used by wifi these days.
@rutrum @jntesteves I have that controller. It’s the best controller I’ve used — I greatly prefer it to my Series X controller.
The back paddle buttons don’t work for me with SteamInput in XInput mode though. Reading around, I think that’s independent of Linux and a limitation of the firmware on them though.
I have the version of this controller with the Nintendo button layout. I like it, but steam refuses to see it as anything other than a standard x box controller. I’m sure I could solve that, but I’m lazy and it works well enough as it is.
The bug report also listed mitigation steps including turning off discovery, so it seems to me that if you enable the insecure method, you can just leave discovery off by default, and manually turn it on briefly to pair a new device, then tirn discovery back off.
Does discovery mode not have a timer? Feels like that should be the default mode… turn it on, you have x amount of time to find and pair before it turns back off.
Honestly wired is more reliable long term
