Electron DevelopersTDSA-2024-001
Build Server Command Execution via postinstall Script
Details Published:
No Action Required
This vulnerability was addressed through infrastructure changes on the ToDesktop platform. No action is required from customers.
The fix was deployed on 2024-10-03 and all ToDesktop for Electron users are automatically protected.
Summary
On October 2nd 2024, a security researcher (T/A xyz3va) reported that she was able to gain access to ToDesktop’s Firebase Service Admin Account.
We have reviewed logs and inspected app bundles. No malicious usage was detected. There were no malicious builds or releases of applications from the ToDesktop platform.
We promptly patched the vulnerability and rotated all keys. In addition to patching the vulnerability, we engaged a third-party cybersecurity company, Doyensec, to conduct an independent audit of our platform and build pipeline.
Impact
- No customer data or applications were compromised
- No action required from customers
- Resolution time: 26 hours
Technical Details
This vulnerability occurred because the build container had broader permissions than necessary, allowing a postinstall script in an application’s package.json to retrieve Firebase credentials. The vulnerability allowed remote attackers to execute arbitrary commands on the build server (e.g., read secrets from the desktopify config.prod.json file), and consequently could have been used to deploy updates to any app.
Had this vulnerability not been identified and responsibly disclosed, a malicious actor could have potentially caused significant harm. In the worst case, this would have allowed an attacker to access the ToDesktop database, user accounts, and deploy unauthorized updates to applications.
Timeline
All timestamps are in Coordinated Universal Time (UTC).
| Date and Time | Event |
|---|---|
| October 2nd, 2024 6:36pm–6:58pm | The researcher reported the vulnerability, and we acknowledged and confirmed it. |
| October 2nd, 2024 9:00pm | Rotated all affected credentials. |
| October 2nd, 2024 10:00pm | Conducted a preliminary review of logs and investigated recent releases, with no immediate signs of unauthorized access. |
| October 3rd, 2024 8:13pm | Deployed a patch for the vulnerability to production. |
| October 5th, 2024 12:17pm | Completed review of the logs. Confirmed all identified activity was from the researcher (verified by IP Address and user agent). |
| January 21st, 2025 | Third-party security audit with Doyensec completed. |
| February 25th, 2025 | Subsequent retest by Doyensec completed. |
| March 1st, 2025 | Public disclosure. |
Actions and Remediations
Immediate Fixes
- Rotated all sensitive tokens.
- Patched the vulnerability by removing the Firebase Service Account token and implemented a restricted-access solution, granting only the minimal permissions necessary for builds.
- Enhanced alerts for suspicious usage of sensitive access tokens.
Long-term Enhancements
Security audits and testing:
- Completed a third-party security audit with independent cybersecurity company, Doyensec. The audit was completed on January 21st, 2025. A subsequent retest was completed on February 25th, 2025.
- We are committing to undertake annual security audits in the future.
Access control and authentication:
- All customers must now use a security key (WebAuthn token) to release app updates, ensuring only authorized releases. This key-based authentication is managed separately from our main systems to prevent unauthorized access even if other parts of our infrastructure are compromised.
- Implemented access control permissions for build and release processes, allowing account admins to assign specific permissions to team members and restrict sensitive actions.
- To prevent unauthorized additions to teams, inviting new users now requires authentication with a security key, ensuring only authorized admins can expand access.
- Sensitive actions, such as updating secrets or inviting new users, now trigger notification emails to the account owner.
Infrastructure and tooling:
- We’ve applied the Principle of Least Privilege (PoLP) to our ephemeral build containers, meaning each process has only the minimum access needed to function. We’ve also open-sourced two tools we built to help achieve this: KeyVault Gatekeeper and Firestore PoLP.
- Introduced an option for customers to self-host updates and downloads. The source code is freely available and open-source, with setup instructions accessible on GitHub. This allows customers to manage their own self-hosted update and download infrastructure if they choose.