[jira] [Created] (YUNIKORN-1536) Avoid spurious Twistlock flags when scanning web package

["Sahib Aulakh (Jira)" <ji...@apache.org>]

Sahib Aulakh created YUNIKORN-1536:
--------------------------------------

             Summary: Avoid spurious Twistlock flags when scanning web package
                 Key: YUNIKORN-1536
                 URL: https://issues.apache.org/jira/browse/YUNIKORN-1536
             Project: Apache YuniKorn
          Issue Type: Improvement
          Components: webapp
            Reporter: Sahib Aulakh
             Fix For: 1.1.0


Twistlock raises spurious CRITICAL issues when scanning web-1.1.0. Potential amelioration to the issue is suggested in the discussion below by Craig.

 

Twistlock scan of Yunikorn

This pertains to the CRITICAL issues surfaced by Twistlock on the YuniKorn image.
h3. Question on Slack Channel (https://yunikornworkspace.slack.com/archives/CLNUW68MU/p1673369962230479)

For a client in the financial industry, in order to use Yunikorn, we have to pass the security scans from Twistlock (https://www.cloudfoundry.org/the-foundry/twistlock/). Twistlock is currently raising the following issues at CRITICAL level for the following images:

admission-1.1.0, scheduler-1.1.0

================================

(1) https://nvd.nist.gov/vuln/detail/CVE-2022-37434 (zlib)

(2) https://nvd.nist.gov/vuln/detail/CVE-2022-2068 (libssl1.1, libcrypto1.1)

 

web-1.1.0

=========

(3) https://nvd.nist.gov/vuln/detail/CVE-2022-42915 (libcurl, curl)

(4) https://nvd.nist.gov/vuln/detail/CVE-2022-32221 (libcurl, curl)

 

I need some advice as to how to make progress here:

(a) For (1), is it sufficent to say that the API call inflateGetHeader is not being made in YK code, so this issue is not relevant? Is it sufficient to search for "inflateGetHeader" in YK sources to verify that the call is not being made anywhere by YK code? I am assuming that the C programming API is not being renamed somewhere.

(b) For (2), is it sufficent to say that the offending shell command "c_rehash" is not being exercised anywhere in the YK code base?

(c) For (3), the offending command is curl before 7.86.0. Is it sufficient to say that curl is not being exercised in the manner indicated in the CVE?

(d) For (4), again can we rule out this scenario for Yunikorn?

(e) Fixes for all these issues exist in later versions of zlib, libssl, libcrypto, libcurl and curl. How much work is involved in switching to these later versions of the libraries? I can supply the additional details here.

 

(f) Finally, if I were to undertake this task and create git pull request, can someone from YK team work with me and provide some basic guidance? I have extensive programming experience but am new to Go.
h3. Response from Craig Condit from YuniKorn team

For #1 and #2 vulnerabilities, YuniKorn is not affected. The yunikorn scheduler and admission controller components are the only things that run within the generated containers, and both are static go executables which do not make use of the affected libraries. It's likely they are being triggered due to libraries / binaries included in the base alpine images. For #3 and #4, the web image uses nginx internally, which does not use curl / libcur.

To prevent issues like #1/#2 in the future, we should probably look at moving the scheduler images to use the scratch (basically empty) base image. This would limit any potential surface area to the YK binary itself. For #3/#4, we need nginx, so we'll need to keep updating to newer nginx-alpine images.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@yunikorn.apache.org
For additional commands, e-mail: issues-help@yunikorn.apache.org