Latest security news
Sat, October 24Today
Electron: Mitigation for compromised eMudhra intermediate certificates
影響: npm:electron >= 45.0.0-alpha.1, < 45.0.0-beta.6 → 45.0.0-beta.6, npm:electron >= 44.0.0-alpha.1, < 44.9.1 → 44.9.1, npm:electron >= 43.0.0-alpha.1, < 43.8.1 → 43.8.1, npm:electron < 42.11.16 → 42.11.16 A set of eMudhra intermediate certificates were compromised and are being blocked by browsers and other TLS clients. This Electron update adds the same block to both Chromium networking and Node.js tls, https and fetch. On earlier versions, an attacker holding a certificate issued through these intermediates and able to intercept network traffic could impersonate a TLS server to an app. Apps are only affected if they make TLS connections over a network an attacker can intercept. Apps that make…
Fri, October 23Yesterday
Electron: SameSite cookie restrictions are not applied to windows opened from links
影響: npm:electron >= 45.0.0-alpha.1, < 45.0.0-alpha.6 → 45.0.0-alpha.6, npm:electron >= 44.0.0-alpha.1, < 44.3.0 → 44.3.0, npm:electron >= 43.0.0-alpha.1, < 43.7.0 → 43.7.0, npm:electron < 42.11.3 → 42.11.3 Pages opened into a new window from a link were loaded as if the app itself had navigated there rather than the page that contained the link, so the request was treated as same-site: SameSite=Strict cookies were sent and Sec-Fetch-Site did not identify the initiating page. Content shown in the app could use this to make a credentialed top-level request to another site that relies on SameSite cookies as a CSRF defence. Apps are only affected if they load untrusted content and allow it to open ne…
Electron: Pointer lock permission requests can be attributed to the wrong frame
影響: npm:electron >= 45.0.0-alpha.1, < 45.0.0-alpha.13 → 45.0.0-alpha.13, npm:electron >= 44.0.0-alpha.1, < 44.5.0 → 44.5.0, npm:electron >= 43.0.0-alpha.1, < 43.7.6 → 43.7.6, npm:electron < 42.11.9 → 42.11.9 For pointerLock permission requests made from some cross-origin iframes, session.setPermissionRequestHandler() was given the top-level frame's requestingUrl and isMainFrame instead of the requesting frame's. Apps that grant pointer lock based on the requesting origin could grant it to embedded content under the top-level page's identity. Apps are only affected if they embed untrusted content in iframes and decide pointerLock requests by origin in setPermissionRequestHandler. Apps that do not em…
Electron: openExternal permission requests can be attributed to the wrong origin
影響: npm:electron < 42.11.3 → 42.11.3, npm:electron >= 43.0.0-alpha.1, < 43.7.0 → 43.7.0, npm:electron >= 44.0.0-alpha.1, < 44.3.0 → 44.3.0, npm:electron >= 45.0.0-alpha.1, < 45.0.0-alpha.5 → 45.0.0-alpha.5 Requests to open external protocol URLs could be attributed to a document other than the one that asked for them, so the requestingUrl passed to session.setPermissionRequestHandler was a trusted origin for a launch untrusted content had requested. An origin-based handler could therefore let untrusted content launch an OS-registered external application. Apps are only affected if they grant openExternal based on the requesting origin and let untrusted content open or navigate windows. Apps whose…
Thu, October 22
Electron: HID and USB permission checks can be attributed to the wrong origin
影響: npm:electron >= 45.0.0-alpha.1, < 45.0.0-alpha.5 → 45.0.0-alpha.5, npm:electron >= 44.0.0-alpha.1, < 44.3.0 → 44.3.0, npm:electron >= 43.0.0-alpha.1, < 43.7.0 → 43.7.0, npm:electron < 42.11.3 → 42.11.3 For hid and usb permission checks made from an iframe, session.setPermissionCheckHandler was given the top-level frame's origin and details instead of the requesting frame's. Apps that allow these permissions based on origin could grant an embedded frame access intended for the top-level page. You're only affected if you use setPermissionCheckHandler with origin-based logic for hid or usb and embed cross-origin iframes with allow="hid" or allow="usb". Apps that don't delegate those featu…