4 ms·

Very true. So many regulated/government security contexts use “critical” or “high” sev ratings as synonymous for “you can’t declare this unexploitable in contex

Very true. So many regulated/government security contexts use “critical” or “high” sev ratings as synonymous for “you can’t declare this unexploitable in context or write up a preexisting-mitigations blurb, you must take action and make the scanner stop detecting this”, which leads to really stupid prioritization and silliness.

gibsonsmog 6mo ago
At a previous job, we had to refactor our entire front end build system from Rollup(I believe it was) to a custom Webpack build because of this attitude. Our FE process was completely disconnected from the code on the site, existing entirely in our Azure pipeline and developer machines. The actual theoretically exploitable aspects were in third party APIs and our dotNet ecosystems which we obviously fixed. I wrote like 3 different documents and presented multiple times to their security team on how this wasn't necessary and we didn't want to take their money needlessly. $20000 or so later (with a year of support for the system baked in) we shut up Dependabot. Money well spent!
lokar 6mo ago
My favorite: a Linux kernel pcmcia bug. On EC2 VMs.
- Sohcahtoa82 6mo ago
  In a similar vein: Raising alarms on a CVE in Apache2 that only affects Windows when the server is Linux. Or CVEs related to Bluetooth in cloud instances.
  - minetest2048 6mo ago
    Or raising alarm on a CVE in linux mlx5 driver on an embedded device that doesn't have a pcie interface
    - xyzzy123 6mo ago
      ReDoS at CVSS 8+ ... in the configuration file parsing of a bundler.
  - nikanj 6mo ago
    ”If you use that installed Python version to start a web server and use it to parse pdf, you may encounter a potential memory leak” Yeah so 1) not running a web service 2) not parsing pdf in said non-existing service 3) congrats you are leaking memory on my dev laptop
- bostik 6mo ago
  I'll top that: wireless-regdb out of date. Against an EC2-specific kernel.
  - xyzzy123 6mo ago
    Kernel headers out of date -> kernel vulnerability... in a container.
    - bostik 6mo ago
      Okay. You win.
- lokar 6mo ago
  I refused to refer to the whole vulnerability reporting / tracking effort as "security", always correcting people that it was compliance, not security.
jjav 6mo ago
Very early in my career I'd take these vulnerability reports as a personal challenge and spent my day/evening proving it isn't actually exploitable in our environment. And I was often totally correct, it wasn't. But... I spent a bunch of hours on that. For each one. These days we just fix every reported vulnerable library, turns out that is far less work. And at some point we'd upgrade anyway so might as well. Only if it causes problems (incompatible, regressions) then we look at it and analyze exploitability and make judgement calls. Over the last several years we've only had to do that for about 0.12% of the vulnerabilities we've handled.
- ozim 6mo ago
  That’s basically my experience as well. Just upgrading is much easier and cheaper. Of course with latest supply chain failures we don’t update right away or automatically. If it is RCE in a component that is exposed then of course we do it ASAP. But those are super rare.

gibsonsmog 6mo ago

At a previous job, we had to refactor our entire front end build system from Rollup(I believe it was) to a custom Webpack build because of this attitude. Our FE process was completely disconnected from the code on the site, existing entirely in our Azure pipeline and developer machines. The actual theoretically exploitable aspects were in third party APIs and our dotNet ecosystems which we obviously fixed. I wrote like 3 different documents and presented multiple times to their security team on how this wasn't necessary and we didn't want to take their money needlessly. $20000 or so later (with a year of support for the system baked in) we shut up Dependabot. Money well spent!

lokar 6mo ago

My favorite: a Linux kernel pcmcia bug. On EC2 VMs.

Sohcahtoa82 6mo ago
In a similar vein: Raising alarms on a CVE in Apache2 that only affects Windows when the server is Linux. Or CVEs related to Bluetooth in cloud instances.
- minetest2048 6mo ago
  Or raising alarm on a CVE in linux mlx5 driver on an embedded device that doesn't have a pcie interface
  - xyzzy123 6mo ago
    ReDoS at CVSS 8+ ... in the configuration file parsing of a bundler.
- nikanj 6mo ago
  ”If you use that installed Python version to start a web server and use it to parse pdf, you may encounter a potential memory leak” Yeah so 1) not running a web service 2) not parsing pdf in said non-existing service 3) congrats you are leaking memory on my dev laptop
bostik 6mo ago
I'll top that: wireless-regdb out of date. Against an EC2-specific kernel.
- xyzzy123 6mo ago
  Kernel headers out of date -> kernel vulnerability... in a container.
  - bostik 6mo ago
    Okay. You win.
lokar 6mo ago
I refused to refer to the whole vulnerability reporting / tracking effort as "security", always correcting people that it was compliance, not security.

jjav 6mo ago

Very early in my career I'd take these vulnerability reports as a personal challenge and spent my day/evening proving it isn't actually exploitable in our environment. And I was often totally correct, it wasn't. But... I spent a bunch of hours on that. For each one. These days we just fix every reported vulnerable library, turns out that is far less work. And at some point we'd upgrade anyway so might as well. Only if it causes problems (incompatible, regressions) then we look at it and analyze exploitability and make judgement calls. Over the last several years we've only had to do that for about 0.12% of the vulnerabilities we've handled.

ozim 6mo ago
That’s basically my experience as well. Just upgrading is much easier and cheaper. Of course with latest supply chain failures we don’t update right away or automatically. If it is RCE in a component that is exposed then of course we do it ASAP. But those are super rare.