RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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.
Summary: There was a stack overflow caused by array out of bound write in fmt_entry fu...
Keywords:
Status: CLOSED DUPLICATE of bug 1473302
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ncurses
Version: 7.5-Alt
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: rc
: ---
Assignee: Miroslav Lichvar
QA Contact: BaseOS QE - Apps
URL:
Whiteboard:
: 1464685 1464688 1464692 (view as bug list)
Depends On:
Blocks: CVE-2017-10684
TreeView+ depends on / blocked
 
Reported: 2017-06-24 14:34 UTC by owl337
Modified: 2017-07-26 13:13 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-07-26 13:13:03 UTC
Target Upstream Version:
Embargoed:

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

Description owl337 2017-06-24 14:34:06 UTC 
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  and chaoz.cn if you need more info about the team, the tool or the vulnerability.
Comment 2 owl337 2017-06-24 14:40:07 UTC 
It is duplicated with id=1464687 for wrong submitting.
Comment 3 Miroslav Lichvar 2017-06-27 15:17:54 UTC 
*** Bug 1464688 has been marked as a duplicate of this bug. ***
Comment 4 Thomas E. Dickey 2017-06-28 00:13:20 UTC 
This appears to be a duplicate, because once POC1-POC3 are addressed this is no longer reproducible.
Comment 5 owl337 2017-06-28 00:25:06 UTC 
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-28 00:32:40 UTC 
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-28 00:58:32 UTC 
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-28 01:04:24 UTC 
I'll factor that out (not enough time tonight, but this week sometime).
Comment 9 owl337 2017-06-28 01:35:36 UTC 
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 09:12:26 UTC 
This one is a duplicate of the one presented with POC2.
Comment 11 Thomas E. Dickey 2017-06-28 09:18:28 UTC 
Reviewing my changes, I changed 4 lines of code to address 4 bug reports.
Comment 12 Thomas E. Dickey 2017-06-28 09:23:30 UTC 
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 09:32:58 UTC 
where are your changeLog? I'd like to review.
Comment 14 Thomas E. Dickey 2017-06-28 22:01:10 UTC 
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-29 02:51:38 UTC 
Ok,I will be concerned about the fixes on this two high risk vulnerabilities.
Comment 16 Miroslav Lichvar 2017-06-29 07:58:20 UTC 
*** Bug 1464692 has been marked as a duplicate of this bug. ***
Comment 17 Miroslav Lichvar 2017-06-29 08:03:18 UTC 
*** Bug 1464685 has been marked as a duplicate of this bug. ***
Comment 19 Thomas E. Dickey 2017-07-01 12:53:17 UTC 
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 13:13:03 UTC 

*** 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.