When /tmp mounted noexec: Failed to handle colibri request: java.lang.UnsatisfiedLinkError: libjnisctp.so: failed to map segment from shared object [Debian] [amd64]

spent a day fighting with jisti, only to realise it was because my /tmp is mounted noexec (as it should be), however jisti seems to copy libjnisctp.so to /tmp (and then delete it), this seems like bad practice and opens up the services to a bunch of attacks, which while difficult/possible to exploit seem like they could be avoided by loading the file from /usr

JVB 2021-12-03 23:22:52.345 WARNING: [51] [confId=bde0745023317088 gid=65443 conf_name=test2@conference.DOMAIN.com] ConferenceShim.lambda$new$0#98: Failed to handle colibri request: 
java.lang.UnsatisfiedLinkError: /tmp/nativeutils11334360586629151/libjnisctp.so: /tmp/nativeutils11334360586629151/libjnisctp.so: failed to map segment from shared object
at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method)
at java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2442)
at java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2498)
at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2694)
at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2627)
at java.base/java.lang.Runtime.load0(Runtime.java:768)
at java.base/java.lang.System.load(System.java:1837)
at cz.adamh.utils.NativeUtils.loadLibraryFromJar(NativeUtils.java:109)
at org.jitsi_modified.sctp4j.SctpJni.<clinit>(SctpJni.java:32)
at org.jitsi_modified.sctp4j.Sctp4j.init(Sctp4j.java:41)
at org.jitsi.videobridge.sctp.SctpManager.<clinit>(SctpManager.java:61)
at org.jitsi.videobridge.Endpoint.createSctpConnection(Endpoint.kt:535)
at org.jitsi.videobridge.shim.ContentShim.createSctpConnection(ContentShim.java:165)
at org.jitsi.videobridge.shim.ContentShim.getOrCreateSctpConnectionShim(ContentShim.java:357)
at org.jitsi.videobridge.shim.ColibriUtil.processSctpConnections(ColibriUtil.java:198)
at org.jitsi.videobridge.shim.ConferenceShim.handleColibriConferenceIQ(ConferenceShim.java:467)
at org.jitsi.videobridge.shim.ConferenceShim.lambda$new$0(ConferenceShim.java:83)
at org.jitsi.utils.queue.PacketQueue$HandlerAdapter.handleItem(PacketQueue.java:381)
at org.jitsi.utils.queue.AsyncQueueHandler$1.run(AsyncQueueHandler.java:133)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
ii  jitsi-meet                                   2.0.6433-1                            all          WebRTC JavaScript video conferences
ii  jitsi-meet-prosody                           1.0.5415-1                            all          Prosody configuration for Jitsi Meet
ii  jitsi-meet-web                               1.0.5415-1                            all          WebRTC JavaScript video conferences
ii  jitsi-meet-web-config                        1.0.5415-1                            all          Configuration for web serving of Jitsi Meet
ii  jitsi-videobridge2                           2.1-570-gb802be83-1                   all          WebRTC compatible Selective Forwarding Unit (SFU)
There are 3 choices for the alternative java (providing /usr/bin/java).

  Selection    Path                                                Priority   Status
------------------------------------------------------------
* 0            /usr/lib/jvm/java-11-openjdk-amd64/bin/java          1111      auto mode
  1            /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/java   1081      manual mode
  2            /usr/lib/jvm/java-11-openjdk-amd64/bin/java          1111      manual mode
  3            /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java       1081      manual mode
lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 10 (buster)
Release:        10
Codename:       buster
uname -a
Linux DOMAIN 4.19.0-17-amd64 #1 SMP Debian 4.19.194-3 (2021-07-18) x86_64 GNU/Linux
1 Like

This is the function that does it, from this library, which looks a bit unmaintained (and its idea of extracting libraries to $TMPDIR and then loading them is a bit dangerous to start with). Maybe there’s a safer option that this could be replaced with.

In the meantime you may be able to work around this with -Djava.io.tmpdir=/path/to/somewhere/else

From a quick look through the JVB source, this code path is only triggered if SCTP is enabled, so if you’ve updated to use the JVB WebSockets you could disable SCTP and avoid the issue entirely.

3 Likes