CVEs incorrectly applied to EAP versions of IntelliJ IDEA

[ddribeiro]

Fleet version: 4.57.2

---

💥  Actual behavior

CVEs are being incorrectly applied to EAP versions of IntelliJ IDEA. For example, CVE-2017-8316 is listed on NVD as affecting up to (excluding) 2017.2.2.

Fleet is returning EAP versions of IntelliJ as affected by this CVE when they shouldn't apply.

To QA

Grab a JetBrains EAP for macOS (currently Writerside is the only JetBrains product with an active EAP) and open it so it shows up in apps (after refreshing the host). It should show as version 2024.2.99.xx.yy in the UI.

Grab the PhpStorm EAP from this Fleet GDrive link. Open it (it'll bail after a few seconds, but should show up anyway; if it doesn't you may need to update the database with an opened-at timestamp). Refresh the host, then run a vulnerabilities cron. You should see no vulnerabilities.

Change the version in the database to 2022.3.99.123.456. Run the vulnerabilities cron (or command) again. You should now see two vulnerabilities (previously PhpStorm EAPs would show all three vulns that PhpStorm has ever had).

[JoStableford]

Linked to Unthread ticket:

Incorrect CVE Applicability for IntelliJ IDEA EAP Versions #2968)

[sharon-fdm]

@mostlikelee, is this a duplicate?

[mostlikelee]

@sharon-fdm I don't believe so

[mostlikelee]

After further investigation, Jetbrains EAP products are only providing build numbers instead of the common version string (ie. 2024.3`). We will attempt to reach out to Jetbrains, but other options to consider:

• pull the version string from the application name IntelliJ IDEA 2024.3 EAP.app
• skip all EAP versions in vuln processing (CPE translation skip)

[iansltx]

Confirmed with JetBrains that EAP versions can reliably be correlated with published versions by e.g.

243.xx.yy -> EAP for 2024.3

(prepend 20, split 3rd digit of major version to minor version, truncate)

We'll want to ensure we're dealing with a three-digit major version prior to doing this munging since if you go back far enough there are some two-digit versions.

Since EAP versions are prereleases, an EAP should be considered as an earlier version than the release; if a vuln was fixed in 2024.3 then EAP 243.xx.yy would be vulnerable, but EAP 244.xx.yy wouldn't be.

[iansltx]

Was looking at fixing this in sanitizeSoftware but feels like we want to tweak version numbers later in the pipeline, e.g. before pulling vulns, since basically what I need to do here is e.g. EAP IC-242.16677.21 -> 2024.1.99999 or something, which looks ugly/is technically incorrect on the display side, but will evaluate correctly for vuln checking.

[iansltx]

Looking at this further/chatting through with @mostlikelee, thinking we should pull the current sanitization for CPE purposes into a struct on CPE translations instead. To bound scope this EAP issue will be the first case with the revised architecture, with a follow-on ticket for cleaning up the rest of the sanitization.

[iansltx]

Scope of this fix will be on macOS, as we're going to rely on bundle ID to spot EAPs. We can expand to Windows/Linux later by software name matching but bundle ID pattern matching will catch all current and future JetBrains IDEs as they're consistent about naming.

For reference, bouncing between standard and EAP versions of various JetBrains products gets me this on macOS:

+--------------------------+---------------------+--------+--------------------------------------------------+
| name                     | version             | source | bundle_identifier                                |
+--------------------------+---------------------+--------+--------------------------------------------------+
| GoLand.app               | 2024.3              | apps   | com.jetbrains.goland                             |
| DataGrip.app             | 2024.3              | apps   | com.jetbrains.datagrip                           |
| embeddings-server.app    | 2.0                 | apps   | org.jetbrains.completion.embeddings.local.server |
| JetBrains Toolbox.app    | 2.3.2.31487         | apps   | com.jetbrains.toolbox                            |
| JetBrains Toolbox.app    | 2.5.2.35332         | apps   | com.jetbrains.toolbox                            |
| WebStorm.app             | 2024.3              | apps   | com.jetbrains.WebStorm                           |
| PhpStorm.app             | 2024.3.1            | apps   | com.jetbrains.PhpStorm                           |
| JetBrains Toolbox.app    | 2.5.2.35332         | apps   | com.jetbrains.toolbox.helper                     |
| full-line-inference.app  | 1.2                 | apps   | org.jetbrains.completion.full.line.local.server  |
| PyCharm Professional.app | 2024.3              | apps   | com.jetbrains.pycharm                            |
| PyCharm Professional.app | 2024.3.1            | apps   | com.jetbrains.pycharm                            |
| GoLand.app               | EAP GO-243.21565.42 | apps   | com.jetbrains.goland-EAP                         |
| DataGrip.app             | EAP DB-243.16718.27 | apps   | com.jetbrains.datagrip-EAP                       |
| WebStorm.app             | 2024.3.1            | apps   | com.jetbrains.WebStorm                           |
| PhpStorm.app             | EAP PS-243.19420.27 | apps   | com.jetbrains.PhpStorm-EAP                       |
+--------------------------+---------------------+--------+--------------------------------------------------+

GoLand betas show up as EAPs.

[iansltx]

Had to rework this to use the existing mutateSoftware action (on-ingest) as the quick-fix insertion into the CPE resolution flow didn't seem to have any effect. So we'll be aliasing e.g. 2024.3 EAP to 2024.2.99 and copying minor/patch version from the EAP as-is on the end so admins can tell different EAPs apart.

Going to create an issue to move this version mutation logic from ingest to CPE resolution as the real reason we're munging version numbers is for vuln matching so we can do this once per vulns run rather than once per software ingest. But in the interim this gets rid of false positives while avoiding false negatives for IDE vulnerabilities that didn't get a bunch of backported patches.

That last caveat applies to CVE-2024-37051, which had both backports and some EAPs as vulnerable, however JetBrains expires access to EAPs and all affected versions (and all newer EAPs for the same products) have been expired by now, so you can't get to an exploitable state for those EAPs anymore. As such, the false negative on that particular CVE for EAPs only seems fine.