From b1ca3d86a7bb15c42bcb1b414bdb94499c29dd8b Mon Sep 17 00:00:00 2001 From: Michael Wilson Date: Fri, 1 Nov 2024 20:22:46 -0700 Subject: [PATCH 1/3] Add more detail to security section --- index.html | 430 ++++++++++++++++++++++++++++++++++++----------------- 1 file changed, 297 insertions(+), 133 deletions(-) diff --git a/index.html b/index.html index 8013374..9714253 100644 --- a/index.html +++ b/index.html @@ -1381,140 +1381,304 @@

Security Considerations

- Separate from the fingerprinting concerns of identifying the available - ports are concerns around sending and receiving [=MIDI - messages=]. Those issues are explored in more depth below. -

-

- In brief, the general categories of things you can do with MIDI ports - are: -

-
    -
  1. Sending short messages (all messages except SysEx) -
    2. -
  2. Receiving short messages (all messages except SysEx) -
    3. -
  3. Sending SysEx messages. SysEx messages include both commonly - recognized MIDI Time Code and MIDI Sample Dump Standard, as well as - device-specific messages (like “patch control data for a Roland - Jupiter-80 synthesizer”) that do not apply to other devices. -
    4. -
  4. Receiving SysEx messages. -
    5. -
-

- The impact of each of these is: -

-
    -
  1. Sending short messages: sending note-on/note-off/controller - messages would let you cause sounds to be played by attached devices, - including (on Mac and Windows) any default virtual synthesizers. This - by itself does not cause any concerning exposure - you can already - make sounds without interaction, through <audio>, Flash, or Web - Audio. Some attached devices might be professional lighting control - systems, so it’s possible you could control stage lighting; however, - this is extremely rare, and no known system has the ability to cause - lasting damage or information leakage based solely on short messages; - at worst, a malicious page could flash lights, and the user could - close the page and reset their lighting controller. -
    2. -
  2. Receiving short messages: receiving note-on/note-off/controller - messages would not cause any information exposure or security issues, - as there is no identifying data being received, just a stream of - controller messages - all of which must be initiated by the user on - that [=MIDI device=] (except clock-type messages). This is very - analogous to receiving keyboard or mouse events. -
    3. -
  3. Sending and Receiving SysEx. This is the biggest concern, because - it would be possible to write code that looked for system-specific - responses to sysex messages, which could identify the hardware - available, and then use it to download data - e.g. samples stored in a - sampler - or replace that data (erasing sample data or patches in the - device), although both these scenarios would have to be coded for a - particular device. It is also possible that some samplers might enable - a [=System Exclusive=] message to start recording a sample - so if the - sampler happened to have a dedicated microphone attached (uncommon in - practice, but possible), it would be possible to write code specific - to a particular device that could record a short sample of sound and - then upload it to the network without further user intervention. (You - could not stream audio from the device, and most samplers have fairly - limited memory, and MIDI Sample Dump sysex is a slow way to transfer - data - it has to transcode into 7-bit - so it’s unlikely you could - listen in for long periods.) More explicit fingerprinting is a - concern, as the patch information/stored samples/user configuration - could uniquely identify the system (although again, this requires much - device-specific code; there is not standardized “grab all patches and - hash it” capability.) This does suggest that [=System Exclusive=] - messages are in a security category of their own. -
    4. -
-

- It's also useful to examine what scenarios are enabled by MIDI, - mapped against these features: -

-
    -
  1. Receiving short messages. This is the most attractive scenario for - Web MIDI, as it enables getting input from keyboards, drum pads, - guitars, wind controllers, DJ/controllerist controllers, and more, and - use those messages as input to control instruments and features in - the [=Web Audio API=] as well as other control scenarios (MIDI is - the protocol of choice for the multi-billion-dollar music production - industry for getting physical controllers like knobs and buttons - attached to your computer, both in pro/prosumer audio and media - applications as well as consumer applications like Garageband.) -
    2. -
  2. Sending short messages - it’s tempting to say sending is - significantly less interesting, as the scenario of attached output - devices like hardware synthesizers is less common in today's market. - The major exception to this is that many of the MIDI controllers have - external host control of their indicator lights, and this makes them - dramatically more useful. For example, the very popular Novation - Launchpad controller uses MIDI note on/off messages sent to it to - turn on/off and change colors of the buttons. The same is true of - nearly all DJ controllers. -
    3. -
  3. Sending and receiving SysEx - obviously, for more advanced - communication with high-end hardware devices, SysEx is required. - Unfortunately, some common MIDI commands are also sent as [=System - Exclusive=] messages (MIDI Machine Control, for example - generic - start/stop/rew/ffw commands) - and many devices use [=System - Exclusive=] to program patches, send advanced controller messages, - download firmware, etc., which are much-demanded scenarios for Web - MIDI. Some devices use sysex as a direct control protocol, as they can - pack more data into a single “message”, and most devices use SysEx as - way to save and restore patches and configuration information on - less-expensive computer storage. Several of the major music hardware - producers have expressed strong interest in using Web MIDI to provide - web-based configuration and programming interfaces to their hardware. - In short, disabling sysex altogether does not only disable high-end - scenarios. -
    4. -
