Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE List in birt 4.9.0 #965

Closed
wilfried-deguil opened this issue May 10, 2022 · 13 comments
Closed

CVE List in birt 4.9.0 #965

wilfried-deguil opened this issue May 10, 2022 · 13 comments

Comments

@wilfried-deguil
Copy link

Hi,

I integrate Birt 4.9 in my java project (copy of ReportEngine/lib libraries under myproject/WEB-INF/lib). I use the owasp dependency-check-maven plugin to check (CVE) all the libraries of the project.
The report outputs a number of CVEs related to the BIRT libraries :

CVSSv3 > 9.0
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-1832 (org.apache.derby_10.11.1.1_v201605202053.jar)
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-7657 (org.eclipse.jetty.servlet-api_4.0.6.jar)
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-7658 (org.eclipse.jetty.servlet-api_4.0.6.jar)

CVSSv3 > 7.0
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-7791 (org.apache.batik.i18n_1.14.0.v20210324-0332.jar)

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-41033 (org.eclipse.core.contenttype_3.8.100.v20210910-0640.jar org.eclipse.core.filesystem_1.9.300.v20220121-1426.jar org.eclipse.core.jobs_3.12.100.v20220120-1329.jar org.eclipse.core.runtime_3.24.100.v20220211-2001.jar org.eclipse.equinox.app_1.6.100.v20211021-1418.jar org.eclipse.equinox.common_3.16.0.v20220211-2322.jar org.eclipse.equinox.frameworkadmin.equinox_1.2.100.v20210703-1540.jar org.eclipse.equinox.frameworkadmin_2.2.0.v20210315-2042.jar org.eclipse.equinox.preferences_3.9.100.v20211021-1418.jar org.eclipse.equinox.registry_3.11.100.v20211021-1418.jar org.eclipse.equinox.security_1.3.900.v20220108-1321.jar org.eclipse.equinox.simpleconfigurator_1.4.0.v20210315-2228.jar org.eclipse.osgi_3.17.200.v20220215-2237.jar org.eclipse.update.configurator_3.4.800.v20210415-1314.jar)

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-5045 (org.eclipse.jetty.servlet-api_4.0.6.jar)
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-7656 (org.eclipse.jetty.servlet-api_4.0.6.jar)
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-9735 (org.eclipse.jetty.servlet-api_4.0.6.jar)
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-24785 (primefaces-11.0.0.jar: moment.js)
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-27216 (org.eclipse.jetty.servlet-api_4.0.6.jar)

CVSSv3 > 5.0
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-1313 (org.apache.derby_10.11.1.1_v201605202053.jar)

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-26336 (org.apache.poi.ooxml.schemas_4.1.1.v20200922-2105.jar
org.apache.poi_4.1.1.v20200604-1524.jar)

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-28169 (org.eclipse.jetty.servlet-api_4.0.6.jar)
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-5046 (org.eclipse.jetty.servlet-api_4.0.6.jar)

CVSSv2 ou CVSSv3 < 5.0
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2008-7271 (org.bouncycastle.bcprov_1.70.0.v20220105-1522.jar)
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-4647 (org.bouncycastle.bcprov_1.70.0.v20220105-1522.jar)
NVD - CVE-2020-8908 (nist.gov) (org.eclipse.birt.runtime_4.9.0-20220315.jar)

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2005-4849 (org.eclipse.datatools.connectivity.apache.derby.dbdefinition_1.2.101.201811012051.jar org.eclipse.datatools.connectivity.apache.derby_1.2.101.201811012051.jar)

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-4269 (org.eclipse.datatools.connectivity.apache.derby.dbdefinition_1.2.101.201811012051.jar org.eclipse.datatools.connectivity.apache.derby_1.2.101.201811012051.jar)

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-34428 (org.eclipse.jetty.servlet-api_4.0.6.jar)

How to fix all CVE ?

Thanks.

@hvbtup
Copy link
Contributor

hvbtup commented May 10, 2022

Note: This is my personal opinion, I don't speak for the developer community.

Currently, we don't have the ressources to keep up with CVEs. Just keep in mind that the team is a small team of volunteers.
If these security issues worry you, you are invited to help with a PR which updates some of the libraries.

OTOH just because a library has vulnerabilities, this doesn't necessarily mean that your product is affected.

For example, take Batik. BIRT uses Batik for SVG rendering.
If your reports don't contain SVGs, or if you can control the SVGs used in your reports (don't allow anyone to upload SVGs from untrusted sources), then you can ignore the Batik vulnerabilities.

And if you integrate BIRT in your application and just don't use the web servlet at all, you can ignore the Jetty vulnerabilities.

But of course: If libraries contain known vulnerabilities, you have to very carefully think about if your program may be affected by one of them.

In an ideal world, someone would check for vulnerabilities every few days and update the corresponding libraries as soon as a fix is available.

Unfortunately, this often means more than just replacing a few JARs and updating version numbers. In fact this is a very time-consuming, boring and frustrating task. It may well be a full-time job for a single developer.

So nobody wants to do this.
And it seems nobody wants to pay others for this work.
So this will probably never happen...

