New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
isisd: overflow bugs in unpack_tlv_router_cap #10507
Comments
|
Issues on stream_forward_getp: Also in the loop shown above, at Line 3015, Line 3020, Line 3045, Line 3054, Line 3061, Line 3066, Line 3097, Line 3107, and Line 3110, when we call |
|
Issues on stream_get: Also in the loop shown above, at Line 3049, when we call |
|
Integer overflow bugs: Also in the loop shown above, at Line 3043 and Line 3090, when we do the operation And I think the following code at Lines 3045 and 3092 should be |
|
Heap overflows: Also in the loop shown above, at Line 3031 and Line 3078, the operation |
|
Hi! Are you fuzzing or auditing manually? |
Hi, I am using FRR in one of our projects and trying to test its reliability. You can regard it as a kind of testing. I carefully went through every problem I found and reported the issue only when I thought it is really a problem. I also tried to propose fixes as I also want to make contributions to FRR's community. |
|
Yes, your reports are good quality and appreciated. I'm just curious what techniques you're using to find the issues. Are you part of a group? Others seem to be reporting the same type of issues recently. |
|
Please check PR #9850. |
|
#10517 is now merged, could you please check if it fixes all reported issues? |
Yes, I think all are fixed. This issue can be closed. Thanks for your great efforts! |
|
Thanks for reporting! |
|
This was assigned CVE-2022-26125. |
|
Yeah, so...this is an assertion failure unless I'm reading the issue wrong. We push a stream buffer until a point where automatic bounds checks kick in and terminate the program to prevent a buffer overflow. Yet this is labeled as a buffer overflow and assigned a CVE score of 7.8. @00xc @whichbug can one of you guys clarify the situation here? |
I guess the problem is that the assertion failures are caused by potential overflows. The CVE score could be reduced. |
|
There are no potential overflows. The potential for overflow is eliminated by the assert. That's the whole point of the assert, that's why we put it there. Since it sounds like you agree with my assessment, can you work with the CVE people to fix the CVE you filed? Frankly I don't even think this deserves a CVE but if you are set on filing them, please make sure you accurately report the problem. So that you have some insight into what happens when the CVE process is used, we now have people from Debian emailing us regarding the high-severity CVEs you've filed for these issues. So now that I've found that this one isn't accurate, now I have to go through and cross check each of your reports against the CVEs you've filed to make sure they're actually accurate. On that topic, usually when you file CVEs against projects, it's expected that you work with the people who run the project to agree on a characterization of what is going to be filed and when it's going to be disclosed. Unless we missed some communication from you, you haven't done that, which is inconsiderate to us. We're volunteers, not a major company selling a product. We aren't going to sue you to prevent you from filing CVEs. We have an established process for reporting security vulnerabilities that's in the project README. Your research is appreciated but please, follow common practices, spend the time to reach out and work with us regarding reporting and disclosure. |
|
@00xc @whichbug By the way, if you guys are really interested in helping us with project security, we have a big list of issues just like this one found via our own security processes (such as Coverity, LLVM scan-build, ClusterFuzz, etc) that we need help fixing. Let me know if you're interested in contributing and I'll get you connected with our services so we can get some patches rolling. |
Thanks for your information. It looks good to me if I can contribute. You see I always tried to fix these reported bugs. |
I have sent a request to update. I think it will be updated soon. |
I don't think this was directed to me, but to be clear, I did not request the CVE, I just tried to make everyone aware. For what is worth, I updated our downstream CVSS score for this issue accordingly. Hopefully MITRE will do the same soon.
Not that my personal opinion matters much here, but a remotely reachable assertion (i.e. remote DoS) seems severe enough, although I might be missing something. |
frr/isisd/isis_tlvs.c
Lines 3004 to 3114 in 18ed776
There are a few issues in the loop above leading to overflow vulnerabilities. The loop condition is
subtlv_len > 2andsubtlv_lenis updated at the end of the loop (Line 3113:subtlv_len = subtlv_len - length - 2).The Issue on Loop Condition: at Line 3113, when we update
subtlv_len, ifsubtlv_len < length + 2, integer overflow will happen, leading to heap overflows in the next loop iteration. Note thatsubtlv_lenandlengthare ofuint8_t, which makes it easy to overflow, e.g.,subtlv_len=35,length=38... An example output of the address sanitizer can be found below:Other Issues: at Line 3016, Line 3021, Line 3062, Line 3067, and Line 3098, I think we need to use
breakinstead ofcontinue. Usingcontinuewill let us miss the update of the loop condition variable at Line 3113.Please check if my understanding of the code above is correct. If so, I can make a pull request to fix these issues then.
The text was updated successfully, but these errors were encountered: