5 ms·

I'm a command-line development tools maintainer for an OS. I am not unfamiliar with high-level CVEs in my inbox with the likes of "gdb crashes on a handcrafted

by bregma 6y ago

I'm a command-line development tools maintainer for an OS. I am not unfamiliar with high-level CVEs in my inbox with the likes of "gdb crashes on a handcrafted core file causing a DoS". I am unfamiliar with a real world in which a simple old-fashioned segfault in a crash analysis tool is truly a denial of service security vulnerability, but our security department assures us we need to drop all revenue work and rush out a fix because our customers may already be aware that our product is shipping with a known CVE. There are occasions in which I recognize a CVE as a vulnerability to a legitimate possible threat to an asset. By and large, however, they seem to be marketing material for either organizations offering "protection" or academics seeking publication. I think like anything else of value, inflation will eat away at the CVE system until something newer and once again effective will come along.

deleted 6y ago
[deleted]
beardedwizard 6y ago
Maybe you can get on the phone with your customers, their security teams, and their compliance teams and explain every single day why these known vulnerabilities are not serious and can never be leveraged. You can convince them all of these latent bugs will never pose a serious risk. You can do this all day every day. Or you can just patch, and maintain a capability to do so quickly because bugs don't just affect security and the inability to update dependencies is really a reflection of awful development practices.
- nullc 6y ago
  It's sad, however, when a highly non-exploitable crash is treated as a five alarm fire while a "silently corrupts users data" falls to the wayside because people don't generally write security vulnerability reports for those. I've heard from some people that they have considered filing security CVEs against non-security but high user impact bugs in software that they're working on, just to regain control of priorities from CVE spammers.
  - beardedwizard 6y ago
    Agree, but having to make these judgement calls at all is a mistake. We need to get to 'just fix it'.
    - TheDong 6y ago
      I don't quite get what you mean. There's finite time and developer effort. You always have to make judgement calls about what to prioritize over what, you can't "just fix it" for literally everything unless you're in a very fortunate position of working in a codebase with minimal tech debt, a mature scope, and sufficient developer-hours. If you're saying that the CVEs that amount to "update dependency X" or whatever should be "just automatically fixed" rather than have to be prioritized, I agree that should be true for a subset of em... But not every dependency update or CVE resolution is trivial, and even the supposedly trivial ones may still require a certain amount of testing or refactoring.
      - whydoyoucare 6y ago
        If the codebase is sufficiently complex, irrespective how mature and tech-debt-free, certain dependency upgrades are simply non-trivial (this includes the testing effort as well as the actual upgrade effort). Like they say "there are no small changes in a big system". So resolving certain CVEs' is simply a delicate balance to be had between the actual damage potential and the amount of effort.
  - ungamed 6y ago
    Non exploitable crash can be a denial of service, given the right configuration. Ie, filling up disk core file storage, crashing at the right time can force expensive operations to retry/rollback.
    - saagarjha 6y ago
      This is exactly the attitude we’re talking about. Ok, if you do a bunch of things maybe it could make the service throw a disk usage warning email your way. But a service that is actually crashing now is obviously quite a bit more important.
- bartread 6y ago
  > really a reflection of awful development practices. You don't know a thing about GP's development practices so perhaps you should be a bit slower to hurl accusations.
