A few days ago, a colleague at work asked me for assistance on a number of vulnerabilities found in Pillow, a graphics library for Python. These are high-severity vulnerabilities (CVSS 3.x score of 7.5), meaning they had less than 30 days to resolve it. This colleague and their team works on a different product than mine–meaning that I’m not familiar with its internals–which depends on the Pillow library for server-side image processing.

These are the said vulnerabilities:

• CVE-2021-27921
  

  Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for a BLP container, and thus an attempted memory allocation can be very large.

• CVE-2021-27922
  

  Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for an ICNS container, and thus an attempted memory allocation can be very large.

• CVE-2021-27923
  

  Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for an ICO container, and thus an attempted memory allocation can be very large.

CVE Classical Conditioning

A knee-jerk reaction of many developers upon seeing a vulnerability report is to upgrade the corresponding library. This probably stems from how CVEs are published, which is shortly after an update is available—the publishing process appears to program an “IF vulnerability THEN update library” statement into developers’ minds. Similar to how sounding a bell to Pavlov’s Dogs condition them to expect that a meal is coming.

Now, this particular set of CVEs has a prescribed remedy, which is to update to Pillow 8.1.1 or newer; which that colleague of mine seem to have realizes a few hours after contacting me. Indicating that is yet another Pavlovian conditioning signal.

But updating a library runs the risk of breaking other parts of the system. Notably when the library authors has little regard to backward compatibility. Which in turn would more likely to occur when you rely on volunteers who work to fulfill their own satisfactions—and not getting paid to ensure smooth upgrades between versions.

Is there another option?

Wouldn’t it be great when faced with a known vulnerability report, you have options other than just updating the vulnerable 3rd party component?

Say No to Pavlov

Yes you can generate other options.

How? By reading the vulnerability description, understanding it, and making a professional judgement on whether your product is affected. If it is not affected, record the assessment (along with the vulnerability’s public identifier) in your tracking system (e.g. JIRA) and be done with it. If it is affected, then create a mitigation plan on what to do with it, also in the same tracking system.

If you look closer to the above CVE descriptions, each vulnerability is about processing a certain niche file formats:

• CVE-2021-27921: blp input – Blizzard Mipmap format
• CVE-2021-27922: icns input – macOS icon file
• CVE-2021-27923: ico input – Windows icon file.

Therefore if your product does not support processing these image types, then it is not affected by the vulnerability. The precondition is the product validates image file formats upon input and reject any unsupported file formats without performing further processing. Preferably it validates the image file’s header to deduce its type or use a utility which does, such as the Unix file command—not by using the Pillow library to validate.

But if your product officially supports these file formats, then one mitigation option would be to convert those files into a simpler format before handing it over to the Pillow library. For instance, you can use the ImageMagick toolset to convert those files into uncompressed BMP or DIB files beforehand.

Realistically when your product is a server-side business application, chances are you don’t need to support these niche image formats. After all, what are the chances that users would upload their photo ID as a multi-resolution macOS icon file? 😉

Next Steps

If you use the Pillow library as part of your products’ dependencies, have a look at the above vulnerabilities and see if it applies. Maybe it’s a good opportunity to improve your product’s input validation logic.

Better yet, be sure to have a good look at the next CVE that comes in—instead of knee-jerk upgrading a library without looking at other options. Remember that upgrading a dependency also carries its own risks.

Thats all for now. Stay safe and secure!

---