|Summary:||Harden TCB against stack protector bypass via overwrite of stack_guard|
|Product:||glibc||Reporter:||Ilya Smith <blackzert>|
|Component:||nptl||Assignee:||Not yet assigned to anyone <unassigned>|
|Severity:||enhancement||CC:||blackzert, carlos, drepper.fsp, fweimer, kamleshbhalui, rwmacleod, yann|
|Attachments:||Proof Of Concept|
Description Ilya Smith 2018-02-16 12:09:04 UTC
Created attachment 10825 [details] Proof Of Concept Stack protector ("canary") should protect application from been exploited by stack-based buffer overflows. It is placed on stack frame in function prologue and checked with some trusted value in function epilogue. For x86 and x86-64 architecture canary value is located in structure 'tcbhead_t' field 'stack_guard'. Special register ('gs' for i386 and 'fs' for x86-64) keeps pointer to this structure. tcbhead_t.stack_guard compared with one on stack to detect stack smashing. If application create new thread with pthread_create() function, tcbhead_t structure will be placed on the top of the stack thread, so stack canary protection could be easily bypassed - attacker just need to overflow enough bytes to rewrite tcbhead_t.stack_guard with controllable value. tcbhead_t should be removed from stack and allocated in separate region. Another good improvement here would be to generate new canary value for any thread. For now stack canary is the same as main thread and never changed.
Comment 1 Carlos O'Donell 2018-02-19 05:02:46 UTC
This is a "known issue" and has been reported several times in the past, including this 2013 public post on exactly this issue of TCB overwrite and stack canary changing: "TCB overwrite" http://bases-hacking.org/tcb-overwrite.html I agree with both of your comments, that moving the TCB away from the stack would help, and so would changing the canary value more often. Though these would require more consideration since the have an impact on core structures and algorithms. I'm marking this as an 'enhancement' bug.
Comment 2 Ilya Smith 2018-02-28 14:51:53 UTC
Hello! If I understand correct from here https://sourceware.org/glibc/wiki/Bugzilla%20Procedures, flag security- means non security bug. But this one is about SECURITY. So in my opinion this issue is security+. You may fix it as enhancement, but this would be a security enhancement. You may not fix it at all but your users are still under risk. This http://bases-hacking.org/tcb-overwrite.html is not a report. This bug just described one more time. But it was reported now and here. If I am wrong, please mark this bug as duplicate and provide a link on the previous ticket. Thanks
Comment 3 Carlos O'Donell 2018-02-28 16:03:49 UTC
(In reply to Ilya Smith from comment #2) > If I understand correct from here > https://sourceware.org/glibc/wiki/Bugzilla%20Procedures, flag security- > means non security bug. But this one is about SECURITY. So in my opinion > this issue is security+. Please review this document: https://sourceware.org/glibc/wiki/Security%20Process#What_is_a_security_bug.3F For this to be a security bug it has to meet the criteria we set out in that process for classifying security defects. As of today this issue is *not* considered a security issue, it is a post-attack mitigation, and we try to make that distinction very clear. We absolutely want to fix this, and improve the hardening the library has, but it must be weighed against other work that is being done in the project. Yes, overall, we discuss these issues under the broader umbrella term of "security", but we try to categorize our response based on exactly how the flaw plays into the various phases of attack or post-attack. I hope this explanation helps.