Package: tech-ctte
Control: block 683839 by -1
modemmanager is a program for handling modems, particularly
usb-connected mobile-telephony modems (aka "3G/4G sticks" etc.)
Many such modems present as USB serial devices, eg ttyACM or ttyUSB.
Consequently, modemmanager has the ability to open serial ports and
probe them to see if they respond to Hayes-style AT commands. That
functionality is currently triggered automatically by default, even
for USB serial ports whose USB device IDs are unknown to modemmanager,
or whose device IDs correspond to generic USB-to-serial adapters.
I.e., if one is running a normal Debian installation and plugs in a
usb-to-serial converter, modemmanager will open the device and send AT
commands to it, to see if it is a modem.
This behaviour is IMO unaccaptable, as a default.
Serial connections are used to connect a wide variety of equipment
including industrial robots, electronic test equipment capable of
generating hazardous voltages, accessibility hardware, scientific
instruments, and embedded computers.
In the worst case (luckily, as far as I know, hypothetical):
* This behaviour could cause someone personal injury, if a real-world
device connected to the serial port misinteprets modemmanager's
probe (or if its control firmware crashes) and makes hazardous
movements or some such
Symptoms which have been observed include:
* User's braille display stopped working during system boot
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621851
With a less resourceful user, that might make the computer
completely unuseable.
* Random number generator "interfered with"
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840697
Ultimate consequences not clear from the bug report, but if the RNG
driver software has poor error handling it might include poor
quality random numbers and therefore weak cryptographic keys.
* GPS no longer recognised at boot
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798193
(Not as trivial a problem as it sounds, as it could prevent the
system being used as a navigation aid.)
* "Breaks" apcupsd
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839#32
* User's Palm Pilot PDA crashes
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839#52
* User's 1-wire DS9097 interface is messed up, requiring a
reboot to become functional again
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839#72
* My 3D printer reported protocol violations on startup
and host software could sometimes not connect to printer
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839#5
Other possible consequences which have been hypothesised are:
* Simply opening the port and enabling RTS might enable radio
transmissions in a ham radio context
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839#42
(Resulting in possibly-illegal radio interference.)
* Simply opening the port and enabling RTS switches some scientific
equipment into remote control mode, disabling the front panel
and perhaps leading to hazardous situations. (pers. comm)
* Some 3D printers will reset when RTS is toggled, interrupting
any print job (causing real world lossage in the form of wasted
feedstock and printer time)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839#32
In August 2012 I experienced this bug and filed #683839 with severity
`important'. The maintainers apparently do not agree with my analysis
and there has been no action by them since then other than efforts to
maintain the blocklist.
In the intervening time many users have reported manifestations of
this problem to #683839 and to other bug reports. The reactions from
the maintainers have consistently been to try to get individual
devices blocklisted, even though as has been explained repeatedly,
this is not really sufficient. The maintainers have not engaged with
the arguments against blanket probing.
Note that safe behaviour does not necessarily mean that every time the
user plugs in their modem, they have to confirm its use. Other
solutions are possible, for example asking for explicit permission
from the user, the first time any particular device is seen, that it
is OK to probe that device. (Similar behaviour is already implemented
for USB HID devices - keyboards etc. - because of the security
implications.)
I'm afraid don't really want to do the work of writing a better UI.
But I have provided a simple patch which at least makes the behaviour
safe.
IMO at the very least, for buster, we should apply that patch - or an
equivalent - and then the maintainers can consider how to improve the
UI/UX to explicitly ask permission, if they think that is desirable.
We should also consider whether to backport any of the resulting
changes, or include them in stable updates of some kind.
Thanks for your attention.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
