Flatcar Mayday evaluation

[LolloneS]

We rely on Flatcar as OS for our Kubernetes product.

Flatcar comes with mayday (https://github.com/flatcar/mayday) installed by default. It recently turned out to be vulnerable to a few CVEs.

Some questions here:

• do we use it?
• is it possible to somehow disable it, especially if we don't use it?

[weseven]

Do we have a reference for these CVEs?
I couldn't find anything specific for that tool

[LolloneS]

I'll provide them ASAP :) in the meantime, can we evaluate if we need it/can disable it?

[weseven]

As far as I know, we don't really use it: it's a tool used to collect diagnostics when there's something wrong in the system to later analyze them/send them to support or whatever (basically what sosreport is in RedHat world).
It has no service, it's only executed on user demand, so unless there's some privilege escalation possible through the tool I think it is mostly harmless (it does not collect sensitive data).

I was asking because there's a class of trojans which has the same name (Mayday), and since I couldn't find any CVE related to the tool I was wondering if the security scanner tripped over the homonymy.

If it turns out there is a significant vulnerability of course we can remove it from the system when we build our flatcar image.

[weseven]

Adidas added the issue reference, it's an outdated go dependency that might cause a crash when parsing malformed HTML (https://nvd.nist.gov/vuln/detail/CVE-2018-17848):

[weseven]

I've opened a PR to the flatcar mayday upstream: flatcar/mayday#12

Edit: PR has already been merged, hopefully they will make a new version and include it in the next flatcar release 🚀

[weseven]

The PR was merged, and the dev made a couple of other PRs removing obsolete functionality and other vulnerable dependencies.
Newer flatcar versions most likely will have the updated, non vulnerable mayday (progress here: flatcar/scripts#2247).

[yulianedyalkova]

We also need to ensure that the following CVE has been fixed with our change:

Also that we have a flatcar version including those changes in CAPI.

Context https://github.com/giantswarm/adidas/issues/1297.

[AverageMarcus]

Can I just check - what's the actual concern here? Unless I'm mistaken mayday is a CLI on the host node. If bad actors already have access to it then they've already won.

If we're not actively using it for anything (and I'm not aware that we are) then I don't think we have anything to worry about. Yes it's not ideal having the CVE notification but if it's not exploitable then its not a problem 🤷

[yulianedyalkova]

If we can solve the scan alert that would be ideal and since we already have a fix for a CVE with a bigger number in the same dependency, I'm hoping this one was resolved in there too with Daniel's change. So let's check if that's the case and in which flatcar version.

If it's not resolved, we need to evaluate the potential risk and communicate with the customer if a fix is really required.

[puja108]

any updates on this?

[Gacko]

So, Daniel proposed a fix in flatcar/mayday#12. This got merged. A day later they just removed the whole dependency in flatcar/mayday#13.

I then looked up which version of mayday is currently being used in Flatcar, turns out they recently bumped it in flatcar/scripts#2247 and fortunately the commit used by this PR also includes the previously mentioned fix.

The first Flatcar release I could find including this PR is 3975.2.1: https://github.com/flatcar/scripts/blob/stable-3975.2.1/sdk_container/src/third_party/coreos-overlay/app-admin/mayday/mayday-9999.ebuild

Flatcar 3975.2.1 is used in CAPA v29.2.0, CAPA v29.3.0, CAPZ v29.1.0 & CAPZ v29.2.0:

% grep 3975.2.1 */*/release.yaml --before-context 1
azure/v29.1.0/release.yaml-  - name: flatcar
azure/v29.1.0/release.yaml:    version: 3975.2.1
--
azure/v29.2.0/release.yaml-  - name: flatcar
azure/v29.2.0/release.yaml:    version: 3975.2.1
--
capa/v29.2.0/release.yaml-  - name: flatcar
capa/v29.2.0/release.yaml:    version: 3975.2.1
--
capa/v29.3.0/release.yaml-  - name: flatcar
capa/v29.3.0/release.yaml:    version: 3975.2.1

According to Dani they are fine as long as we include it in one of the releases on their journey from v20 to v29:

Priority

For the next upgrade. After capa migration, I think there are plans to fast forward from v20 to v29. Including it on this path would be ok. Not urgent, but cannot be forgotten.