Security issues in Openvidu 2.29

[poojakamra]

We are using openvidu 2.29 community edition. All the development is done but before delpoying the solution, we need to scan the components to check the security issues.
When we run scan on openvidu’s docker images, around 300 vulnerabilities are there.
With so many vulnerabilities we are not able to proceed further.
Please suggest how to remove the vulnerabilities or is there any plan to work on these.
Added some issues for reference:

CVE-2020-36130	6.5	aom:1.0.0.errata1-3build1	MEDIUM	Open
CVE-2021-30473	9.8	aom:1.0.0.errata1-3build1	MEDIUM	Open
CVE-2020-36135	6.5	aom:1.0.0.errata1-3build1	MEDIUM	Open
CVE-2020-36129	8.8	aom:1.0.0.errata1-3build1	MEDIUM	Open
CVE-2021-30475	9.8	aom:1.0.0.errata1-3build1	MEDIUM	Open

[cruizba]

What is the image involving those CVEs? openvidu/openvidu-recording ?

[poojakamra]

@poojakamra

how to remove the vulnerabilities or is there any plan to work on these.
Added some issues for reference:

Vulnerabilties are there in all the components. These vulnerabilities are in “Kurento-media-server”.

[cruizba]

I would start migrating to v3, which is using more up-to-date technologies (Pion, mediasoup in PRO Tier, etc).

[poojakamra]

Hi,

We have done migration to Openvidu v3. In that also the issues are there. To scan the components we are using Amazon ECR image scanning which internally uses Clair to scan images.

Component	Critical	High	Medium	Low	Informational	Undefined	Total
bitnami_minio	1	2	6	3	37	13	62
bitnami/mongodb	1	2	6	3	37	13	62
curlimages/curl			4			4	8
livekit/ingress		2	84	50	7	0	143
openvidu-dashboard			3	12	3		18
openvidu-server						1	1
redis	1	1	4	2	25	5	38
openvidu-caddy-local			4			4	8
	3	7	111	70	109	40	340

Most of the vulnerabilties are there in third party component ingress.

[cruizba]

Based on my experience, achieving zero vulnerabilities is nearly impossible. Even the most up-to-date components often have dependencies that introduce vulnerabilities. These vulnerabilities frequently originate from dependencies related to the container OS or the software itself, but are not involved with the component itself.

