Important Information
If you have the Loom Desktop for Mac installed (this does not apply to Windows), please check that you have at least version 0.17.3 installed. You can either download the app directly, or you can check if you have the latest version of our app by clicking on the 3-dot menu in the upper-right corner of our app and then selecting Check for Updates.
On July 9th, 2019 our team was made aware of three separate security vulnerabilities in our desktop application. We have since fixed all three. Here is the log of action:
July 9th, 2019 – Received inbound email detailing security issues from Thomas Karpiniec
July 12th, 2019 – Sent messages to Thomas confirming the issue and that a fix was in progress
July 26th, 2019 – Loom shipped update 0.17.2. This version fixed the remote code execution vulnerability and improved resilience to malformed input.
July 30th, 2019 – Loom shipped update 0.17.3. This fixed Loom’s internal web server binding on port 0.0.0.0.
What Happened
Now that you’ve updated your Loom desktop app, we’d like to take a bit of time to explain what happened.
On July 8th, 2019, it was discovered that Zoom had a zero day vulnerability that allowed users to leverage a web server they hosted locally on each user’s machine. If an attacker knew how to connect to this web server, they could use this web server to activate the user’s camera and execute code. The latter attack is called a Remote Code Execution vulnerability, or RCE, for short. You can read more about this vulnerability and its story here.
During this same time, many security researchers started to find other apps using this same pattern of hosting a web server on a user’s machine. For most apps, it appears the use case is for the user’s web browser to talk to the application. I personally worked on a project that explored this possibility and decided against it.
That being said, we still leverage a web server. We simply didn’t implement it with the intention of other applications being able to talk to it other than our own. In fact, we implemented measures to make sure the web server couldn’t be communicated with unless it was from a trusted application by:
Randomizing the port we open the web server on
Ensuring a secret is generated from within our application that is only given to another application spun up from within our app code.
Despite these measures, Thomas reported 3 security flaws:
Our connection secret logic had a flaw in it, and he was able to connect to the web server regardless of sending any secret.
Once connected, although he wasn’t able to leverage an RCE vulnerability in the way we parsed messages. This vulnerability is only able to be leveraged/initialized during a recording.
We were binding to host 0.0.0.0 instead of 127.0.0.1, which meant anyone on a local intranet would be able to leverage this kind of attack against a user with our application installed on the same intranet.
We have since fixed all issues.
You might be wondering why Loom uses a web server at all if it’s not meant to be connected to from outside our application. The reason is because our recording layer is separate from our UI layer. Our recording layer is written in native code and needs to communicate with our UI layer, which is written in different code via Electron. The recording layer was written in native code in order to leverage better APIs for better performance, and the UI layer was written in Electron in order to leverage Electron’s cross-platform capabilities and decrease iteration cycles for our engineers. There is no industry-standard way for these 2 layers to talk to each other, so we leverage a web server for this.
Closing Notes
We do not take this situation lightly and have fixed all issues in a way that doesn’t simply fix these specific problems but also fixes a host of the same types of problems from coming up in the future. Our users record sensitive information into our platform, and we do not take that for granted. Loom will continue to improve its security practices, and we’re grateful for security researchers like Thomas. We have compensated him for his efforts.
FAQs
Was I hacked? Can you confirm if I was?
We have done an investigation and we have not been able to find that anyone’s information or account was compromised.
How can I tell if someone accessed my camera or microphone?
No one has accessed your camera or microphone. Those code paths are protected by our app and not accessible without first getting certain credentials from our server, which is not possible via this exploit path.
What exactly does this mean? Did hackers access my computer without my knowledge?
To our knowledge, no one was compromised. All messages sent to the web server we mentioned in the blog post have been expected messages with the exception of messages Thomas sent to his own application for testing purposes.
Does this mean someone was able to access my camera or microphone?
In theory, yes, but the window of opportunity for this to happen is small and we have run a thorough investigation to ensure no data breach had occurred. To our knowledge, no one has leveraged this vulnerability.
How do I know this is been resolved and how can you assure this doesn’t happen again?
We have paid the security researcher who reported this and were able to confirm the fix with him and internally. We have written code that will prevent this vulnerability from happening again. We have also put in code that forces certain users who may be more susceptible to upgrade to the latest desktop version.
If you have any questions, please feel free to shoot me a Tweet/DM @vhmth or email us at support@loom.com.