Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1464687 - There was a stack overflow caused by array out of bound write in fmt_entry function in ncurses tool with latest verison(6.0). Crafted input could lead to arbitrary code execution.
There was a stack overflow caused by array out of bound write in fmt_entry fu...
Status: CLOSED DUPLICATE of bug 1473302
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ncurses (Show other bugs)
7.5-Alt
x86_64 Linux
unspecified Severity urgent
: rc
: ---
Assigned To: Miroslav Lichvar
BaseOS QE - Apps
:
: 1464685 1464688 1464692 (view as bug list)
Depends On:
Blocks: CVE-2017-10684
  Show dependency treegraph
 
Reported: 2017-06-24 10:34 EDT by owl337
Modified: 2017-07-26 09:13 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-07-26 09:13:03 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Triggered by "captoinfo POC4" (218 bytes, application/x-rar)
2017-06-24 10:34 EDT, owl337
no flags Details

  None (edit)
Description owl337 2017-06-24 10:34:06 EDT
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):

<=6.0

How reproducible:

infotocap $POC

Steps to Reproduce:


The debug information is as follows:

$gdb infotocap
…
(gdb) set args $POC
 (gdb) b dump_entry.c:1143 // the stack overflow related caller point
 (gdb) r 
... 
(gdb) x/10i 
$pc => 0x41621c <dump_entry+1724>: mov %r14d,%r8d 0x41621f 
<dump_entry+1727>: mov 0x3c(%rsp),%r9d 0x416224 
<dump_entry+1732>: callq 0x410150
 <fmt_entry> 0x416229 
<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
<dump_entry+1737>
 (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
 (gdb) c
 Continuing. 
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
…
 (gdb) x/10i 
$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

Actual results:

specified function return address be covered
crash

Expected results:

crash

Additional info:

Credits:

This vulnerability is detected by team OWL337, with our custom fuzzer coll AFL. Please contact ganshuitao@gmail.com  and chaoz@tsinghua.edu.cn if you need more info about the team, the tool or the vulnerability.
Comment 2 owl337 2017-06-24 10:40:07 EDT
It is duplicated with id=1464687 for wrong submitting.
Comment 3 Miroslav Lichvar 2017-06-27 11:17:54 EDT
*** Bug 1464688 has been marked as a duplicate of this bug. ***
Comment 4 Thomas E. Dickey 2017-06-27 20:13:20 EDT
This appears to be a duplicate, because once POC1-POC3 are addressed this is no longer reproducible.
Comment 5 owl337 2017-06-27 20:25:06 EDT
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.
Comment 6 Thomas E. Dickey 2017-06-27 20:32:40 EDT
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.
Comment 7 owl337 2017-06-27 20:58:32 EDT
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?
Comment 8 Thomas E. Dickey 2017-06-27 21:04:24 EDT
I'll factor that out (not enough time tonight, but this week sometime).
Comment 9 owl337 2017-06-27 21:35:36 EDT
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.
Comment 10 Thomas E. Dickey 2017-06-28 05:12:26 EDT
This one is a duplicate of the one presented with POC2.
Comment 11 Thomas E. Dickey 2017-06-28 05:18:28 EDT
Reviewing my changes, I changed 4 lines of code to address 4 bug reports.
Comment 12 Thomas E. Dickey 2017-06-28 05:23:30 EDT
Sorry - "5 lines" (POC2 took 2 lines).  If your report had included fixes, you would have noticed that POC4 is a duplicate.
Comment 13 owl337 2017-06-28 05:32:58 EDT
where are your changeLog? I'd like to review.
Comment 14 Thomas E. Dickey 2017-06-28 18:01:10 EDT
That will be noted here:

http://lists.gnu.org/archive/html/bug-ncurses/

when this week's batch of changes are released.
Comment 15 owl337 2017-06-28 22:51:38 EDT
Ok,I will be concerned about the fixes on this two high risk vulnerabilities.
Comment 16 Miroslav Lichvar 2017-06-29 03:58:20 EDT
*** Bug 1464692 has been marked as a duplicate of this bug. ***
Comment 17 Miroslav Lichvar 2017-06-29 04:03:18 EDT
*** Bug 1464685 has been marked as a duplicate of this bug. ***
Comment 19 Thomas E. Dickey 2017-07-01 08:53:17 EDT
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.
Comment 20 Miroslav Lichvar 2017-07-26 09:13:03 EDT

*** This bug has been marked as a duplicate of bug 1473302 ***

Note You need to log in before you can comment on or make changes to this bug.