...with two exceptions:

  • If a new library version contains bug fixes which affect the functionality (not the security), chances are that this version will be used in a newer release (of BIRT, or take many other open source projects).
  • If a new major release (of BIRT) is prepared, chances are that many of the used libraries are checked for a newer version. But probably not 4 times in a year.

@SteveSchafer-Innovent
Copy link
Contributor

Since publishing 4.9 on maven, I've been getting emails from Sonatype Lift listing a bunch of vulnerabilities that it detected in the code. I don't know if this URL will work for anyone, but here it is:

https://sbom.lift.sonatype.com/report/T1-a0368c8f29fdaa555824-7ff7f10204ce21-1651529809-f35aa4ac38be4cfba79ccae0510d345d

Also they offer to install Sonatype Lift in the github repository for free.

https://github.com/marketplace/muse-dev/plan/MLP_kgDNGN8#pricing-and-setup

I'm trying it on one of my personal repos. It want's read permission to emails. Given Henning's comments this is probably overkill but I thought I'd mention it.

@hvbtup
Copy link
Contributor

hvbtup commented May 13, 2022

Well, please give it a try. It sounds useful.
From what it looks like, it also looks for possible errors in the code.

BTW Do we have Dependabot configured for the GH repo?
Personally, I never used any of these tools, but AFAIK Dependabot can even create PRs to bump vulnerable libraries to a newer release (see https://docs.github.com/en/code-security/dependabot/dependabot-alerts/about-dependabot-alerts):

For repositories where Dependabot security updates are enabled, the alert may also contain a link to a pull request to update the manifest or lock file to the minimum version that resolves the vulnerability

If one (or a combination) of these tools can eliminate a lot of the boring work - in particular, if the Dependabot PRs actually work - that would really help a lot.

@SteveSchafer-Innovent
Copy link
Contributor

SteveSchafer-Innovent commented May 16, 2022

As far as I can tell Dependabot is enabled.

https://github.com/eclipse/birt/security/dependabot

I don't have access to the settings tab so I can't tell how it's configured.

@SteveSchafer-Innovent
Copy link
Contributor

It appears that, as an eclipse committer, I can install Sonatype Lift on the BIRT repository. It wants these permissions:

Read access to members, metadata, organization administration, organization plan, and organization projects

Read and write access to checks, code, commit statuses, issues, pull requests, and security events

And read access to my github emails.

I'd like @wimjongman to let me know if this is acceptable before I do it.

@wimjongman
Copy link
Contributor

Hi Steve. I think this is a call for the project lead, @TheLaserNinja

@TheLaserNinja
Copy link
Contributor

TheLaserNinja commented May 18, 2022

I'm a little hesitant to give a 3rd party organization write access to code given recent events with source code poisoning for personal messaging, and since we typically have a vetting process for comitters. However, I've used tools like this in the past, in particular SonarQube. I haven't used Sonatype Lift, so I'd be interested to hear your experience with it so far.

@SteveSchafer-Innovent
Copy link
Contributor

That's understandable. I have run it on my BIRT fork and it produces a huge report of vulnerabilities and code suggestions for java, javascript, and shell scripts, that I"ve noticed. But the question is what does it do when it's installed as an app and a pull request occurs. I'll let you know once I've had a chance to run a test.

@wimjongman
Copy link
Contributor

wimjongman commented May 18, 2022

Maybe @waynebeaton can help. Wayne, we are thinking of using Sonatype Lift on our repo. Is this allowed?

It appears that, as an eclipse committer, I can install Sonatype Lift on the BIRT repository. It wants these permissions:

Read access to members, metadata, organization administration, organization plan, and organization projects

Read and write access to checks, code, commit statuses, issues, pull requests, and security events

And read access to my github emails.

@waynebeaton
Copy link
Contributor

Open an issue against Eclipse Help Desk and the IT team will help you sort it out. They're the permissions experts.

FWIW, even with automatic detection of vulnerabilities and pull requests to fix versions in pom.xml files (like what Dependabot does) still requires sometimes significant committer investment to ensure that the fix doesn't break something.

Updating these old and vulnerable third-party libraries is an excellent opportunity for adopters to begin their contribution journey.

@SteveSchafer-Innovent
Copy link
Contributor

We don't want this tool to be automatically fixing anything. Even automatically producing reports is probably overkill now that I think about it. It would make sense if there are only a few issues and you can stay on top of them, but with hundreds of issues and sparse volunteers to deal with them, the report's going to be ignored. It's probably better to produce the reports on-demand, which anyone can do based on a fork. So I'm going to back off on recommending that we install this.

@SteveSchafer-Innovent
Copy link
Contributor

SteveSchafer-Innovent commented May 19, 2022

I'm inclined to work on these because some companies require vulnerabilities to be fixed before they can use the product, and vulnerabilities just annoy me. I will create separate issues for each one that I work on. If anyone would like to suggest priorities, feel free.

@wimjongman
Copy link
Contributor

wimjongman commented May 20, 2022 via email

@eclipse-birt eclipse-birt locked and limited conversation to collaborators Sep 27, 2022
@wimjongman wimjongman converted this issue into discussion #1067 Sep 27, 2022

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants