6 ms·

These reports are a a waste of everyone's time. There are 10s of completely meaningless CVEs being issued for each new deserialization gadget that someone finds

by lol768 7y ago

These reports are a a waste of everyone's time. There are 10s of completely meaningless CVEs being issued for each new deserialization gadget that someone finds and gets added to a blacklist designed to protect a known-unsafe use-case (deserializing user input whilst defaultTyping is enabled). They're not general vulnerabilities in the library. They surface when people use a documented-dangerous function in a stupid way.

ErrantX 7y ago
Its aggravating because then internal security flags pick it up and create "upgrade this lib" busywork for every team. Obviously this stuff (security disclosure) isn't easy but with such a pervasive library near monthly findings is a growing chore.
- cipherboy 7y ago
  The correct response is to audit how you use it, especially what other libraries you have on the classpath. Per another comment on this submission [0], its unlikely that you've satisfied all the requirements for exploiting these CVEs. If you don't satisfy those preconditions, there's not much benefit in upgrading. Additionally, 2.10 deprecates the unsafe behavior and introduces a new, safer alternative. See the blog post for more information there. [1] That might be a valid reason to spend time upgrading. Obviously, if you're actually affected, then yes, upgrading or backporting patches is a good idea. [0]: https://news.ycombinator.com/item?id=21171746 https://news.ycombinator.com/item?id=21171746 [1]: https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062 https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-...
  - TallGuyShort 7y ago
    The problem is when you have customers who have internal no-CVE policies and a business-person looking at fortify instead of an engineer looking at the technology. Then they insist on special releases every month because Jackson has another CVE, and if you don't do it, their manager talks to your manager.
    - user5994461 7y ago
      Even if you have the technologist, it's just too much work and it's soul breaking to go over every CVE, try to understand if the CVE is a real vulnerability or not and what it is about. They don't bother most of the time to explain what is the issue or what's the fix.
      - lol768 7y ago
        >They don't bother most of the time to explain what is the issue or what's the fix. This - the vulnerability descriptions are usually incredibly poor. Snyk are bad at this too. What's particularly infuriating is when the descriptions tell you what a generic e.g. XSS or Java deserialisation vulnerability is. It's so incredibly patronising and doesn't tell you anything at all about the _specifics_ of the problem. If you're really lucky you'll be able to find the patch that fixes the CVE on GitHub (often the commit messages are deliberately vague - I guess the devs think it'll be exploited less this way?) and then you can try to reverse engineer what the actual problem was and what you'd need to be to be exploitable.
    - SpicyLemonZest 7y ago
      And honestly, I’m not sure the businesspeople have it wrong here. Maybe I can guarantee that there’s no real issue in our current build; how do I know that nobody will ever change things in a way that exposes the vulnerability? What’s the control against a lazy or bad engineer saying “this other CVE can be ignored because I don’t personally see how to exploit it”?
      - dogma1138 7y ago
        They aren’t wrong. First you have a regulatory landscape that isn’t going to evaluate every CVE and every implementation so if you work in a regulated sector you get no CVE over X policy by default. Second for a large enterprise with a lot of developed in house applications it’s impossible to validate every implementation and use case; so the default policy is updated or file for an exception in the exception process is upto the application owner in the business to make an argument to the security team why it’s not applicable. No CVE policy is actually the smart way of doing things because it does moves the load form your security team which will be understaffed compared to the development staff (doesn’t matter if it’s in house or not) and they have better things to focus on than going over SCA or Vuln scanning CVE reports.
  - ErrantX 7y ago
    The biggest problem is; jackson is not just my dependency, but a dependency of my dependencies. And those packages are not heavily managed enterprise things.... So it's an intense cycle. A great step might be for libraries to note when their implementation of a package is safe.
DCKing 7y ago
The CVE database can be quite problematic for libraries. CVEs get registered according to some 'worst case' impact criteria. This means that more often than not, you the alerts go off for 'using the library in a stupid way' or 'using the library in an exotic/unusual way'. Often - not in this case - CVE descriptions are also poorly written, making it extremely difficult what kind of library use is the prerequisite for your product to be vulnerable. Stuff like this warrants a followup, but you have to have a good option in your vulnerability management to accept a vulnerable dependency (especially if - unlike this case - the upgrade path is not available or requires extensive other upgrades). In any case, casual high-rated CVEs for library edge cases like this contribute a lot to "alarm fatigue". Despite the CVE database being problematic for libraries, there's no real alternative for answering the question "do my dependencies have security problems?", so you've got to accomodate.

