Skip to content
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

OPERA security vulnerabilities #191

Open
popenc opened this issue May 9, 2022 · 7 comments
Open

OPERA security vulnerabilities #191

popenc opened this issue May 9, 2022 · 7 comments
Labels
dev Deployed on a dev server staging Deployed on EPA AWS staging vulnerability security vulnerabilities

Comments

@popenc
Copy link
Collaborator

popenc commented May 9, 2022

Upgraded to OPERA v2.8, which still throws high to critical level security vulnerabilities when scanning the Docker image with Prisma (cts_kube repo).

Update: new version v2.8.2 is supposed to have security updates. Update to v2.8.2 and test the Prisma scans.

@popenc
Copy link
Collaborator Author

popenc commented Jun 1, 2022

Will try to remove log4j from dependencies and see how that goes.

@popenc popenc added the vulnerability security vulnerabilities label Jun 8, 2022
@popenc
Copy link
Collaborator Author

popenc commented Jun 23, 2022

  1. com.fasterxml.jackson.core_jackson-databind
  2. Java
  3. org.apache.xmlgraphics_xmlgraphics-commons
  4. org.apache.cxf_cxf-core
  5. commons-beanutils_commons-beanutils
  6. log4j_log4j

@popenc
Copy link
Collaborator Author

popenc commented Jun 24, 2022

Updated to OPERA v2.8.4 (Python module). Looks like the above CVEs remain. I'm now going through to see where the above libraries are located.

@popenc
Copy link
Collaborator Author

popenc commented Jul 13, 2022

Added removal of (unused) log4j in Docker image. Should be able to use a fresh build and enable OPERAWS on servers again.

@popenc
Copy link
Collaborator Author

popenc commented Jul 13, 2022

This is now running on GDIT/ceam dev server. I'm getting data back from the example API request, although it took a really long time. Also, since the ceam dev server cannot reach CCTE from outside the EPA network, it's not able to get DTXSID and therefore isn't getting data from the DB, so it always runs the model.

@popenc popenc added dev Deployed on a dev server staging Deployed on EPA AWS staging labels Jul 27, 2022
@popenc
Copy link
Collaborator Author

popenc commented Jul 27, 2022

log4j resolutions added to dev and epa staging.

NOTE: If operaws CVEs are still being flagged in Prisma via the Gitlab pipeline, this along with bt_api can be deployed on a separate backend server that goes through the routine manual app scans, which do pass.

@popenc
Copy link
Collaborator Author

popenc commented Nov 14, 2022

Prisma scans working again and added them back to the Gitlab pipeline. It looks like updating to v2.9.1 has resolved the log4j vulnerability but all the rest remain.

15 critical, 39 high, 13 medium, and 18 low.

Main offending libraries:

  • com.fasterxml.jackson.core_jackson-databind (v2.9.8, fixed in v2.9.10)
    • This has the majority of vulnerabilities.
  • java v1.8.0_202 (no suggested fix version listed)
  • org.apache.cxf_cxf-core (v3.2.14, fixed in 3.4.3 and 3.3.10)
  • commons-beanutils_commons-beanutils (v1.8.3, no suggested fix version listed)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dev Deployed on a dev server staging Deployed on EPA AWS staging vulnerability security vulnerabilities
Projects
None yet
Development

No branches or pull requests

1 participant