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

["Wilfred Spiegelenburg (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/YUNIKORN-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17680464#comment-17680464 ] 

Wilfred Spiegelenburg commented on YUNIKORN-1536:
-------------------------------------------------

All issues are linked to libraries that are part of the base image layer. One thing that you can do is build your own docker images from the source code we deliver. The docker images are convenience images only. Everything you need to create them is in our source code release.

The 1.1.0 release used the most recent alpine images when it was build. It was build a number of months ago. A current build of the image using {{make image}} would use the current latest alpine image. That might be enough to get you a fix. Otherwise you can change the base image to for instance a RedHat UBI image that has a fix for the issue. You are free to do so. It would still give you the same YuniKorn version just on an updated base OS image.

For the project there is one solution that we could use for the scheduler and the admission controller: use scratch as the base which reduces the footprint of what is used even further.

That does not work for the web application as we need something to serve the application through. That means we need something simple like a nginx image always.

> 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
>            Priority: Minor
>             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