A CVE doesn’t imply having an actual vulnerability, and often is even a false positive (given how most distributions handle versioning/security updates in stable releases). The key factor to focus on is reproducibility. For instance, take a look to the official MongoDB linux images on Docker Hub, which often have multiple up-to-date versions containing vulnerabilities (https://hub.docker.com/_/mongo/tags). All of these vulnerabilities are not reproducible.

We will make our best effort to minimize vulnerabilities by using the most up-to-date images in future releases.

We are still making progress in the beta, so expect updates in the future.

[poojakamra]

Thanks for the response cruizba.
We are less concerned about low, information and undefined vulnerabilties. But Critical, high and Medium needs to be resolved as per our quality team.
Will it be possible to resolve these vulnerabilities?

[cruizba]

We will focus on keeping images with its latest OS version per release, and update application dependencies.

[poojakamra]

Hi, we have taken code of openvidu 2.30 version and upgraded the dependencies in the code and compiled it.
All the vulnerabilities got resolved.
Also we built docker images of all components and upgraded the OS versions as well.
But when we run the openvidu server and make composed recording, whitelabel error page is coming in the mp4 file.
Individual recordings are working fine,
Please help to resolve it as we are stuck with it.

[pabloFuente]

You need to compile the OpenVidu Dashboard before packaging openvidu-server: openvidu/openvidu-server/src/dashboard at v2 · OpenVidu/openvidu · GitHub

cd openvidu/openvidu-server/src/dashboard
npm install
npm run build-prod

This will build and copy the OpenVidu Dashboard into the required path at openvidu-server. After that, build openvidu-server as normal and the COMPOSED recording layout will be available.

PD: if your dependency updates have resolved any secuirty vulnerabilities reported on OpenVidu 2.30.0, could you please open a Pull Request with those changes to review them and accept them into v2 branch? That would be awesome!

[poojakamra]

@pabloFuente while running second command “npm run build-prod” we are getting error. Screenshot attached for the same.

Please see once.

[poojakamra]

Command worked perfectly in Linux machine. I will compile jar again and will let you know if it works.
Thanks for the help.

[poojakamra]

Hi, after creating docker image with the compiled jar, recording is not getting started.
Getting error : [ERROR] 2024-09-17 12:55:29,970 [http-nio-0.0.0.0-5443-exec-7] org.apache.catalina.core.ContainerBase.[Tomcat].[localhost].[/].[dispatcherServlet] - Servlet.service() for servlet [dispatcherServlet] in context with path threw exception [Request processing failed; nested exception is com.github.dockerjava.api.exception.NotFoundException: Status 404: No such container: 946febc5854e78e84488023b155d6c8c7fd9ec825dc21929bde5afd754a14769] with root cause
openvidu-openvidu-server-1 | com.github.dockerjava.api.exception.NotFoundException: Status 404: No such container: 946febc5854e78e84488023b155d6c8c7fd9ec825dc21929bde5afd754a14769

Please help.

[poojakamra]

Sure will merge the changes after testing the functionality. Or should i merge without testing the functionalities?

[pabloFuente]

It seems that your openvidu-server is not able find the openvidu-recording image in your host. openvidu-server tries to search and download image openvidu-recording on start up. Does it have access to DockerHub?

[pabloFuente]

@poojakamra

Sure will merge the changes after testing the functionality. Or should i merge without testing the functionalities?

If these are simply changes to dependency versions, you can do it right away. We will review them ASAP.

[poojakamra]

No. System does not have internet. We manually deployed all docker images. Issue got resolved after building openvidu-server jar on linux machine instead of windows machine,

[poojakamra]

The change is there in pom.xml file only for openvidu-server.
Added following dependencies:

	<!-- https://mvnrepository.com/artifact/org.springframework/spring-web -->
	<dependency>
	    <groupId>org.springframework</groupId>
	    <artifactId>spring-web</artifactId>
	    <version>5.3.39</version>
	</dependency>

	<dependency>
	    <groupId>org.yaml</groupId>
	    <artifactId>snakeyaml</artifactId>
	    <version>2.0</version>
	</dependency>
	
	<dependency>
	    <groupId>ch.qos.logback</groupId>
	    <artifactId>logback-core</artifactId>
	    <version>1.2.13</version>
	</dependency>
	
	<dependency>
	    <groupId>ch.qos.logback</groupId>
	    <artifactId>logback-classic</artifactId>
	    <version>1.2.13</version>
	    <scope>test</scope>
	</dependency>
	
	<dependency>
	    <groupId>com.google.guava</groupId>
	    <artifactId>guava</artifactId>
	    <version>32.1.2-jre</version>
	</dependency>
	
	<dependency>
	    <groupId>org.springframework.security</groupId>
	    <artifactId>spring-security-core</artifactId>
	    <version>5.7.12</version>
	</dependency>
	
	<dependency>
	    <groupId>org.springframework.security</groupId>
	    <artifactId>spring-security-crypto</artifactId>
	    <version>5.7.12</version>
	</dependency>
	
	<dependency>
	    <groupId>org.springframework.security</groupId>
	    <artifactId>spring-security-config</artifactId>
	    <version>5.7.12</version>
	</dependency>
	
	<dependency>
	    <groupId>org.springframework.security</groupId>
	    <artifactId>spring-security-web</artifactId>
	    <version>5.7.12</version>
	</dependency>
	
	<dependency>
	    <groupId>org.eclipse.jetty.websocket</groupId>
	    <artifactId>websocket-client</artifactId>
	    <version>9.4.56.v20240826</version>
	</dependency>
	
	<dependency>
	    <groupId>org.eclipse.jetty.websocket</groupId>
	    <artifactId>websocket-common</artifactId>
	    <version>9.4.56.v20240826</version>
	</dependency>
	
	<dependency>
	    <groupId>org.springframework</groupId>
	    <artifactId>spring-expression</artifactId>
	    <version>5.3.39</version>
	</dependency>
	
	<dependency>
	    <groupId>org.eclipse.jetty</groupId>
	    <artifactId>jetty-io</artifactId>
	    <version>9.4.56.v20240826</version>
	</dependency>

	<dependency>
	    <groupId>org.apache.commons</groupId>
	    <artifactId>commons-compress</artifactId>
	    <version>1.27.1</version>
	</dependency>
	
	<dependency>
	    <groupId>org.codehaus.janino</groupId>
	    <artifactId>commons-compiler</artifactId>
	    <version>3.1.12</version>
	</dependency>
	
	<dependency>
	    <groupId>commons-io</groupId>
	    <artifactId>commons-io</artifactId>
	    <version>2.16.1</version>
	</dependency>
	
	<dependency>
	    <groupId>io.netty</groupId>
	    <artifactId>netty-codec-http</artifactId>
	    <version>4.1.113.Final</version>
	</dependency>
	
	<dependency>
	    <groupId>io.netty</groupId>
	    <artifactId>netty-codec-socks</artifactId>
	    <version>4.1.113.Final</version>
	</dependency>
	
	<dependency>
	    <groupId>io.netty</groupId>
	    <artifactId>netty-handler-proxy</artifactId>
	    <version>4.1.113.Final</version>
	</dependency>
	

	<dependency>
	    <groupId>com.github.docker-java</groupId>
	    <artifactId>docker-java</artifactId>
	    <version>3.4.0</version>
	</dependency>

	<dependency>
	    <groupId>com.fasterxml.jackson.core</groupId>
	    <artifactId>jackson-databind</artifactId>
	    <version>2.17.2</version>
	</dependency>
	
	<dependency>
	    <groupId>org.codehaus.janino</groupId>
	    <artifactId>janino</artifactId>
	    <version>3.1.12</version>
	</dependency>
			
	<dependency>
	    <groupId>org.slf4j</groupId>
	    <artifactId>slf4j-simple</artifactId>
	    <version>1.7.36</version>
	</dependency>

After that all vulnerabilities got resolved except depndency related to spring 2.x.

Thanks for the support.