[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#877024: marked as done (modemmanager should ask before messing with serial ports)

Your message dated Wed, 21 Mar 2018 22:25:09 +0100
with message-id <87370tt93e.fsf@hands.com>
and subject line Re: Bug#877024: modemmanager should ask before messing with serial ports
has caused the Debian Bug report #877024,
regarding modemmanager should ask before messing with serial ports
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org

877024: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877024
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
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
   With a less resourceful user, that might make the computer
   completely unuseable.

 * Random number generator "interfered with"
   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
   (Not as trivial a problem as it sounds, as it could prevent the
   system being used as a navigation aid.)

 * "Breaks" apcupsd

 * User's Palm Pilot PDA crashes

 * User's 1-wire DS9097 interface is messed up, requiring a
   reboot to become functional again

 * My 3D printer reported protocol violations on startup
   and host software could sometimes not connect to printer

Other possible consequences which have been hypothesised are:

 * Simply opening the port and enabling RTS might enable radio
   transmissions in a ham radio context
   (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)

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

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

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 Jackson <ijackson@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.

--- End Message ---
--- Begin Message ---

You'll be pleased to note that the original bug in this case has now
been closed as a result of a newly uploaded package version:


Thanks to all involved for bringing this to a successful resolution,
at which point the TC bug becomes moot, so I'm closing it now.

Cheers, Phil
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

Attachment: signature.asc
Description: PGP signature

--- End Message ---

Reply to: