To make a FTDI breakout work on Ubuntu:
Open the file /etc/group with root permissions:
sudo nano /etc/group
After that, search for tty:x5:
and dialout:x20:
Add your user to this groups typing your username in front of each line:
tty:x5:<user>
dialout:x20:<user>
You can also use the next two commands to avoid search for the file:
sudo usermod -aG tty <user>
sudo usermod -aG dialout <user>
Where <user>
, is your user name.
Finally, reboot your computer.
If you want to use udev rules, connect the FTDI Module, then run:
lsusb
This will show the vendorID and the productID. For example:
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Where 8087 is the vendorID, and 0024 the productID.
Then, create a rule like this:
ATTRS{idVendor}="8087", ATTRS{idProduct}="0024", MODE="0660", GROUP="dialout"
From dmesg
output, it is clear that the phone connected twice.
- [ 40.632283] 1st connected as USB bus 2 dev 3
- [ 40.864690] disconnected
- [ 41.613079] 2nd connected as USB bus 2 dev 4
The problem is:
Both phone connection modes are using same attributes idVendor
/idProduct
/bcdDevice
.
libmtp udev rules use only idVendor
/idProduct
to filter devices in addition to non-important/common attributes ACTION!="add"
, ENV{MAJOR}!="?*"
and SUBSYSTEM=="usb"
libmtp udev rules use ATTR
(not ATTRS
), it does target exactly this device node /devices/pci0000:00/0000:00:13.2/usb2/2-1
. So we can't use interfaces nodes details as they are children nodes to this one.
To get what going on, use udevadm monitor
. To see just events without details.
- Unplug the phone
- Open terminal and run
udevadm monitor -u
, -u
to show UDEV events only (for clean output)
- Plug the phone and wait till things settle down
- Ctrl+C to stop monitoring
To get details (Environment properties) use udevadm monitor -u -p
instead and compare output at that node:
UDEV [107.024195] add /devices/pci0000:00/0000:00:13.2/usb2/2-1 (usb)
UDEV [107.998137] add /devices/pci0000:00/0000:00:13.2/usb2/2-1 (usb)
Notice the difference in ID_USB_INTERFACES
Another cleaner way, using a udev rule to collect only what we need:
Add a rule to /lib/udev/rules.d/69-libmtp.rules
just after LABEL="libmtp_usb_rules"
:
ATTR{idVendor}=="0bb4", ATTR{idProduct}=="0f91", RUN+="/bin/sh -c 'env >> /home/username/udev-phone-mtp_%E{SEQNUM}.log'"
Reload rules
sudo udevadm control -R
Replug the phone once.
This rule should be triggered twice. Comparing output at that node:
diff udev-phone-mtp_*.log
should bring: (this is just the interesting portion)
< ID_USB_INTERFACES=:060101:080650:
---
> ID_USB_INTERFACES=:060101:ffff00:
Exactly what Pilot6 (OP) could catch it using usb-devices
before it reconnected.
I suggest adding this rule to /lib/udev/rules.d/69-libmtp.rules
, just after LABEL="libmtp_usb_rules"
:
ATTR{idVendor}=="0bb4", ATTR{idProduct}=="0f91", ENV{ID_USB_INTERFACES}==":060101:080650:", GOTO="libmtp_rules_end"
Best Answer
A key to writing the proper rules is understanding that udev rules are applied in a certain order. The default, package-supplied rules are in
/lib/udev/rules.d/
. Leave those files alone. Local rules should be placed in/etc/udev/rules.d/
which takes precedence over/lib/udev/rules.d
.Your file (if you choose to create a new one) must end in
.rules
and it can be named as you like, however the numbered files will be processed first. If you want to override a numbered rules file, choose a higher number for your file name, or choose a file name without a number, it will run after all the numbered rules files. So the idea is: make your total blacklist rule run first and then the whilelist rules afterwards to allow the specific devices you want to allow.It has already been pointed out however, that this attack requires physical access and such vulnerabilities are usually fixed quickly. However, what's even more interesting is the fact that if you were using Ubuntu 9.10 and above, you were never really vulnerable to this attack anyway. Since 9.10 evince's AppArmor profile would have contained the rogue process and limited it to pwning your thumbnails. See: USN-1035-1: Evince vulnerabilities