Created attachment 1291507 [details]
Triggered by "captoinfo POC4"
Description of problem:
n the loop for_each_string(j, tterm) of fmt_entry function( line:725), there was array out of bound write for the buffer that led to the return address of fmt_entry function was covered later.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
The debug information is as follows:
(gdb) set args $POC
(gdb) b dump_entry.c:1143 // the stack overflow related caller point
$pc => 0x41621c <dump_entry+1724>: mov %r14d,%r8d 0x41621f
<dump_entry+1727>: mov 0x3c(%rsp),%r9d 0x416224
<dump_entry+1732>: callq 0x410150
<dump_entry+1737>: cmpl $0x0,0x34(%rsp) ...
(gdb) si //3 times
(gdb) i r $rsp rsp 0x7fffffffb2e8
(gdb) x/4x $rsp
0x7fffffffb2e8: 0x29 0x62 0x41 0x00 // the ret address
(gdb) b dump_entry.c:725
(gdb) c //repeat 9 times
(gdb) b dump_entry.c:724
(gdb) c //repeat 24 times
(gdb) b dump_entry.c:838
Breakpoint 18, fmt_entry (tterm=0x675430, pred=<optimized out>, content_only=<optimized out>, suppress_untranslatable=0, infodump=0, numbers=0) at ../progs/dump_entry.c:838
838 len += (int) strlen(capability) + 1;
(gdb) x/4x 0x7fffffffb2e8 //check the ret address again
0x7fffffffb2e8: 0x2f 0x25 0x7b 0x31 //it was overflowed
(gdb) continue //until the function return
Program received signal SIGSEGV, Segmentation fault. 0x00000000004135ee in fmt_entry (tterm=<optimized out>, pred=<optimized out>, content_only=<optimized out>, suppress_untranslatable=<optimized out>, infodump=<optimized out>, numbers=<optimized out>) at ../progs/dump_entry.c:984
$pc => 0x4135ee <fmt_entry+13470>: retq 0x4135ef
<fmt_entry+13471>: movslq %fs:(%r14),%rax ...
(gdb) x/4x 0x7fffffffb2e8 //check the ret address again, it was
// overflowed by 0x2f 0x25 0x7b 0x31
0x7fffffffb2e8: 0x2f 0x25 0x7b 0x31
specified function return address be covered
This vulnerability is detected by team OWL337, with our custom fuzzer coll AFL. Please contact firstname.lastname@example.org and email@example.com if you need more info about the team, the tool or the vulnerability.
It is duplicated with id=1464687 for wrong submitting.
*** Bug 1464688 has been marked as a duplicate of this bug. ***
This appears to be a duplicate, because once POC1-POC3 are addressed this is no longer reproducible.
Did you mean the overflow point in POC4 is covered by POC1-POC3?
Anyway, before your fixes, the POC4 is close to being arbitrary code execution.
I suppose you could devise an interesting (but unlikely) use case illustrating what you're suggesting. But this particular report is no longer of interest.
As my description, the return address of fmt_entry is overflowed by POC4 which has enough illustrated the buffer overflow will cause arbitrary code execution attack. Can you tell me which poc in POC1-POC3 cover this POC4?
I'll factor that out (not enough time tonight, but this week sometime).
This test case is the most detailed of all POCs, there is no reason to refuse serious influence.
Even if the overflow points are the some point, no one will understand why only accept Null Pointer Dereference and reject Funtion Return Address be overflowed. Could you give priority to more serious vulnerabilities?
Moreover, the overflow point in bug 1464691 is not the same as this one, it is happened at the format string funtion as my description.
This one is a duplicate of the one presented with POC2.
Reviewing my changes, I changed 4 lines of code to address 4 bug reports.
Sorry - "5 lines" (POC2 took 2 lines). If your report had included fixes, you would have noticed that POC4 is a duplicate.
where are your changeLog? I'd like to review.
That will be noted here:
when this week's batch of changes are released.
Ok,I will be concerned about the fixes on this two high risk vulnerabilities.
*** Bug 1464692 has been marked as a duplicate of this bug. ***
*** Bug 1464685 has been marked as a duplicate of this bug. ***
Actually, Red Hat's packages use stack-protection. When you recompiled ncurses to investigate the error-exit caused by that feature, it was using different compiler-flags than their package. If you had used the same compiler-flags, you probably could not have seen the issue in the debugger.
The report is useful, and is addressed upstream, but the urgency has not been demonstrated. For that, you'd have to construct an exploit against their existing packages.
*** This bug has been marked as a duplicate of bug 1473302 ***