formidable, koa-body and my rant about CVE---
date: Aug 19, 2022
This is a recent thing that happened to me around a vulnerability that caused incompatibility in the project in my current company, and my thought (rant) on CVEs.
CVE-2022-29622. This is one of the vulnerabilities reported by the customer after rounds of sending fixed versions. After my initial investigation, this is a vulnerability that affects a nodeJS package called
formidable. A quick
yarn why revealed that this is used by
koa-body, a package that our project directly used. It is quickly revealed that
formidable had patched the issue in version
3.2.4. Then it’s easy, just a simple
resolution right? Oh boy, I was wrong…
I was enjoying my weekend when the Server team pinged me and told me the images I delivered cannot be started on Kubernetes and they are tossing errors:
Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: ./node_modules/formidable/src/index.js
Well well well. It’s an ES Module. We now got a problem. According to the website,
formidable@v3 is an ES Module without CommonJS support.
Now we have a very interesting situation:
formidable@v3 is an ES Module, but it fixed the vulnerability;
koa-body is written in CommonJS with TypeScript support; it is not able to use ES Module only packages;
Our project is written in CommonJS.
koa-body themselves can only upgrade to
formidable@v2 at most. So, this leaves two options for us:
formidableto backport the fix;
We end up choosing the latter and delivered the fix.
But I still wrote a fix for option 1 (Although actually not needed, see my rant for more details). If you still have to use
formidable, you can use a fixed version that patched the problem in
@v2 with a fake 3.2.4 version to bypass the vulnerability: https://github.com/patrick330602/formidable.
Software is built by man, people make mistakes, and that means no software is perfect. Softwares are always potentially vulnerable. Heck, even we the human are not vulnerable to the latest vulnerability, COVID-19!
But there will be people who say no, for example, large cooperation running critical infrastructures. They have strict vulnerability requirements and will toss you a report of 30k vulnerabilities, and tell you to fix it. Yep, that’s me. I took a week to generate 500+ suggestions for all dev teams just for that.
However, this is exactly what I am ranting for. These kinds of unfixable, problematic, or questionable bugs or vulnerabilities are driving me nuts.
From the NVD database, I saw a link to a Medium article talking about this CVE (And their rants). This is a really good article talking about the issue, and why this is a false positive vulnerability.
Problematic vulnerabilities are still really common. They can be revoked from a third party, but it seems not for CVE themselves. heck, there are even falsely linked vulnerabilities. However, your (and our) customers usually won’t listen. They will point out it is a vulnerability and needs to be fixed. What we could only do is tell them they are not able to be fixed now.
The original CVE-2022-29622 issue has some interesting discussions too. This line by
@keymandllperfectly sums up the problem in CVEs:
The CVE looks to me like yet another overly eager “security professional” trying to get a CVE attached to his/her name by ignoring context and understanding of responsibilities. Then, all the other lemmings just accept it and pick it up without actually looking into the reported “issue”.
The funny thing about that Medium article is that it says, and I quote:
Even the National Vulnerability Database (NVD) is willing to accept anything nowadays?
Well, guess where I find the article? The CVE site!
Oh the irony.