-

- The additional security concern for receiving short messages is also - small - it’s analogous to listening to keyboard, mouse, mobile/laptop - accelerometer, touch input or gamepad events; there is no additional - information exposed, and all messages other than clock signals must - be initiated by the user. -

-

- The additional concerns about sending short messages are analogous to - any audio output - you cannot overwrite user information or expose - use information, but you can make sounds happen, change patches, or - (in rare configurations) toggle lights - but non-destructively, and - not persistently. -

-

- [=System Exclusive=], on the other hand, has a much less bounded - potential, and it seems that distinguishing requests for SysEx - separately in the API is a good idea, in order to more carefully - provide user security hooks. The suggested security model explicitly - allows user agents to require the user's approval before giving access - to [=MIDI devices=], although it is not currently required to prompt - the user for this approval - but it also detailed that [=System - Exclusive=] support must be requested as part of that request. + The first [=MIDI devices=] were released in 1983, before the + web platform and its security risks existed. Many [=MIDI + devices=] are still in use long after their manufacturers + stopped supporting them. [=MIDI=] has adapted to transports + beyond the original serial connection, such as FireWire, + USB, and Bluetooth. This poses a security challenge, with a + long tail of devices from different eras that do not have + official support but are still actively in use, connected to + computers and the web in ways their designers did not + expect.

+
+

+ Malicious Firmware Updates +

+

+ One concerning theoretical attack involves malicious + firmware updates for USB-[=MIDI devices=]. USB devices in + general can do things based on their device descriptor, + which is sent from the USB device itself. If a USB-[=MIDI + device=]'s firmware can modify what descriptor is sent, it + could make itself act as a human interface device. This + could allow a malicious website to read or inject + keystrokes or other events on the host computer, which + could lead to a total compromise of the system. +

+

+ The attack would proceed as follows: +

+
    +
  1. + A malicious site tricks the user into granting Web MIDI + permission. +
    2. +
  2. + The malicious site enumerates the [=MIDI devices=] + connected to the user's machine, and identifies a + vulnerable device. +
    3. +
  3. + The malicious site sends a pre-crafted set of [=MIDI + messages=] to the vulnerable device, compromising the + device by overwriting its firmware and adding a human + interface device to its USB descriptor. +
    4. +
  4. + The compromised device injects keystrokes to download or + otherwise reproduce a pre-crafted security exploit and + execute it, compromising the system. +
    5. +
+

+ In order to enable to the above attack, a [=MIDI device=] + would need all of the following to be true: +

+ +

+ [=MIDI devices=] that are vulnerable to malicious firmware + updates but do not satisfy the other conditions cannot be + used with this attack to compromise the host system. A + malicious firmware update could still cause these [=MIDI + devices=] to stop working or behave in undesired ways. +

+

+ To mitigate this risk, implementers should emphasize the + following in their implementations: +

+ +

+ Explicitly allowing or blocking lists of known MIDI + devices may also help mitigate this specific attack, but + many small companies and individuals build MIDI devices, + and many MIDI devices are no longer supported, so doing + this would significantly reduce the usability of the Web + MIDI API. +

+
+
+

+ Additional Security Considerations +

+

+ Separate from the fingerprinting concerns of identifying + the available ports are concerns around sending and + receiving [=MIDI messages=]. Those issues are explored in + more depth below. +

+

+ MIDI messages can be divided into [=System Exclusive=] + messages, and short (non-[=System Exclusive=]) messages. + [=System Exclusive=] messages can be further subdivided + into Universal System Exclusive messages such as the + commonly recognized MIDI Time Code and MIDI Sample Dump + Standard, and device-specific messages like “patch control + data for a Roland Jupiter-80 synthesizer” that do not + apply to other devices. +

+

+ Before discussing security concerns, it's useful to + examine what scenarios are enabled by MIDI mapped against + these features: +

+ +

+ The potential security impact of each of these is as + follows: +