by lol768 7y ago

ErrantX 7y ago

Its aggravating because then internal security flags pick it up and create "upgrade this lib" busywork for every team. Obviously this stuff (security disclosure) isn't easy but with such a pervasive library near monthly findings is a growing chore.

cipherboy 7y ago
The correct response is to audit how you use it, especially what other libraries you have on the classpath. Per another comment on this submission [0], its unlikely that you've satisfied all the requirements for exploiting these CVEs. If you don't satisfy those preconditions, there's not much benefit in upgrading. Additionally, 2.10 deprecates the unsafe behavior and introduces a new, safer alternative. See the blog post for more information there. [1] That might be a valid reason to spend time upgrading. Obviously, if you're actually affected, then yes, upgrading or backporting patches is a good idea. [0]: https://news.ycombinator.com/item?id=21171746 https://news.ycombinator.com/item?id=21171746 [1]: https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062 https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-...
- TallGuyShort 7y ago
  The problem is when you have customers who have internal no-CVE policies and a business-person looking at fortify instead of an engineer looking at the technology. Then they insist on special releases every month because Jackson has another CVE, and if you don't do it, their manager talks to your manager.
  - user5994461 7y ago
    Even if you have the technologist, it's just too much work and it's soul breaking to go over every CVE, try to understand if the CVE is a real vulnerability or not and what it is about. They don't bother most of the time to explain what is the issue or what's the fix.
    - lol768 7y ago
      >They don't bother most of the time to explain what is the issue or what's the fix. This - the vulnerability descriptions are usually incredibly poor. Snyk are bad at this too. What's particularly infuriating is when the descriptions tell you what a generic e.g. XSS or Java deserialisation vulnerability is. It's so incredibly patronising and doesn't tell you anything at all about the _specifics_ of the problem. If you're really lucky you'll be able to find the patch that fixes the CVE on GitHub (often the commit messages are deliberately vague - I guess the devs think it'll be exploited less this way?) and then you can try to reverse engineer what the actual problem was and what you'd need to be to be exploitable.
  - SpicyLemonZest 7y ago
    And honestly, I’m not sure the businesspeople have it wrong here. Maybe I can guarantee that there’s no real issue in our current build; how do I know that nobody will ever change things in a way that exposes the vulnerability? What’s the control against a lazy or bad engineer saying “this other CVE can be ignored because I don’t personally see how to exploit it”?
    - dogma1138 7y ago
      They aren’t wrong. First you have a regulatory landscape that isn’t going to evaluate every CVE and every implementation so if you work in a regulated sector you get no CVE over X policy by default. Second for a large enterprise with a lot of developed in house applications it’s impossible to validate every implementation and use case; so the default policy is updated or file for an exception in the exception process is upto the application owner in the business to make an argument to the security team why it’s not applicable. No CVE policy is actually the smart way of doing things because it does moves the load form your security team which will be understaffed compared to the development staff (doesn’t matter if it’s in house or not) and they have better things to focus on than going over SCA or Vuln scanning CVE reports.
- ErrantX 7y ago
  The biggest problem is; jackson is not just my dependency, but a dependency of my dependencies. And those packages are not heavily managed enterprise things.... So it's an intense cycle. A great step might be for libraries to note when their implementation of a package is safe.

DCKing 7y ago

The CVE database can be quite problematic for libraries. CVEs get registered according to some 'worst case' impact criteria. This means that more often than not, you the alerts go off for 'using the library in a stupid way' or 'using the library in an exotic/unusual way'. Often - not in this case - CVE descriptions are also poorly written, making it extremely difficult what kind of library use is the prerequisite for your product to be vulnerable. Stuff like this warrants a followup, but you have to have a good option in your vulnerability management to accept a vulnerable dependency (especially if - unlike this case - the upgrade path is not available or requires extensive other upgrades). In any case, casual high-rated CVEs for library edge cases like this contribute a lot to "alarm fatigue". Despite the CVE database being problematic for libraries, there's no real alternative for answering the question "do my dependencies have security problems?", so you've got to accomodate.