5 ms·

I don't understand, were you planning to patch the CRITICAL vulnerability but now that it's only HIGH you have dropped the patch? It's nice to have a scale for

I don't understand, were you planning to patch the CRITICAL vulnerability but now that it's only HIGH you have dropped the patch? It's nice to have a scale for these things but it also doesn't fucking matter.

fragmede 4y ago
Patching things isn't free. If it's only HIGH and not CRITICAL, then users really are going to spend their time on other things and leave things unpatched.
- Thorrez 4y ago
  It goes both ways. If engineers are so busy they can't patch HIGH vulnerabilities, and a lot of CRITICAL vulnerabilities come in that don't impact them, they might decide they're to busy to patch CRITICAL vulnerabilities too.
  - Xylakant 4y ago
    There’s enough places where I would hold off on patching critical vulnerabilities as well. Practically all vulnerabilities require some specific to be in place to be exploitable. It’s up to the engineers to determine whether they are affected. Heartbleed for example was ranked as critical, but if your public SSL sessions terminated at a server running some other TLS stack, you could hold off with patching and roll it into the general patch cycle. Why should you invest time into an out of cycle patch for no gain other than the fuzzy feeling of having patched.
tedunangst 4y ago
Well... I am not in favor of fine grained severities, personally, but that's what I'm asking. Where in the patch response decision tree do I plug in HIGH vs CRIT? For people who do play this game, now that this vuln is apparently both CRIT or HIGH depending, how do I know which value to plug into my response decider?
- kdmccormick 4y ago
  Do you actually want this spelled out for you? * CRIT - Wake an engineer up at 3 AM to apply the patch. * HIGH - Apply the patch in the next 24 hours. * MEDIUM - Apply the patch in the next week. * LOW - Apply the patch in the next month. I'm making these time frames up, but I'm doing it to illustrate a point: different vulnerabilities have different priority levels. If you consider EVERY VULNERABILITY IN EVERY PACKAGE TO BE AN EMERGENCY then your on-call engineers aren't going to get a lot of sleep, and they'll probably find work somewhere less alarmist. Library maintainers like OpenSSL provide these severity levels to assist you in that prioritization game. If you don't trust them, which might be warranted in some systems, that's fine; you can always read every single CVE for every package yourself (or pay someone to do so).
  - 0xbadcafebee 4y ago
    More realistically: * CRIT - The CEO called my boss and asked if we were patched yet, so I will be working 16 hour days until it's patched, even if the vuln can't be exploited * HIGH - My boss told his bosses we have a deadline of other work to meet, so I have until the end of next week * MEDIUM - Put it in the backlog * LOW - We will upgrade or sunset the product before it gets patched
    - SoftTalker 4y ago
      Nice that you have a CEO who is has ever heard of OpenSSL much less is monitoring patch advisory notices.
      - 0xbadcafebee 4y ago
        They don't, but sometimes a big vuln makes it into The New York Times or something and they get panicky
        midasuni 4y ago
        When the json thing came out I think it was late night Thursday on HN. I’d checked and patched our applicable servers on Friday and carried on The panic set in over the weekend as managers decided to issue major panic stations, bronze and silver bridge calls, etc - after it had reached the more general press. Told them to f-off, public facing servers had been automatically patched, most of the rest manually done and triaged.