+ +
From 1ec82dc4f4194a91a6c176bb8b76908cb658c6c7 Mon Sep 17 00:00:00 2001 From: Michael Wilson Date: Wed, 6 Nov 2024 10:56:27 -0800 Subject: [PATCH 2/3] Remove spaces around slashes --- index.html | 64 +++++++++++++++++++++++++++--------------------------- 1 file changed, 32 insertions(+), 32 deletions(-) diff --git a/index.html b/index.html index 9714253..a09c193 100644 --- a/index.html +++ b/index.html @@ -1553,15 +1553,15 @@

  • Receiving short messages from [=MIDI devices=] - this enables getting input from keyboards, drum pads, - guitars, wind controllers, DJ / controllerist - controllers, and more, and using those messages as input - to control instruments and features in the [=Web Audio - API=] as well as other control scenarios. MIDI is the - protocol of choice for the multi-billion-dollar music - production industry for getting physical controllers - like knobs and buttons attached to your computer, both - in pro / prosumer audio and media applications as well - as consumer applications like Garageband. + guitars, wind controllers, DJ/controllerist controllers, + and more, and using those messages as input to control + instruments and features in the [=Web Audio API=] as + well as other control scenarios. MIDI is the protocol of + choice for the multi-billion-dollar music production + industry for getting physical controllers like knobs and + buttons attached to your computer, both in pro/prosumer + audio and media applications as well as consumer + applications like Garageband.
  • Sending short messages to [=MIDI devices=] - it’s @@ -1582,21 +1582,21 @@

    devices, [=System Exclusive=] messages are required. Some common MIDI commands are also sent as Universal [=System Exclusive=] messages, such as MIDI - Machine Control - generic start / stop / rewind / - fast-forward commands. Many devices use device-specific - [=System Exclusive=] messages to program patches, send - advanced controller messages, download firmware, etc., - which are much-demanded scenarios for Web MIDI. Some - devices use [=System Exclusive=] as a direct control - protocol, as they can pack more data into a single - “message”, and most devices use [=System Exclusive=] as - a way to save and restore patches and configuration - information on less-expensive computer storage. Several - of the major music hardware producers have expressed - strong interest in using Web MIDI to provide web-based - configuration and programming interfaces to their - hardware. In short, disabling [=System Exclusive=] - altogether does not only disable high-end scenarios. + Machine Control - generic start/stop/rewind/fast-forward + commands. Many devices use device-specific [=System + Exclusive=] messages to program patches, send advanced + controller messages, download firmware, etc., which are + much-demanded scenarios for Web MIDI. Some devices use + [=System Exclusive=] as a direct control protocol, as + they can pack more data into a single “message”, and + most devices use [=System Exclusive=] as a way to save + and restore patches and configuration information on + less-expensive computer storage. Several of the major + music hardware producers have expressed strong interest + in using Web MIDI to provide web-based configuration and + programming interfaces to their hardware. In short, + disabling [=System Exclusive=] altogether does not only + disable high-end scenarios.

    • @@ -1606,11 +1606,11 @@

    • Sending short messages to a [=MIDI device=] - sending - note-on / note-off / controller messages could cause - sounds to be played by attached devices, including (on - Mac and Windows) any default virtual synthesizers. This - by itself does not cause any concerning exposure - you - can already make sounds without interaction, through + note-on/note-off/controller messages could cause sounds + to be played by attached devices, including (on Mac and + Windows) any default virtual synthesizers. This by + itself does not cause any concerning exposure - you can + already make sounds without interaction, through <audio> or Web Audio. Some attached devices might be professional lighting control systems, so it’s possible to control stage lighting; however, this is @@ -1627,13 +1627,13 @@

    • Receiving short messages from a [=MIDI device=] - - receiving note-on / note-off / controller messages would + receiving note-on/note-off/controller messages would not cause information exposure or security issues, as there is no identifying data being received, just a stream of controller messages - all of which must be initiated by the user on that MIDI device (except clock-type messages). This is analogous to listening to - keyboard, mouse, mobile / laptop accelerometer, touch + keyboard, mouse, mobile/laptop accelerometer, touch input or gamepad events; there is no additional information exposed, and all messages other than clock signals must be initiated by the user. @@ -1660,7 +1660,7 @@

      to transfer data - it has to transcode into 7-bit - so it’s unlikely you could listen in for long periods. More explicit fingerprinting is a concern, as the patch - information / stored samples / user configuration could + information/stored samples/user configuration could uniquely identify the system. Again, this requires much device-specific code; there is not standardized “grab all patches and hash it” capability. This suggests that From f6b931b93be67cf4b5153a41713874fcf4b220f0 Mon Sep 17 00:00:00 2001 From: Michael Wilson Date: Fri, 15 Nov 2024 18:01:10 -0800 Subject: [PATCH 3/3] Address reviewer comments --- index.html | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/index.html b/index.html index 1a3a22d..32e4407 100644 --- a/index.html +++ b/index.html @@ -1451,13 +1451,15 @@

      messages=]. Many [=MIDI devices=] use [=System Exclusive=] messages to perform firmware updates. This is a common use of [=System Exclusive=] - messages. A small number of devices use - non-[=System Exclusive=] messages to perform - firmware updates. Others may use out-of-band USB - communication or require the user to connect a - storage device directly to the [=MIDI device=] to - perform firmware updates, which cannot be done using - the Web MIDI API, and are not vulnerable. + messages. It is technically possible to make a + device that uses non-[=System Exclusive=] messages + to perform firmware updates, but this is not an + intended use of non-[=System Exclusive=] messages. + Other devices may use out-of-band USB communication + or require the user to connect a storage device + directly to the [=MIDI device=] to perform firmware + updates, which cannot be done using the Web MIDI + API, and are not vulnerable.

    • Allow firmware updates without explicit user @@ -1546,8 +1548,8 @@

      Before discussing security concerns, it's useful to - examine what scenarios are enabled by MIDI mapped against - these features: + examine what scenarios are enabled by MIDI using these + features: