3 ms·

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 unli

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.
- beardedwizard 7y ago
  Have to agree with above comment - this is where snyk and whitesource are trying to stand out with usage analysis to tell you if you are truly vulnerable. The load is too high on both sides for humans.
  - ErrantX 7y ago
    My experience is that whitesource still has some way to go... Someone who can solve this problem effectively could make some real money.
    - beardedwizard 7y ago
      You tried eua and still got false positives?
- deleted 7y ago
  [deleted]
- cipherboy 7y ago
  Yes, this is a separate issue. jackson-databind is a XML/JSON parser so I was presuming a web stack here and that your customer wouldn't necessarily know what your backend was. Which also means that it is up to you to secure it properly, which has its own risk. I'd just point out that accepting any customer's policy as something you implicitly agree to support is inherently risky without an adequate contract between the relevant parties. Presumably, you've signed a contract with the customer, and if they have a no-CVE policy, there's SLAs that you can point to that say what is and isn't covered, and by what date. So it is just the price of doing business and both parties know that this'll impact the delivery of other features, bug fixes, &c. Otherwise, your business-people aren't doing a great job of covering the costs of doing business with said customer... :) Without much better developer tooling, we'll always be trying to catch up with the people who find vulnerabilities. People aren't perfect. Tools aren't perfect either. But they can complement each other nicely and currently most projects err on the side of "too little" rather than "too much" tooling.
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.

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.
beardedwizard 7y ago
Have to agree with above comment - this is where snyk and whitesource are trying to stand out with usage analysis to tell you if you are truly vulnerable. The load is too high on both sides for humans.
- ErrantX 7y ago
  My experience is that whitesource still has some way to go... Someone who can solve this problem effectively could make some real money.
  - beardedwizard 7y ago
    You tried eua and still got false positives?
deleted 7y ago
[deleted]
cipherboy 7y ago
Yes, this is a separate issue. jackson-databind is a XML/JSON parser so I was presuming a web stack here and that your customer wouldn't necessarily know what your backend was. Which also means that it is up to you to secure it properly, which has its own risk. I'd just point out that accepting any customer's policy as something you implicitly agree to support is inherently risky without an adequate contract between the relevant parties. Presumably, you've signed a contract with the customer, and if they have a no-CVE policy, there's SLAs that you can point to that say what is and isn't covered, and by what date. So it is just the price of doing business and both parties know that this'll impact the delivery of other features, bug fixes, &c. Otherwise, your business-people aren't doing a great job of covering the costs of doing business with said customer... :) Without much better developer tooling, we'll always be trying to catch up with the people who find vulnerabilities. People aren't perfect. Tools aren't perfect either. But they can complement each other nicely and currently most projects err on the side of "too little" rather than "too much" tooling.

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.