Generator-jhipster: CVE-2019-16303 failing with latest JHipster 6.9.1

[Victor-bln]

Overview of the issue

A docker image (created with the integrated Jib library) of a newly created application with the latest JHipster version 6.9.1 is showing a critical vulnerability that can't be solved: CVE-2019-16303.

We firstly saw this vulnerability when we try to deploy the application to a stage environment with harbor. Then we also run a dependecy check using the OWASP plugin (https://jeremylong.github.io/DependencyCheck/dependency-check-maven/index.html) and the same vulnerability was shown.

Motivation for or Use Case

We shouldn't deploy such an application on a production environment with a critical vulnerability.

Reproduce the error

Just creating a new application with the latest version (selected options follow) and running a dependency check of the docker image.

Related issues

It was already reported and solution was stated here: https://www.jhipster.tech/2019/09/13/jhipster-release-6.3.0.html.

Suggest a Fix

According to your website this issue should have been solved after JHipster version 6.2.0 and I checked the generated class and it is already using SecureRandom.

But could it be that the vulnerabilities register has the wrong information?

JHipster Version(s)

Latest available version 6.9.1

JHipster configuration

INFO! Using JHipster version installed locally in current project's node_modules
INFO! Executing jhipster:info
INFO! Options: from-cli: true
Welcome to the JHipster Information Sub-Generator

JHipster Version(s)

[email protected] C:\testJhipster
`-- [email protected]

##### **JHipster configuration, a `.yo-rc.json` file generated in the root folder**

.yo-rc.json file

{
  "generator-jhipster": {
    "promptValues": {
      "packageName": "com.mycompany.myapp",
      "nativeLanguage": "de"
    },
    "jhipsterVersion": "6.9.1",
    "applicationType": "monolith",
    "baseName": "testJhipster",
    "packageName": "com.mycompany.myapp",
    "packageFolder": "com/mycompany/myapp",
    "serverPort": "8080",
    "authenticationType": "jwt",
    "cacheProvider": "ehcache",
    "enableHibernateCache": false,
    "websocket": false,
    "databaseType": "sql",
    "devDatabaseType": "h2Disk",
    "prodDatabaseType": "mysql",
    "searchEngine": false,
    "messageBroker": false,
    "serviceDiscoveryType": false,
    "buildTool": "maven",
    "enableSwaggerCodegen": false,
    "jwtSecretKey": "YourJWTSecretKeyWasReplacedByThisMeaninglessTextByTheJHipsterInfoCommandForObviousSecurityReasons",
    "embeddableLaunchScript": false,
    "useSass": true,
    "clientPackageManager": "npm",
    "clientFramework": "react",
    "clientTheme": "flatly",
    "clientThemeVariant": "primary",
    "creationTimestamp": 1591108034543,
    "testFrameworks": [],
    "jhiPrefix": "jhi",
    "entitySuffix": "",
    "dtoSuffix": "DTO",
    "otherModules": [],
    "enableTranslation": true,
    "nativeLanguage": "de",
    "languages": ["de"],
    "blueprints": []
  }
}

JDL for the Entity configuration(s) entityName.json files generated in the .jhipster directory

JDL entity definitions

Environment and Tools

java version "1.8.0_221"
Java(TM) SE Runtime Environment (build 1.8.0_221-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.221-b11, mixed mode)

git version 2.24.1.windows.2

node: v12.17.0

npm: 6.14.4

Docker version 19.03.8, build afacb8b

docker-compose version 1.25.5, build 8a1c60f6

INFO! Congratulations, JHipster execution is complete!

Entity configuration(s) entityName.json files generated in the .jhipster directory

No entities created yet.

Browsers and Operating System

Not related to any browser

• [X] Checking this box is mandatory (this is just to show you read everything)

[atomfrede]

As you said it is fixed. Not sure where the plugin gets the vulnerability information from. I checked snyk's database recently the issue you mention contains the correct version information.

[Victor-bln]

First of all thanks for the quick reply!

The OWASP magen plugin downloads and processes the data from the National Vulnerability Database (NVD) hosted by NIST: https://nvd.nist.gov.

But we also have the issue when deploying with Harbor (also accessing the NVD) and even with the anchore engine

[atomfrede]

It looks like the information is wrong as the jhipster lib is not relased in log step with the main generator. At least from looking it at it looks like they are referring to jhipster lib > 6.2.0, while we the latest version is 3.8.0 (because of different version schema). Not sure how to proceed here.

https://nvd.nist.gov/vuln/detail/CVE-2019-16303#VulnChangeHistorySection

[Victor-bln]

That could be it. Latest release of the JHipster lib is 3.8.0 and of JHipster generator is 6.9.1 right?

The vulnerability CVE-2019-16303 shoud be linked to the version number of the JHipster lib and and not to the generator version. That is why this vulnerability will still come up until a lib version of 6.3.0 is released.

I think the corresponding version of the JHipster lib used by the latest JHipster generator version still facing this vulnerability should be added to the NVD. I think this version of the JHipster was 3.0.3?

[atomfrede]

I think it should be linked to generator-jhipster instead of the lib. The vulnerable RandomUtil class was generated and migrated to the lib in december last year (using SecureRandom directly). So imho the jhipster lib has never been vulnerable.
Looking at snyk they reference generator-jhipster, like we do in the github advisory (which is correct I would say)

[Victor-bln]

I understand but the vulnerabilities check is run over the libraries added to the application and there is only 1 added through the pom: jhipster-framework.

There is no generator-jhipster lib added through pom like there is an npm generator-package.

[atomfrede]

And thats wrong as the vulnerable package is a npm package and not a java package.

[Victor-bln]

Is it maybe related to the fact that the CPEs are named such as
cpe:2.3:a:jhipster:jhipster:[version]:*:*:*:*:*:*:*
...and maybe should be
cpe:2.3:a:jhipster:jhipster-generator:[version]:*:*:*:*:*:*:* ?

[atomfrede]

yes, exactly. It is just wrong, as the jhipster:jhipster was never vulnerable. It was the main generator, under certain conditions/options.

[Victor-bln]

So you just have to "correct" the cpe names and that would be it?

[atomfrede]

As I don't know how to do that or who is allowed to do that, I would say not 'just' but I would expect it to work correctly afterwards.

[Victor-bln]

As we created the application with the latest JHispter generator we will add for now this CVE to the whitelist and await your response.

So far thanks a lot for your quick support and good day!

[atomfrede]

You are welcome. @jdubois Do you have an idea how handle the wrong artifact definition?

[jdubois]

Thanks @atomfrede @Victor-bln ! I can confirm this is an old bug that was fixed.
Now I have no idea how to fix this, so this might take some time.

[jdubois]

OK so here is the issue:

• The CVE is at https://github.com/jhipster/generator-jhipster/security/advisories/GHSA-mwp6-j9wf-968c and indeed that's for JHipster 6.3.0
• I have no idea how it happened, but indeed that's very confusing for an external person that we have an NPM package and a Maven package. So we got the Maven packaged tagged with the CVE.
• I didn't pay attention to this, but our version numbers for our Maven releases are not the same as the NPM releases. The Maven packages are at version 3.6.0 and the NPM packages at 6.9.1.

-> as a result, our Maven packages are tagged with the CVE, which is wrong. And I confirm the issue is fixed, it's the CVE that is wrong.

I don't think we can edit a CVE once it's published, at least it's not easy.

But then, it would make more sense to have the same versions for the NPM and the Maven libraries. There could be some differences for patch releases, but for major and even minor releases, they could have the same version numbers. That would be more consistent and limit that kind of questions.

So my suggestion (cc @pascalgrimaud @deepu105 ) is to upgrade our Maven packages version to match the NPM packages version. This will solve this issue, but it will probably annoy a bit our users (they will have a sudden version bump, which might worry them).

WDYT?

[deepu105]

I agree to align versions but with Jhipster 7 onwards would be better

[pascalgrimaud]

Agree, we can align versions for v7

[mraible]

How do we fix this? Are there actionable issues we can work on to make this happen?

[DanielFran]

This should be fixed since we will create now a new dependency for jhipster lib.

@pascalgrimaud Can we close it?

[pascalgrimaud]

@DanielFran : yes, we can close this