LionsOS musllibc old version? Vulnerable?
Hi, reading the dependencies of LionsOS I realized it is using an old version of muslibc : https://github.com/au-ts/musllibc/blob/81842bc43d0b49bbcca03ff5f506c6df8e2bd... if this version has not been patched may be vulnerable to a remotely exploitable buffer overflow in the dns resolution: https://git.musl-libc.org/cgit/musl/commit/?id=45ca5d3fcb6f874bf5ba55d0e9651... Can someone confirm or reject? Thanks.
The musllibc version is quite old yes and so I believe the patch that you link would not be included in the version we pin to. For context, we’ve initially used the musllibc that other seL4 projects used which has not been updated in a long time. That will likely change in the future [1]. The libc has been used for porting off-the-shelf libraries/components such as libnfs and MicroPython which are already considered untrusted. I believe our trusted components such as sDDF virtualisers do not depend on musllibc at all, which is good because we want to be able to verify *all* their code. Given that muslibc is unverified I’m sure that there are many more vulnerabilities to come! [1] https://github.com/au-ts/lionsos/issues/48 Ivan
The musllibc version is quite old yes and so I believe the patch that you
in the version we pin to. For context, we’ve initially used the musllibc
Hi Ivan!
Ok so now we have confirmation that the musllibc in LionsOS is vulnerable,
my question is: does LionsOS use musllibc to resolve hostnames (maybe via
libnfs)?
What I'm trying to understand is if this vulnerability can be triggered in
LionsOS in any way.
I already know musllibc will be vulnerable to many bugs in the future (it
is non verified C code...) and also know the difference among verified and
unverified code... my real interest is the robustness of software design,
so in a software solution where there are different pieces glued together,
some of them very reliable (seL4) and some of them very unreliable
(musllibc) and other pieces half way between realiable-unreliable world,
how they interact each other...
So, can this musllibc vulnerability be triggered in LionsOS in any way?
Thank you!
On Wednesday, November 27, 2024, Ivan Velickovic via Devel
has not been updated in a long time. That will likely change in the future [1].
The libc has been used for porting off-the-shelf libraries/components such as libnfs and MicroPython which are already considered untrusted. I believe our trusted components such as sDDF virtualisers do not depend on musllibc at all, which is good because we want to be able to verify *all* their code.
Given that muslibc is unverified I’m sure that there are many more vulnerabilities to come!
[1] https://github.com/au-ts/lionsos/issues/48
Ivan
_______________________________________________ Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems
The musllibc version is quite old yes and so I believe the patch that you link would not be included in the version we pin to. For context, we’ve initially used the musllibc that other seL4 projects used which has not been updated in a long time. That will likely change in the future [1].
The libc has been used for porting off-the-shelf libraries/components such as libnfs and MicroPython which are already considered untrusted. I believe our trusted components such as sDDF virtualisers do not depend on musllibc at all, which is good because we want to be able to verify *all* their code.
Given that muslibc is unverified I’m sure that there are many more vulnerabilities to come! In practice I expect many real-world deployments to rely on
On 11/26/24 6:14 PM, Ivan Velickovic via Devel wrote: libc in trusted parts of the system. The only exception would be safety-certified embedded systems. People really do expect that DNS resolution is safe, even if they do not expect the same for e.g. parsing untrusted images. Also, a remote code execution exploit could be chained with e.g. a Spectre exploit to steal confidential information from trusted parts of the system. -- Sincerely, Demi Marie Obenour (she/her/hers)
participants (3)
-
Demi Marie Obenour -
Hugo V.C. -
Ivan Velickovic