RFP: WebMIDI

[qdot]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: WebMIDI
• Specification or proposal URL: https://webaudio.github.io/web-midi-api/
• Caniuse.com URL (optional): https://caniuse.com/#feat=midi
• Bugzilla URL (optional): https://bugzilla.mozilla.org/show_bug.cgi?id=webmidi

Other information

WebMIDI has been in development in Firefox since 2015. The DOM API (https://bugzilla.mozilla.org/show_bug.cgi?id=1201590) recently landed, but is pref'd off on all branches, runs only in tests, and was mostly landed to curb bit-rot. Platform implementation bugs exist at:

• Mac: https://bugzilla.mozilla.org/show_bug.cgi?id=1201593
• Windows: https://bugzilla.mozilla.org/show_bug.cgi?id=1201596
• Linux: https://bugzilla.mozilla.org/show_bug.cgi?id=1201598

The major blocker right now is security issues related to device firmware hijacking. There's a public google doc available listing issues and ideas for mitigation at

https://docs.google.com/document/d/1SjYRmNvQKxOPHufWbx6n0NOeTKKd_O1WIiTBZAjVj5E/edit#heading=h.lavkfo6fb57g

[martinthomson]

Thanks for the extra context, that made reviewing this easy.

The big concern here is SysEx messages. Those have the same concerns as WebUSB. From the text in the specification, these appear to grant unrestricted access to the device. Simply asking for permission isn't a good answer to this class of problem: we can't expect someone to understand the full implications of this if the potential extent of capabilities they are extending to the origin includes rewriting firmware.

The mitigations doc says:

No firmware overwrite reports related to the Chrome implementation of WebMIDI have been mentioned in public so far.

That's not relevant. The same applies to the language assessing likelihood or difficulty of attack. What is relevant is that the possibility exists. And that includes rewriting the MIDI device to be a (remote controlled) keyboard, which has implications for not just browser security, but system security.

It would be irresponsible of us to ship this without addressing this concern. As I see it, the safe options are: disable SysEx, whitelist devices for SysEx, and don't ship. I don't see a huge amount of harm in shipping without SysEx or with a whitelist.

I'll let others speak to the benefits of the API. I don't do MIDI or know anyone who does, so don't have any investment.

[marcoscaceres]

I'm also not a MIDI person, so don't really know the implications of not including SysEx. The doc says the consequences are "severe" with respect to limiting functionality.

@qdot, should we ask some MIDI folks for opinions (e.g., Chris Wilson)?

I'll let others speak to the benefits of the API. I don't do MIDI or know anyone who does, so don't have any investment.

5 years ago, I spent a lot of time helping with editing, implementing a polyfill, and testing this specification. I've personally seen some pretty amazing things done with it at conferences and events I've attended: like, whole parties DJ'ed realtime using the API, and really impressive controller software written specifically for the API.

While I was looking into Web MIDI, I also investigated the iOS MIDI ecosystem... it's pretty vibrant (see example native apps). I mention iOS here because I believe we have an opportunity to tap into that community through the Web.

From the perspective that this allows the creation of really amazing musical experiences (and it makes the web a creative outlet for talented musicians) - I'd strongly support shipping this API. It would make a lot of people happy - and make more events pretty awesome 🎹💃🕺.

[marcoscaceres]

Loop Drop was the software I saw being used by @mmckegg at an event. Matt is a good person to talk to from a developer perspective, as he probably knows Web MIDI as well as anyone.

[stpeter]

I agree with @marcoscaceres on the possibilities here. I'm pretty sure @obensource & friends have used the Web MIDI API in the https://github.com/websound project - I'll check with Ben for details.

[stpeter]

@qdot With respect to whitelisting, is this something that we could co-own with Google or crowdsource with the MIDI community (including device vendors)?

[mmckegg]

Thanks for letting me know about this issue @marcoscaceres.

Some random thoughts about SysEx and Web Audio off the top of my head:

I think that (security issues aside), rewriting the firmware of a midi device is probably one of the coolest potential use cases for Web MIDI. Also a lot of devices use sysex to backup and restore presets (yet another potentially great web midi use case).

• Here is an example of a web page for updating the firmware of the RK-002 smart midi cable.
• Here's another page for updating the settings for the CV.OCD Midi -> CV converter. This doesn't use Web Midi, but instead allows you to download the sysex file for manual use - but this would be a great potential use case!

Besides system level stuff, SysEx can be vital for certain midi controllers to access advanced functionality. I use it personally in Loop Drop with the Launchpad MK2 for setting the colors of the RGB lights. Another case is for updating the LCD screen on the Ableton Push (original).

I'm not sure how standard this is, but I have noticed that it is quite common for devices to only accept firmware updates when they are booted in a special mode. Most likely exactly to avoid the case where some random software pushes malicious firmware updates to a device. Unfortunately this is not the case with all midi controllers.

So I think in combination with a security prompt "Would you like to allow full access to this midi device (SysEx)", this should be good enough. Maybe a warning in the message that this might allow the web page to update the firmware of the connected device?

---

We need to find a way to support sysex safely in Web Midi, otherwise we'll be missing out on a tonne of possibilities.

Still, I'd much prefer Web Midi API without SysEx than no Web Midi API at all!

[qdot]

@marcoscaceres I've already pinged Chris Wilson, Paul Adenot, and a couple of vendors who've implemented applications using WebMIDI that are currently running on Chrome. I hope that we'll hear from them over the next few days.

@stpeter Possibly! I'll let Chris Wilson speak to that, though I may try to loop in other Chrome engineers working on WebMIDI also.

[qdot]

@mmckegg In that gdocs file in the top comment, I listed firmware reflash instructions from a few devices from different manufacturers. From the instructions, it looks like some require user gesture to reflash, while others it appears can be reflashed by just having them connected. It's that second set that are the worrisome ones, unfortunately.

I should say that these firmware attack issues really only apply to USB MIDI devices too. If a device uses actual 5-pin MIDI, that'll be going through an adapter that most likely cannot be reflashed, so the potential there is less security and more annoyance.

[mmckegg]

Ah, thanks @qdot. That document is a good analysis!

The only addition I have would be to the Blacklist approach. Rather than blacklisting SysEx entirely on an device, could blacklist certain SysEx prefixes.

For example, the Launchpad MK2 is one of the devices that can be updated without being put into a special mode. Instead this mode is achieved by sending a particular sysex message (F0h 00h 20h 29h 00h 71h 00h 69h F7h). See Launchpad MK2 Programmers Reference Guide under "Other SysEx Messages" (page 16).

If the SysEx message itself was blacklisted for that device, there would no longer be a risk of the firmware being updated, and we can still have access to updating the LED colors, and scrolling text etc.

[dvhdr]

Thanks @qdot & co for the hard work and commentary! I just wanted to raise that sysex firmware upgrades are the reason we built our Components app. It's the single most important use case for our customers - getting new content onto their hardware with a minimum of fuss. Yes, this means firmware upgrades without gestural input, as @mmckegg describes above.

In fact, writing new third-party firmware to our devices is something we encourage (e.g. with open firmware development tools like https://github.com/dvhdr/launchpad-pro).

I'm no security expert and don't wish to downplay the concerns raised. I'd happily support any initiative that gets sysex-capable WebMIDI out into the wider world, even if that does compromise the user experience. But please - it's got to have sysex!

[ekr]

A few notes: It's useful to have people explain why they want this, but ultimately our obligation is to the security of our users, so no matter how useful it is, if we can't make it secure we can't do it.

"So I think in combination with a security prompt "Would you like to allow full access to this midi device (SysEx)", this should be good enough. Maybe a warning in the message that this might allow the web page to update the firmware of the connected device?"

The problem here is that it's not obvious to users that this allows the site to quite likely take control of the user's computer.

The initial framing of this was: how do we avoid this mechanism being used for firmware updates, but if that's actually a feature you are trying to enable, I don't see how to make it safe.

[qdot]

There's still different levels of security inside of firmware updates too. For instance, are we /just/ worried about USB descriptor rewrite, which is what's required for the HID attack referenced? If so, there's nothing saying firmware rewrite would always enable that. Firmware is sometimes but not always responsible for USB descriptor handling.

If manufacturers are specifically open to third party firmware, it doesn't seem like the not-security-but-annoying issue of bricking is a thing we can reasonably worry about stopping. We'd have to expect the manufacturer to put in a way to always boot to bootloader, and to make sure the bootloader can't be overwritten by USB.

Not sure if this level of nuance matters in the argument or not, though, since we're mostly trying to cover unwanted firmware reflashes period.

[adamroach]

@ekr --

The initial framing of this was: how do we avoid this mechanism being used for firmware updates, but if that's actually a feature you are trying to enable, I don't see how to make it safe.

I think I'm reading that as "how do we avoid this mechanism being used for unwanted firmware updates?" For those devices that require the user to physically manipulate the device to initiate such an update, this seems to provide the right level of agency (unless I've overlooked something important). So whitelisting SysEx those devices that are known to have such a property would seem to get us to "safe," right?

[ekr]

@adamroach: again, I think the user has a lot of trouble meaningfully consenting to a firmware update, so "unwanted" seems difficult.

[martinthomson]

Is there any reason why SysEx access needs to be raw? Is it possible to identify common functions that are enabled by SysEx and build APIs specific to those functions?

My intuition is that the breadth of applications are large and the use of SysEx is sufficiently non-uniform as to make this untenable.

Thus, I might conclude that whitelisting would need to be contingent on some guarantee that either the device can't do bad things. Bad things definitely includes firmware updates, unless we have other guarantees that (for instance) this extends to a guarantee that a firmware update can't cause a device to change type or enable other new bad functions. That's a hard guarantee to extract, and a lot of effort to police effectively. I'm fairly sure that we don't want to be in that position.

[toyoshim]

Hi, I'm working on Chrome Web MIDI implementation. I'm happy to discuss better permission handling to improve Web MIDI security.

So, here are our mitigation approaches we already do for Web MIDI:

• Permission is allowed only for secure origins such as https
• Feature Policy - Powerful features including Web MIDI are disabled by default in cross-origin iframes, and the top frame needs to allow it explicitly.
• Kill switch - Have a server-managed emergency switch to kill the feature against zero-days

All three approaches are also used for other newly added device APIs that have similar concerns.

For common discussion around device APIs' security, Web USB implements a device chooser prompt that is believed to be better than usual permission prompts. It's considerable to introduce a similar approach to Web MIDI.

Some more information about SysEx that may be an answer for the question by @martinthomson . SysEx is a mechanism to define vendor specific commands. That's the reason why we need to allow raw SysEx message passing rather than providing abstracted API set.

Major use case of SysEx is to edit sound parameters on synthesizers. Sound librarian or editing applications need it. Since such application can be developed by third-party, whitelisting does not work. Such third-party often develop an editor for retro synthesizers because original native application does not run on recent versions of Windows/Mac, or just such old devices do not have good applications.

Firmware update is another major usage, and first parties really want this in Web MIDI. If SysEx is only for firmware update, whitelisting would work well. Since updating process heavily depends on device specific command and sequence, it will be hard to find a way to update the firmware, and need per-device investigation and need to develop per-device modified firmware. So attacking MIDI devices over SysEx firmware update is very expensive.

Unfortunately, just playing back Standard MIDI File (aka, .mid files) needs SysEx because it's very often used in most data to modify sound colors.

[martinthomson]

Thanks for the extra info @toyoshim. I'm hearing that MIDI without SysEx is virtually useless and MIDI with SysEx is a security nightmare.

Are there a common set of SysEx commands that would allow us to enable common use cases without exposing us to the possibility of things we don't want like firmware updates? For instance, if modifying sound colors is something that is common across multiple devices with the same commands, could we provide access to those commands only? Or is that too constraining? Or do certain commands have different interpretations when sent to different devices?

Is it possible to develop whitelists for completely safe devices and for other devices whitelists of safe commands? That's a pretty big exercise, but it might be the only way that this could be shipped safely.

I don't consider the measures that Chrome have deployed to be adequate against this level of threat. Obviously this is where Firefox and Chrome differ. Firefox doesn't ship WebUSB either, for almost precisely the same reasons.

[dvhdr]

Sysex messages are supposed to work by having a manufacturer-specific header (Novation's is 0x00 0x20 0x29). Most vendors stick to this, but it's not enforced in any technical way. I expect some smaller vendors don't, as you need to pay the MIDI Manufacturers Association to register the ID.

So you could whitelist by MMA registered vendors, and then as @mmckegg suggested, blacklist the small number of messages that can flip a device into bootloader mode without user input. I'd be surprised if there's more than a handful of devices that do this - ours do.

You'd always have the possibility of tricking a user into doing a firmware update - but that possibility exists with raw *.syx files too. An attacker could disguise malicious firmware as feature update, and trick users into installing it using software they already have. But if you're going to do that, you may as well just trick them into downloading an executable.

[jeffgca]

A couple of thoughts:

It's totally fine to ship initially without sysex. Sysex is something most consumer use cases do not need, eg you can still send note, sync and control data without sysex. I would be fine eliminating sysex from the MVP.

sysex is most commonly used for updating firmware of user data on midi devices and as was hinted at in other parts of this thread this functionality is very device-dependent. The most common workflow is something like:

1. physically engage sysex receive mode on the midi hardware usually by hitting actual buttons.

You need physical access to the device, and midi hardware varies hugely in terms of how this actually works. Also, while it may be true that I personally have a midi device or two connected to my system at all times, most people do. The potential attack surface is small and diverse.

2. send sysex via a midi connection to the device from some sort of software that supports sending midi data, in our case a web browser.

I think to initiate sending sysex from the web to hardware a permission prompt might be reasonable. If the user is in this mode, they are typically already doing a bunch of manual steps on the hardware as well as in the midi app to make this happen, and extra click isn't the end of the world.

[73rhodes]

SysEx is really useful in a lot of scenarios like triggering patch changes during live performances. It would be a shame to disable it and I think it it should be the responsibility of the device to take measures against things like unilateral firmware modification. I seem to recall my keyboards requiring confirmation for things like things that overwrite memory. This situation exists with any native midi sequencer already.

[ekr]

While I think that SysEx is the main area of threat, I don't want to lose the fact that anything is a threat here. It seems pretty clear that these devices were generally not intended to operate in an environment where the computer they are connected to them is controlled by the attacker. That means that there are quite likely defects in the processing of the non-SysEx messages that could lead to vulnerabilities and RCE, at which point we have the same problems.

[stpeter]

MIDI (standardized in 1983) assumes trusted communication among physically connected devices. Grafting that trust model onto the Web seems challenging...

[qdot]

@ekr If we're at the point of arguing that any MIDI hardware period is vulnerable, what does that mean for our ship/don't ship criteria for this? I'm not quite sure how I'm supposed to work with that.

If we're looking at it that way, GPUs were/are vulnerable too, we've seen sandbox escapes with them, yet WebGL shipped and continues to ship, and we sometimes blacklist drivers there as needed as part of that mitigation. The attack surface there is huge in terms of the user base, since video cards are kind of a requirement for computing. How is that different than what's being proposed here, between whitelisting/blacklisting/etc?

I realize no one can expect full security guarantees, nor can we just hand out access everywhere and trust the world, but I'm personally not feeling like we're moving toward any middle ground in this thread so far. I'd like to poke this in that direction more, or else understand what might be missing.

[qdot]

Also, in general for this thread, I'd say that I see WebMIDI as sort of a small litmus test for hardware API integration in Firefox in general. MIDI is a smaller use-case compared to things like Bluetooth and Sensors (WebUSB is still so new and contentious that I don't really want to bring it in to consideration quite yet for sake of not derailing completely), and those are also APIs that I'd like to maybe see happen at some point, so I'm hoping to take some points and lessons from this discussion to apply to those, if/when they come along.

[ekr]

@qdot: I don't think that moving to a middle ground is necessarily a virtue here. The question is whether we think that this feature can be safely shipped to our users, and either it can or it can't, but it's not like if it's half-safe then it's OK to ship.

WRT to the general security of MIDI hardware, my experience with embedded software is that it tends to be especially bad about defending against this class of attack, so absent either some research that suggests its generally safe or some representation from the manufacturers that it is, then it really needs to be presumed to be unsafe. Are the manufacturers willing to make that representation? I don't get the impression that they are.

Now, maybe on balance that's a risk we're willing to take, but my point above is that we need to be taking that risk into account, not just assuming that !SysEx == safe.

[cwilso]

I agree with Kyle's capturing of WebMIDI as a good litmus test for hardware API integration, as it is far more limited in scope than most.

A few specific points I want to address:

@martinthomson https://github.com/martinthomson> I'm hearing that MIDI without SysEx is virtually useless and MIDI with SysEx is a security nightmare.

This is not true. First, MIDI without SysEx will still let you use most common keyboard controllers - at least, the keys/sliders/drum pads kind of stuff - as ways to provide musical input to web apps. That's not useless at all. If that's all you feel you can do, then at least you can do that.

Second, I think the concern over the scope of potential damage via sysex is a bit out of kilter, and the user opt-in and secure origin not being considered as any protection at all. Trust is important; but just as you need to gain the user's trust for permission to access the camera, I don't see this as much different.

SysEx is used for a bunch of things:

1. There are some common, non-vendor-specific controller features that are coded via SysEx commands. Examples of these would be things like MIDI Machine Control (MMC - http://midi.teragonaudio.com/tech/mmc.htm), which enables extended play/pause/stop/record type control, or the MIDI Sample Dump Standard (SDS, which lets users transfer sound multi-samples from one device to another in a non-vendor-specific way). You could probably recognize these as a category. Some of my keyboard controllers have buttons like this
2. SysEx is used to edit system-specific patch settings or other controls, or transfer whole patches or libraries (or sound samples or the like) to and from devices. For nearly the whole of its 30 year history, this has been an incredibly important feature, as individual instruments tend to have limited screens and UI controls, and limited storage for patches, and users have developed lots of communities around transferring and trading patches. These are typically applicable only to a specific vendor if not device. This is also used for things like configuring flexible controllers, like DJ launchpads or LIVID controllers or the like.
3. There are some devices - like the ROLI Blocks, particularly the Lightpad Block (https://roli.com/products/blocks) - that simply can't map their massive data streams into the basic MIDI messages, and they bitpack into sysex messages. These controllers wouldn't be usable without sysex at all.
4. SysEx is most DEFINITELY used to update firmware. Vendors know this can be reverse-engineered and hacked; they also know that users might brick their devices if, say, someone happened to send out a Standard MIDI file that claimed to be a killer bass sound for a particular synth and actually contained a bricking malicious firmware update. (Yes, SysEx can - by design - be embedded in SMFs.) This is actually an incredibly powerful feature - for example, I have sitting just to my right as I type this a Novation Circuit groovebox, which has updated its functionality several times via a web page - and yes, they tell their users they need to use Chrome or Opera for now. This is the only way to update the firmware on a Circuit, actually - they don't have an .EXE updater, you need a Web MIDI browser. They also offer patch updates, and unlimited library storage in the cloud, as well as new samples you can dump on to the device this way. Obviously, any exploit here would only be applicable to a particular device.

In short - you can, and should if that's all you're comfortable doing, ship Web MIDI with all sysex disabled. That's not useless. However, I wouldn't characterize sysex support as "half-safe" -I would suggest it's a powerful feature, and should be treated like any other powerful feature.

As to @stpeter https://github.com/stpeter's question - I would NOT want to use a whitelist. There are hundreds if not thousands of new types of MIDI devices every year, and a very large number of manufacturers. Requiring entries on a whitelist would harm the richness of that ecosystem. If there was every an exploit that was actually causing significant user issues, as @toyoshim said I think we would hit the kill switch and then start blacklisting devices; however, we've been shipping sysex - requiring a permission prompt and secure origin - for a couple of years now without any concerns raised.

If you're not already talking to manufacturers like Novation and Yamaha on this concern, you should be. I'm happy to connect you if you need.

On Thu, Mar 1, 2018 at 4:51 PM, Kyle Machulis notifications@github.com wrote:

Also, in general for this thread, I'd say that I see WebMIDI as sort of a small litmus test for hardware API integration in Firefox in general. MIDI is a smaller use-case compared to things like Bluetooth and Sensors (WebUSB is still so new and contentious that I don't really want to bring it in to consideration quite yet for sake of not derailing completely), and those are also APIs that I'd like to maybe see happen at some point, so I'm hoping to take some points and lessons from this discussion to apply to those, if/when they come along.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mozilla/standards-positions/issues/58#issuecomment-369782912, or mute the thread https://github.com/notifications/unsubscribe-auth/AAe8eV0_Y-qZmA-v8MBKCIe9zdeiYce_ks5taJd9gaJpZM4SVw-v .

[ekr]

Second, I think the concern over the scope of potential damage via sysex is a bit out of kilter, and the user opt-in and secure origin not being considered as any protection at all. Trust is important; but just as you need to gain the user's trust for permission to access the camera, I don't see this as much different.

I think it's pretty clear from upthread why it's different: the threat here is compromise of the device leading to compromise of the user's computer. Not only does no such threat exist from access to the camera (though of course USB access to the camera would present such a threat), but the user is easily able to apprehend the threat from the camera, whereas this threat is almost entirely unobvious (and in fact the discovery of the threat in other settings such as VMs lead to several academic papers). It's worth noting that we delayed releasing screen sharing for a very long time for a threat that was a lot less severe but similarly unobvious (as compared to the camera).

I don't think a secure origin is relevant here. It's trivial for an attacker to get a certificate.

we've been shipping sysex - requiring a permission prompt and secure origin - for a couple of years now without any concerns raised.

Hmm... I'm not sure what you mean by "without any concerns being raised". I'm pretty sure I expressed these concerns to several people at Chrome. I know I did for WebUSB and WebBT.

[ekr]

While we're on the topic of WebUSB, https://www.wired.com/story/chrome-yubikey-phishing-webusb/

[marcoscaceres]

Hmm... I'm not sure what you mean by "without any concerns being raised". I'm pretty sure I expressed these concerns to several people at Chrome. I know I did for WebUSB and WebBT.

I'm going to guess @cwilso means "no reports of compromised devices or sites maliciously taking advantage of SysEx" (yet!). But that only holds until there is one such attack (and the severity of such an attack), which, if history is anything to go by, we can be fairly certain will happen.

Reading over the arguments, it seems like MIDI devices are different from USB devices, in that there is a at least some expectation from MIDI device owners that their devices will be "patched" and/or have their firmware rewritten.

Would that be a fair assessment? And would a sufficiently informative/scary permission prompt, like "You do understand that by enabling SysEx your MIDI device could be destroyed by this website? You really want to do this??!" be sufficient?

In a sense... it's similar to allowing users to proceed on sites with invalid SSL certs, where we put up a bunch of roadblocks and try to get them back to safety... but if they really want to go there, they can.

[adamroach]

Would that be a fair assessment? And would a sufficiently informative/scary permission prompt, like "You do understand that by enabling SysEx your MIDI device could be destroyed by this website? You really want to do this??!" be sufficient?

If I read the preceding comments correctly about the capabilities of SysEx, it's more like "this website could reprogram your MIDI device to act like a keyboard, and then use keyboard commands to do literally anything it wants to your machine, including uploading sensitive information -- such as your passwords, tax returns, or basically anything else of value on your machine -- to a hostile remote server."

That's a lot for a dialog box, and it really only captures one dimension of the possible harm.

[marcoscaceres]

and then use keyboard commands to do literally anything it wants to your machine

Yeah, this is pretty much the show stopper 😢

[dvhdr]

I’d argue that this attack opportunity already exists, in a more easily exploited form. To attack a USB MIDI device currently, you could:

1. Craft malicious firmware for a popular device
2. Embed said firmware in an enticing looking session file or synth patch dump
3. Create a malicious site - no need for HTTPS (but why bother, just use one of the existing patch or session sharing sites)
4. Wait for users to download it using their trusted browser and install it using their trusted DAW

At no point are they warned that this could be dangerous. There’s no “this file could harm your computer” at the point of download, because it’s not an executable. There's no warning from the DAW that sending sysex could be dangerous.

With sysex dumping from the browser, there is a chance to warn the user that the content may be unsafe, and the origin is verified by HTTPS. We're already in a better position!

[qdot]

We're going to try to pull a few more manufacturers in to get some view into their world and how this affects it. May take a day or two though.

[adamroach]

@dvhdr --

I’d argue that this attack opportunity already exists, in a more easily exploited form.

The top-line notion of web browser security is that it shouldn't be possible to visit a site and have something bad happen to you or your computer, unless you have been clearly warned of the risk, in a way that all users can understand, and agreed to it. You're pointing out that MIDI DAWs don't follow that same philosophy; however, their less rigorous approach to security and informed consent doesn't mean that we should relax ours.

[resource0x]

bricking can occur as a result of legitimate update too, with higher probability. (My laptop was recently bricked by Windows update). With Web Midi, manufactures will be able to provide online interface, which, among other things, can help to un-brick it. Other possibilities like simulating keyboard commands by attacker and other scary scenarios may be implemented only with the help of device driver (please correct me if I'm wrong) - in which case the driver itself is a security threat, with Web Midi or without

[ekr]

"Other possibilities like simulating keyboard commands by attacker and other scary scenarios may be implemented only with the help of device driver (please correct me if I'm wrong) "

I'm not sure what you mean by "help of device driver". Many computers will treat any USB device that claims to be a keyboard as a keyboard with basically no user intervention.

[svgeesus]

I'm also not a MIDI person, so don't really know the implications of not including SysEx. The doc says the consequences are "severe" with respect to limiting functionality

I'm a MIDI person; and while useful work can be done without SysEx, shipping with SysEx always disabled would be a severe limitation. As an analogy, useful work can be done with just HTML and CSS, but shipping a browser with JS always disabled (because there can be security issues) would be a significant limitation.

We're going to try to pull a few more manufacturers in to get some view into their world and how this affects it.

Yes, great idea. Manufacturers of MIDI equipment are definitely folks to talk to. Consider too the Maker community, because MIDI-enabled devices are very popular there. And thus, a whitelist would be actively harmful.

[svgeesus]

See Table VIIIa in the MIDI 1.0 spec: "CURRENTLY DEFINED UNIVERSAL SYSTEM EXCLUSIVE MESSAGES "

Universal SysEx is used for things like tuning, sample dump, and time-code related control (start, stop, cue points, sample looping ...), MIDI Show Control, and so on.

[adamroach]

Without taking a position on whether deploying with equipment-specific SysEx limitations is okay, I have two observations to make.

The first is that, in cases like this, whitelists are fail-safe, while blacklists are fail-dangerous: unknown (and exploitable) equipment will not appear on a blacklist. For this reason, I believe that blacklists are a complete non-starter.

The second observation is regarding the interaction between the maker community and whitelists. Given the skills and hacker ethos of the maker community, I believe that all that would be required to accomodate their use cases would be allowing side-loading of equipment identifiers through a non-web-accessible mechanism (e.g., via about:prefs).

[ekr]

One thing that occurred to me the other day is that we might be able to do some CORS-like consent thing. I.e., we send some well-defined SysEx message to the device to ask "are you safe for me to send WebMIDI to", and then only allow it with the proper response.

[qdot]

@adamroach @ekr That's something I've been meaning to ask. How do we deal with "user has to change a pref to turn something dangerous on" in this situation? Like, would "unbounded sysex behind pref" even be viable? On one hand, it's definitely a complex user gesture, while on the other, does it mean everyone that wants WebMIDI just says "Here's instructions to turn on firefox pref [x]?"

[ekr]

Well, Firefox is full of crazily dangerous prefs, so I'm not worried about creating another one, but that shouldn't be our authorized mechanism to enable a feature.

[resource0x]

@ekr if firmware is so bad that it allows update to completely override its functionality (including impersonating something else) then how "are you safe for me to send WebMIDI to" can help? Everybody will upgrade their firmware to answer 'yes', and you are back to square 1. Whitelist will do the same with less hassle :)

[ekr]

@resource0x: As I said at the beginning, the problem here is usually that the firmware has been written to a non-adversarial threat model. That's not necessarily an unreasonable model when the computer its talking to is under the control of the owner of the device, but WebMIDI breaks that model, which is why it's unsafe for the Web browser to just unilaterally change it out from under the device. However, if the device has to opt-in, then it's the job of the device manufacturer to harden the device before representing that it's safe (and we can document what "harden" means in this case). Of course, they can lie, but that's on them, not us, just as it's the site's fault, not the browsers, if someone breaks in and steals your credit cart number, even though it's the browser that let you send the number to the site.

With that said, a whitelist seems fine from a security perspective; I was attempting to respond to complaints it was too onerous.

[resource0x]

Looking at https://www.midi.org/specifications/item/table-4-universal-system-exclusive-messages, the impression is that only a small subset of SysEx messages has a potential to affect anybody but the instrument itself. Maybe only those need special permissions? Isn't it too draconian to constrain all SysEx interface just because of this subset?

[Makio64]

Hi guys, I use MIDI for VJing with webgl and having the possibility to do it on firefox will be nice :)

MIDI Controler allow live play, they are fun and peoples who uses it focus on creating cool stuffs ( music / visual / installation / etc.. ). Make it easy plugnplay is a very important.

This said, the security issue should be taken seriously and asking the user to understand the full consequence of his act and use it only with trustfull MIDI Controller will filter a lot of troubles and make them double check, keeping the user safe.

Just my feedback as an average MIDI Controler + web technology user .

[andrejhronco]

Hi everybody, at Keith McMillen Instruments all of our new generation product editors use Web MIDI to send sysex for preset updates and firmware updates, this includes BopPad, K-Board Pro 4, and Mallet Station which we built for Pearl Drums. It's the very core of the functionality of the editor. https://files.keithmcmillen.com/products/boppad/editor/

Due partly to the limited availability of web MIDI, we also build a standalone web app wrapped in Electron, which the vast majority of our users use.

I understand the security conundrum and don't really have any suggestions other than what have been presented above, but for KMI and it seems Novation, shipping Web MIDI with sysex disabled would make the editors completely useless on FireFox. it's a really powerful feature that it seems a lot of MIDI manufacturers are interested in using since it allows their user base instant access to powerful product software.

I hope there is a way we can have features and security

[bzbarsky]

@AndrejHronco Do the devices in question allow sysex firmware updates to make them look like USB keyboards?

It seems to me that the only way to have "features and security" here is to ensure that the features cannot be used in ways that compromise security. In practice it sounds like a bare minimum is placing certain limits on just how much sysex firmware updates can change about the way the device interacts with the USB host.

[svgeesus]

"this website could reprogram your MIDI device to act like a keyboard, and then use keyboard commands to do literally anything it wants to your machine, including uploading sensitive information -- such as your passwords, tax returns, or basically anything else of value on your machine -- to a hostile remote server."

(Note for the MIDI folks reading, in the above 'keyboard' means a computer keyboard for entering characters, not a music keyboard for entering notes)

I have been thinking about this potential exploit and it does seem very theoretical. Look at the USB specification for a MIDI device and for a computer keyboard. The data structures are very different. Even for a generic microcontroller (like a Teensy, which has a USB MIDI and also a USB keyboard option) changing USB device type is something you do as a compiler option, which links in different libraries; it is not something one could do on-the-fly by reading SysEx data and then doing something with it, even if that was the intent of the firmware writer.

[martinthomson]

To counter @svgeesus' point here, an attack on the MacBook Pro camera rewrote the firmware to perform a VM escape: https://jscholarship.library.jhu.edu/bitstream/handle/1774.2/36569/camera.pdf

That paper references other examples. You can't assume that this is not possible just because it is hard.

It might be possible, though it might need operating system assistance, to pin the device type down somehow, such that its type couldn't change, but that's likely beyond what we are currently capable of.