- arp242 6y ago
  "Never fix it" is one extreme. "Drop all revenue work and rush out a fix" is another. The previous poster didn't say it should never get fixed, but rather that there's some nuance to be had in these things, and that fixing it in e.g. the next release is usually just fine too.
  - beardedwizard 6y ago
    No disagreement here. What is dangerous for me is the idea that difficulty upgrading for security fixes does not predict the same difficulty for other fixes. It's not that security bugs are uniquely hard to patch, it's that dependency management on the whole is neglected and security gets the blame. Those crusty old dependencies and the processes around them are an operational risk, we should be lowering the bar to just patching rather than picking and choosing.
    - arp242 6y ago
      Who is talking about "crusty old dependencies"? Or processes which are an "operational risk"? The previous poster never mentioned any of those things.
      - beardedwizard 6y ago
        They get old and crusty when you have to choose not to patch, or de prioritize those not so serious bugs because the operational cost is too high. Developers shouldn't have to make this call, the cost should be zero.
        arp242 6y ago
        I think you're making all sorts of assumptions and extrapolations here that I'm not really seeing any hints of. What I see is that someone is responsible for dealing with CVEs, judges its severity as they come in, and concludes that a lot of them are just cruft and not really worthy of a CVE as such. Nothing more, nothing less.
- hoppla 6y ago
  It will probably be less effort to patch (increment version number) a non existing vulnerability than to explain it to every customer that comes with an report from a third party auditor. CVEs for non-vulnerabilities is like corporate trolling
raverbashing 6y ago
Ah yes, this also fits with the famous "no insecure algorithms" in which an auditor will check a box if your use md5, even if for a feature totally unrelated to security.
- brohee 6y ago
  TBH, if you are doing security with it, it's obviously wrong, but if you are not, it also is because way better (faster) options exist for non security usage...
- consp 6y ago
  I've seen exactly this many times in audits (gets them a high score!). If they flag it and not check the usage I know they didn't bother putting anyone good on the audit or only ran automated stuff and it is pretty much useless. The same can now be said for sha1, gets them results quickly and looks good on the final report.
- Macha 6y ago
  Our security team at a previous employer previously added a systemwide checker to our github enterprise installation that would spam comments on any change to a file in which Math.random is used. The idea is that anyone using random numbers must be implementing a cryptographic protocol and therefore should not be using Math.random as it's not a CSPRNG. So all the AB tests, percentage rollouts etc. started getting spam PR comments until they were made to turn it back off again. Frankly if a teammate was writing their own crypto algorithm implemntation in the bog standard web app we working on, that would be more concerning than which RNG they're using.
- koolba 6y ago
  There’s the “executive” level of this stupidity where an app replaces their md5 OpenSSL calls with their own internal copy pasta of the function. “Look ma! We’re FIPS compliant now!”
  - whydoyoucare 6y ago
    Unfortunately, that happens because most regulations try to enforce a black-and-white rulebook, which is easy on the auditors but extremely difficult on those being audited. I now thinks most compliance regulations are by auditors for auditors... :-D :-D

by bregma 6y ago

deleted 6y ago

[deleted]

beardedwizard 6y ago

Maybe you can get on the phone with your customers, their security teams, and their compliance teams and explain every single day why these known vulnerabilities are not serious and can never be leveraged. You can convince them all of these latent bugs will never pose a serious risk. You can do this all day every day. Or you can just patch, and maintain a capability to do so quickly because bugs don't just affect security and the inability to update dependencies is really a reflection of awful development practices.

nullc 6y ago
It's sad, however, when a highly non-exploitable crash is treated as a five alarm fire while a "silently corrupts users data" falls to the wayside because people don't generally write security vulnerability reports for those. I've heard from some people that they have considered filing security CVEs against non-security but high user impact bugs in software that they're working on, just to regain control of priorities from CVE spammers.
- beardedwizard 6y ago
  Agree, but having to make these judgement calls at all is a mistake. We need to get to 'just fix it'.
  - TheDong 6y ago
    I don't quite get what you mean. There's finite time and developer effort. You always have to make judgement calls about what to prioritize over what, you can't "just fix it" for literally everything unless you're in a very fortunate position of working in a codebase with minimal tech debt, a mature scope, and sufficient developer-hours. If you're saying that the CVEs that amount to "update dependency X" or whatever should be "just automatically fixed" rather than have to be prioritized, I agree that should be true for a subset of em... But not every dependency update or CVE resolution is trivial, and even the supposedly trivial ones may still require a certain amount of testing or refactoring.
    - whydoyoucare 6y ago
      If the codebase is sufficiently complex, irrespective how mature and tech-debt-free, certain dependency upgrades are simply non-trivial (this includes the testing effort as well as the actual upgrade effort). Like they say "there are no small changes in a big system". So resolving certain CVEs' is simply a delicate balance to be had between the actual damage potential and the amount of effort.
