akabulous Posted 2 hours ago Posted 2 hours ago Steps to repeat the bug: 1) use the cross platform PoC written in C, the Python one that everyone is sharing contains obfuscated code (bad ju-ju) and is x86_64 specific `git clone https://github.com/tgies/copy-fail-c` `cd copy-fail-c` 2) compile either on your target device natively, or do what I did and cross-compile it as a static binary using an aarch64-linux-musl toolchain (this made it easy to test on different SBCs) `PREFIX="/opt/toolchains/aarch64-linux-musl-cross" CC=aarch64-linux-musl-gcc LD=aarch64-linux-musl-ld CFLAGS="-static -fPIC -I/opt/toolchains/aarch64-linux-musl-cross/include -L/opt/toolchains/aarch64-linux-musl-cross/lib" LDFLAGS="-static -fPIE -L/opt/toolchains/aarch64-linux-musl-cross/lib" make -j$(nproc --all)` 3) pass the resulting binaries "payload" and "exploit" to your target device (if you cross compiled) 4) from an unprivileged user account not in the sudo group, run the exploit I'm not here to point fingers but I would like to see AT LEAST an advisory of this potentially devastating bug with a public exploit available on the Armbian homepage, radio silence for over a week seems completely inappropriate to me 0 Quote
Igor Posted 1 hour ago Posted 1 hour ago 59 minutes ago, akabulous said: radio silence for over a week seems completely inappropriate We understand the concern, and we appreciate the effort put into testing and documenting the issue. At the same time, it is important to understand the realities of the embedded Linux ecosystem. Armbian supports a very large combination of SoCs, vendor kernels, boot chains, and downstream modifications across several hundred boards. Security response and validation in this environment is significantly more complex than in standardized desktop/server distributions. Explained here: https://github.com/armbian/build/issues/6937#issuecomment-4366571379 This is not a matter of ignoring the issue, but of limited engineering resources, kernel fragmentation, and the high cost of validating fixes safely across multiple platforms. Project can only finance security from your contributions https://github.com/sponsors/armbian volonteers or sponsors. Until none is taking this seriously, there is little what existing team members can do. We already attempted mitigation work on one of the most widely used kernel branches: https://github.com/armbian/linux-rockchip/pull/475 but even targeted fixes require substantial testing effort and may (i am sure it will) introduce regressions on affected hardware families. Current resources barely sustain even our regular release and maintenance process: https://docs.armbian.com/Process_Release-Model/ For users who need receiving upstream fixes faster and are willing to accept a higher risk of regressions on hardware feature breakage, there is always an option to switch to rolling/daily builds, where fix may already be available: https://docs.armbian.com/User-Guide_Armbian-Config/System/#rolling Tradeoff between stability, validation cost, hardware compatibility, and update speed is unfortunately a sad reality of embedded Linux maintenance. 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.