Logic2 security posture

[natevw]

My impression based on the developer docs and posts like Third party libraries with HLAs is that the Logic2 app does no sandboxing of its Python extensions — is that a correct understanding?

And based on download size and mention of WebGL my impression is that the app is now Electron-based. If that’s a correct assumption, can you speak to what plans Saleae has for ensuring that its own bundling of third-party JS libraries as well as the Python code run through the marketplace don’t negatively impact the privacy/stability implications of using your hardware?

[markgarrison]

Thanks @natevw for asking. This has been pretty new territory for us actually.

First, the marketplace, since that’s probably the most important thing to discuss with regards to the security of our application.

Currently, extensions are not sandboxed. Extensions are not automatically installed (except for 2 Saleae written & controlled ones) and we don’t auto-update extensions. It’s only possible to publish extensions from open source github repositories, making the source code for all extensions easily browsable. That’s about all we do at the moment though. We had a similar discussion here near the beginning of the extension marketplace development. Our first action was to take a look at what security measures similar tools took, such as Microsoft’s VS Code and Google Chrome, as well as npm and PyPI - which, in large, don’t provide any security for the end user either. One of my colleges can speak more about the possibility of sandboxing and the technical challenges involved in our application.

Second, you mentioned Electron, and the third party npm packages that we’re bringing with that. The main risk here, and I think the same one you’re thinking of, is that we could install a malicious npm module, and then deploy that to end user computers, where it runs in a privileged environment.

At the moment, we have pretty basic safeguards against this. Because we use yarn, the version of the npm package that is selected at install time, and is not automatically updated on clean builds of the application, and remains the same until we manually update a specific npm module (and it’s dependencies). This, at a minimum, protects us (and many other projects out there) from situations where an npm module is compromised. However, the risk remains that the npm module (or one of its dependencies) was already compromised. We do automatically get security alerts on our entire dependency graph. This is a problem common to all Electron apps, such as visual studio code, slack, or skype.

I’m curious to hear what your expectations are for marketplaces and installed desktop apps. Our software has been capable of loading 3rd party C++ plugins pretty much since launch, although we didn’t have a marketplace for easy distribution. I also think we can and should do a better job of setting expectations with marketplace content (there are currently 3 non-saleae created extensions). Overall, using Electron is a larger vector than our original C++ application, which only shipped with a handful of 3rd party libraries.

What would be particularly helpful (because we have been having trouble figuring it out ourselves) would be any examples of desktop applications with extension marketplaces that you think are doing things right.

[john]

Hi @natevw. You bring up a good option for Python sandboxing using PyPy. We looked at PyPy in general early in the HLA development but found it had some limitations that made it unsuitable for our use case. In particular it has a lot of difficulties and caveats with interacting with C/C++ code. This is critical for us both for being able to interoperate with our C++ backend, and for supporting important Python extensions like NumPy. This also limits the usefulness of the sandbox, since we need to allow shared-memory interactions with C++ that (as the PyPy documentation highlights) create a lot of opportunities for escape.

Also with respect to PyPy’s sandboxing, it is not to my knowledge used in any popular program that has to deal with significant adversaries analyzing it or has gone through an audit. Even browser JS engines which are the most examined JIT sandboxes available have code generation vulnerabilities with some regularity, so I have some doubts that this would be an effective way to sandbox the application.

We are also limited in what process-level sandboxing we can do on the backend, since it must interact with raw USB devices on each platform. This would necessitate splitting the backend into a multi-process model on all three of our major platforms, similar to Chrome’s sandbox model. This would be made much more difficult by the high data rate we need to be able to handle from the USB devices, which rules out some simpler IPC strategies. In short, it would require a sandboxing strategy of which the only examples I’m aware of are the major browser vendors, which have a far broader and more aggressive threat model than we do.

[natevw]

Thank you both for the thorough (and thoroughly transparent!) replies. I think you raise excellent points.

Admittedly when I pulled up Logic2 for the first time I was struck mostly by the change from the original Logic app, now with its big sidebar tempting me to start running “random” extra Python code right away. A fairer contrast, as you bring up, would be between Logic2 and other “pro” tools like VS Code, DAWs with their VST plugins, and really just about every other app that lets me add anything… or open malicious documents for that matter.

I also agree that it’s a hard problem, even for the big platforms. E.g. I don’t think Apple’s expensive/obsessive/anticompetitive “curation” of their store has done much beyond what their sandboxing system does on its own. And understand the effort it would take to build a high-performance sandboxing solution across three substantially different platforms (each of which is evolving in these areas anyway).

I’ll keep thinking about your questions as I don’t have good answers:

• what your expectations are for marketplaces and installed desktop apps
• any examples of desktop applications with extension marketplaces that you think are doing things right
• examples of effective sandboxing apart from major browser [/OS] vendors

I’m gradually playing more and more with “general purpose” isolation stuff like VMs and containers and maybe the answer is to keep watching that space while continuing to wrestle with the paranoia/practicality questions. I could be convinced that it’s an OS-level problem, while still being heartened by the thought you’ve already put into it for your own app. Thanks again!

[indeterminatus]

In my personal opinion, extensibility (and the freedom to use the machine to its full extent without “battling” against security sandboxes) trumps the fear of malicious marketplace content, right now.

I think that the Saleae extension market place is way too small currently to be interesting as attack vector, especially given its users are not the typical “I can’t phone you via e-mail, what is wrong with the internet on my phone?”-Grannies, but engineers (some of which may of course be Grannies). Once a critical mass of 3rd party extension is reached, it may be worthwhile to re-evaluate your position with respect to content moderation, but right now I think that this would pose a barrier for someone trying to contribute (and do you more harm than good).

Sticking a device into a USB port already requires a huge amount of trust, and it’s not as if anyone is forced to install any 3rd party extensions. Not saying that your points and concerns are not valid, @natevw, on the contrary.

I would love some “official statement” for the Logic 2 software, what kind of behaviour is expected (by itself and any “well-behaved” extension), to ease setting up firewall rules for the ones who feel better when some rules are enforced, and to provide some guideline for extension developers what the community would deem OK, and leave the rest to peer review. It may be worthwhile to think about a contingency plan, how to act if an extension is actually reported as malicious, but this is also reactive and not proactive (like most things when it comes to security).

Maybe it would also be good to inform the user before installing any non-official (read: Saleae) extensions that there are risks involved (I guess concerning security, stability, performance).