- ungamed 6y ago
  Non exploitable crash can be a denial of service, given the right configuration. Ie, filling up disk core file storage, crashing at the right time can force expensive operations to retry/rollback.
  - saagarjha 6y ago
    This is exactly the attitude we’re talking about. Ok, if you do a bunch of things maybe it could make the service throw a disk usage warning email your way. But a service that is actually crashing now is obviously quite a bit more important.
bartread 6y ago
> really a reflection of awful development practices. You don't know a thing about GP's development practices so perhaps you should be a bit slower to hurl accusations.
arp242 6y ago
"Never fix it" is one extreme. "Drop all revenue work and rush out a fix" is another. The previous poster didn't say it should never get fixed, but rather that there's some nuance to be had in these things, and that fixing it in e.g. the next release is usually just fine too.
- beardedwizard 6y ago
  No disagreement here. What is dangerous for me is the idea that difficulty upgrading for security fixes does not predict the same difficulty for other fixes. It's not that security bugs are uniquely hard to patch, it's that dependency management on the whole is neglected and security gets the blame. Those crusty old dependencies and the processes around them are an operational risk, we should be lowering the bar to just patching rather than picking and choosing.
  - arp242 6y ago
    Who is talking about "crusty old dependencies"? Or processes which are an "operational risk"? The previous poster never mentioned any of those things.
    - beardedwizard 6y ago
      They get old and crusty when you have to choose not to patch, or de prioritize those not so serious bugs because the operational cost is too high. Developers shouldn't have to make this call, the cost should be zero.
      - arp242 6y ago
        I think you're making all sorts of assumptions and extrapolations here that I'm not really seeing any hints of. What I see is that someone is responsible for dealing with CVEs, judges its severity as they come in, and concludes that a lot of them are just cruft and not really worthy of a CVE as such. Nothing more, nothing less.
hoppla 6y ago
It will probably be less effort to patch (increment version number) a non existing vulnerability than to explain it to every customer that comes with an report from a third party auditor. CVEs for non-vulnerabilities is like corporate trolling

raverbashing 6y ago

Ah yes, this also fits with the famous "no insecure algorithms" in which an auditor will check a box if your use md5, even if for a feature totally unrelated to security.

brohee 6y ago
TBH, if you are doing security with it, it's obviously wrong, but if you are not, it also is because way better (faster) options exist for non security usage...
consp 6y ago
I've seen exactly this many times in audits (gets them a high score!). If they flag it and not check the usage I know they didn't bother putting anyone good on the audit or only ran automated stuff and it is pretty much useless. The same can now be said for sha1, gets them results quickly and looks good on the final report.
Macha 6y ago
Our security team at a previous employer previously added a systemwide checker to our github enterprise installation that would spam comments on any change to a file in which Math.random is used. The idea is that anyone using random numbers must be implementing a cryptographic protocol and therefore should not be using Math.random as it's not a CSPRNG. So all the AB tests, percentage rollouts etc. started getting spam PR comments until they were made to turn it back off again. Frankly if a teammate was writing their own crypto algorithm implemntation in the bog standard web app we working on, that would be more concerning than which RNG they're using.
koolba 6y ago
There’s the “executive” level of this stupidity where an app replaces their md5 OpenSSL calls with their own internal copy pasta of the function. “Look ma! We’re FIPS compliant now!”
- whydoyoucare 6y ago
  Unfortunately, that happens because most regulations try to enforce a black-and-white rulebook, which is easy on the auditors but extremely difficult on those being audited. I now thinks most compliance regulations are by auditors for auditors... :-D :-D