6 ms·

>Doesn't sound that critical to me. https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/ https://www.openssl.org/blog/blog/2022/11/01/email-ad

by homarp 4y ago

>Doesn't sound that critical to me. https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/ https://www.openssl.org/blog/blog/2022/11/01/email-address-o... has Q: The 3.0.7 release was announced as fixing a CRITICAL vulnerability, but CVE-2022-3786 and CVE-2022-3602 are both HIGH. What happened to the CRITICAL vulnerability? A: CVE-2022-3602 was originally assessed by the OpenSSL project as CRITICAL as it is an arbitrary 4-byte stack buffer overflow, and such vulnerabilities may lead to remote code execution (RCE). During the week of prenotification, several organisations performed testing and gave us feedback on the issue, looking at the technical details of the overflow and stack layout on common architectures and platforms. Firstly, we had reports that on certain Linux distributions the stack layout was such that the 4 bytes overwrote an adjacent buffer that was yet to be used and therefore there was no crash or ability to cause remote code execution. Secondly, many modern platforms implement stack overflow protections which would mitigate against the risk of remote code execution and usually lead to a crash instead.

tedunangst 4y ago
That sounds bananas. It's okay to have a little stack overflow as a treat? So for some people, this still is a critical vuln. Is there a list of people for whom this is still urgent?
- jefftk 4y ago
  > It's okay to have a little stack overflow as a treat? They're still doing a CVE and publishing a fix, they're just calling it HIGH and not CRITICAL (definition at https://www.openssl.org/policies/general/security-policy.html https://www.openssl.org/policies/general/security-policy.htm...). More on their categorization, from when they decided to break CRITICAL out of HIGH: https://www.openssl.org/blog/blog/2015/09/28/critical-security-level/ https://www.openssl.org/blog/blog/2015/09/28/critical-securi...
- deleted 4y ago
  [deleted]
- orra 4y ago
  Right!? Just because several people have been unable to exploit this stack overflow in a week, doesn't prove the flaw is not exploitable.
  - AdamJacobMuller 4y ago
    If you remember when heartbleed first was announced, cloudflare put up a vulnerable server and challenged the internet saying they did not think it was possible to exploit it to exfiltrate data. They were quickly proven wrong.
    - orra 4y ago
      Thank you. I'd forgotten that, and it's very relevant.
    - charcircuit 4y ago
      I think that's significantly different because that heartbleed gave attackers potentially sensitive information as opposed to just crashing.
      - orra 4y ago
        “Just crashing” is a premise; it hasn't been proven. These are buffer and stack overflows, so I feel some skepticism is warranted.
        charcircuit 4y ago
        Sure, but a vulnerability that out of the box gives attackers potentially sensitive data is a much easier target.
  - snvzz 4y ago
    You forgot the /s sarcasm indicator.
    - orra 4y ago
- stefan_ 4y ago
  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?
    - 4y ago
- ajross 4y ago
  I dunno, your criteria sounds too broad. I think there's absolutely value to the user in having vulnerability disclosures distinguish the case of "exploit exists" from "no exploit exists". It's all well and good to just advise everyone to always update their systems, but in practice people managing systems need to deal with gray areas. Do you shut systems down proactively? Revoke certs for hosts running the old version? Change network access protocols to require the new version? All those decisions have measurable costs, and in practice "we believe this is unexploitable on the OS version you are running" is going to change the decision for some users.
- lmm 4y ago
  If your stack overflow only allows user input to overwrite other unvalidated user input, then yes, it's "ok". Sometimes you get lucky. Of course it's a bug that should still be fixed, but if it's not an exploitable vulnerability then it's not an exploitable vulnerability. (It's not exploitable for ad-hoc rather than systematic reasons, but anyone who's still using C in this day and age is already only avoiding exploitable vulnerabilities through ad-hoc rather than systematic reasons, so that doesn't seem like a reason to rush out a fix).

by homarp 4y ago

tedunangst 4y ago

That sounds bananas. It's okay to have a little stack overflow as a treat? So for some people, this still is a critical vuln. Is there a list of people for whom this is still urgent?

jefftk 4y ago
> It's okay to have a little stack overflow as a treat? They're still doing a CVE and publishing a fix, they're just calling it HIGH and not CRITICAL (definition at https://www.openssl.org/policies/general/security-policy.html https://www.openssl.org/policies/general/security-policy.htm...). More on their categorization, from when they decided to break CRITICAL out of HIGH: https://www.openssl.org/blog/blog/2015/09/28/critical-security-level/ https://www.openssl.org/blog/blog/2015/09/28/critical-securi...
deleted 4y ago
[deleted]
orra 4y ago
Right!? Just because several people have been unable to exploit this stack overflow in a week, doesn't prove the flaw is not exploitable.
- AdamJacobMuller 4y ago
  If you remember when heartbleed first was announced, cloudflare put up a vulnerable server and challenged the internet saying they did not think it was possible to exploit it to exfiltrate data. They were quickly proven wrong.
  - orra 4y ago
    Thank you. I'd forgotten that, and it's very relevant.
  - charcircuit 4y ago
    I think that's significantly different because that heartbleed gave attackers potentially sensitive information as opposed to just crashing.
    - orra 4y ago
      “Just crashing” is a premise; it hasn't been proven. These are buffer and stack overflows, so I feel some skepticism is warranted.
      - charcircuit 4y ago
        Sure, but a vulnerability that out of the box gives attackers potentially sensitive data is a much easier target.
- snvzz 4y ago
  You forgot the /s sarcasm indicator.
  - orra 4y ago
stefan_ 4y ago
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?
  - 4y ago
ajross 4y ago
I dunno, your criteria sounds too broad. I think there's absolutely value to the user in having vulnerability disclosures distinguish the case of "exploit exists" from "no exploit exists". It's all well and good to just advise everyone to always update their systems, but in practice people managing systems need to deal with gray areas. Do you shut systems down proactively? Revoke certs for hosts running the old version? Change network access protocols to require the new version? All those decisions have measurable costs, and in practice "we believe this is unexploitable on the OS version you are running" is going to change the decision for some users.
lmm 4y ago
If your stack overflow only allows user input to overwrite other unvalidated user input, then yes, it's "ok". Sometimes you get lucky. Of course it's a bug that should still be fixed, but if it's not an exploitable vulnerability then it's not an exploitable vulnerability. (It's not exploitable for ad-hoc rather than systematic reasons, but anyone who's still using C in this day and age is already only avoiding exploitable vulnerabilities through ad-hoc rather than systematic reasons, so that doesn't seem like a reason to rush out a fix).