insanitybit 4y ago
Why would I patch this in an environment where I only trust certificates that I control and distribute? And in environments where TLS session handling is done in a process with stack cookies (assuming I verify there's a cookie on this function)? The reason to have these descriptions is to assess whether this threat applies to you. If I were in another position I would care a lot, but I'm not. I'll likely patch anyways because this bug may end up being a useful primitive in a larger chain of bugs (kinda doubt it tho tbh), and for me patching is not hard, but at scale, given this threat model, I would not necessarily trigger an out of cycle patch.
colinsane 4y ago
> were you planning to patch the CRITICAL vulnerability but now that it's only HIGH you have dropped the patch? i mean it’s not far from the truth. do i wake up early on release day and rush out a manual patch, or do i do nothing and observe it to be fixed 1-2 days from now when my OS vendor ships an updated openssl in the course of business-as-usual? what kind of environment are you in where you’re keeping up with CVEs but don’t care about their categorization?
- qwertox 4y ago
  Their initial assessment was CRITICAL at the point of announcement. Turned out to be only HIGH. Aren't we lucky or what? Would I have preferred to not deal with it on this holiday? Yes. But I prefer to be safe than sorry, and the OpenSSL team is doing their best to help us be to safe. When was the last time you had to deal with such an issue, where a HIGH vuln was announced as a CRITICAL one?
sigzero 4y ago
They are both getting patched. They only downgraded the CRITICAL designation to a HIGH after further testing etc. They are still fixing it.

fragmede 4y ago

Patching things isn't free. If it's only HIGH and not CRITICAL, then users really are going to spend their time on other things and leave things unpatched.

Thorrez 4y ago
It goes both ways. If engineers are so busy they can't patch HIGH vulnerabilities, and a lot of CRITICAL vulnerabilities come in that don't impact them, they might decide they're to busy to patch CRITICAL vulnerabilities too.
- Xylakant 4y ago
  There’s enough places where I would hold off on patching critical vulnerabilities as well. Practically all vulnerabilities require some specific to be in place to be exploitable. It’s up to the engineers to determine whether they are affected. Heartbleed for example was ranked as critical, but if your public SSL sessions terminated at a server running some other TLS stack, you could hold off with patching and roll it into the general patch cycle. Why should you invest time into an out of cycle patch for no gain other than the fuzzy feeling of having patched.

tedunangst 4y ago

Well... I am not in favor of fine grained severities, personally, but that's what I'm asking. Where in the patch response decision tree do I plug in HIGH vs CRIT? For people who do play this game, now that this vuln is apparently both CRIT or HIGH depending, how do I know which value to plug into my response decider?

kdmccormick 4y ago
Do you actually want this spelled out for you? * CRIT - Wake an engineer up at 3 AM to apply the patch. * HIGH - Apply the patch in the next 24 hours. * MEDIUM - Apply the patch in the next week. * LOW - Apply the patch in the next month. I'm making these time frames up, but I'm doing it to illustrate a point: different vulnerabilities have different priority levels. If you consider EVERY VULNERABILITY IN EVERY PACKAGE TO BE AN EMERGENCY then your on-call engineers aren't going to get a lot of sleep, and they'll probably find work somewhere less alarmist. Library maintainers like OpenSSL provide these severity levels to assist you in that prioritization game. If you don't trust them, which might be warranted in some systems, that's fine; you can always read every single CVE for every package yourself (or pay someone to do so).
- 0xbadcafebee 4y ago
  More realistically: * CRIT - The CEO called my boss and asked if we were patched yet, so I will be working 16 hour days until it's patched, even if the vuln can't be exploited * HIGH - My boss told his bosses we have a deadline of other work to meet, so I have until the end of next week * MEDIUM - Put it in the backlog * LOW - We will upgrade or sunset the product before it gets patched
  - SoftTalker 4y ago
    Nice that you have a CEO who is has ever heard of OpenSSL much less is monitoring patch advisory notices.
    - 0xbadcafebee 4y ago
      They don't, but sometimes a big vuln makes it into The New York Times or something and they get panicky
      - midasuni 4y ago
        When the json thing came out I think it was late night Thursday on HN. I’d checked and patched our applicable servers on Friday and carried on The panic set in over the weekend as managers decided to issue major panic stations, bronze and silver bridge calls, etc - after it had reached the more general press. Told them to f-off, public facing servers had been automatically patched, most of the rest manually done and triaged.

insanitybit 4y ago

Why would I patch this in an environment where I only trust certificates that I control and distribute? And in environments where TLS session handling is done in a process with stack cookies (assuming I verify there's a cookie on this function)? The reason to have these descriptions is to assess whether this threat applies to you. If I were in another position I would care a lot, but I'm not. I'll likely patch anyways because this bug may end up being a useful primitive in a larger chain of bugs (kinda doubt it tho tbh), and for me patching is not hard, but at scale, given this threat model, I would not necessarily trigger an out of cycle patch.

colinsane 4y ago

> were you planning to patch the CRITICAL vulnerability but now that it's only HIGH you have dropped the patch? i mean it’s not far from the truth. do i wake up early on release day and rush out a manual patch, or do i do nothing and observe it to be fixed 1-2 days from now when my OS vendor ships an updated openssl in the course of business-as-usual? what kind of environment are you in where you’re keeping up with CVEs but don’t care about their categorization?

qwertox 4y ago
Their initial assessment was CRITICAL at the point of announcement. Turned out to be only HIGH. Aren't we lucky or what? Would I have preferred to not deal with it on this holiday? Yes. But I prefer to be safe than sorry, and the OpenSSL team is doing their best to help us be to safe. When was the last time you had to deal with such an issue, where a HIGH vuln was announced as a CRITICAL one?

sigzero 4y ago

They are both getting patched. They only downgraded the CRITICAL designation to a HIGH after further testing etc. They are still fixing it.