read-heap-buffer-overflow in ares_parse_soa_reply()

[ltx2018]

we found read-heap-buffer-overflow by fuzzing c-ares master-branch

lenth unchecked before read aptr

[ltx2018]

#332

[bradh352]

fixed by #332

[cebarks]

FYI this flaw was assigned CVE-2020-22217.

[samueloph]

NVD scored it as a critical:
https://nvd.nist.gov/vuln/detail/CVE-2020-22217

Sorry for the mention, but I think this might be of your interest @bagder

[cebarks]

NVD scored it as a critical: https://nvd.nist.gov/vuln/detail/CVE-2020-22217

Unfortunately, NVD scores almost everything a critical 9.8 anymore (usually against the wishes of the developers and other members of the security. Not to say they should be ignored, but take all of their ratings with a huge dash of salt.

Some more info:

• https://daniel.haxx.se/blog/2023/03/06/nvd-makes-up-vulnerability-severity-levels/
• https://daniel.haxx.se/blog/2023/06/12/nvd-damage-continued/
• https://daniel.haxx.se/blog/2023/09/05/bogus-cve-follow-ups/

[attritionorg]

If this is, indeed, an OOB read, then NVD scored incorrectly in this case. That said, I am not defending NVD as they frequently do not score correctly. That said, I want to point out that one part of CVSS specs says to "Score for the worst". That is one thing that leads to many v2 10 / v3 9.8 scores, especially when a vendor says e.g. "Vulnerability fixed". Without details orgs are forced to score like that, which may be artificially high of course.