| Summary: | sha512-crypt.c usage of alloca() unbounded | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Russell Bryant <rbryant> |
| Component: | glibc | Assignee: | Jeff Law <law> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 16 | CC: | dprince, fweimer, jlieskov, pbrady, rbryant, security-response-team |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-03-29 18:50:36 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Russell Bryant
2012-03-19 19:32:43 UTC
Thanks for the archive link. I meant to post that ... pbrady pointed that out to me before I posted this. It wasn't clear if the issue was ever reported anywhere and the code appears to still be the same, so I figure it should be reported. Also, the original reporter of this issue to OpenStack was Dan Prince (dprince). Though we understand the potential negative implications, this deficiency might have on packages / code using glibc's sha512-crypt module's routines, we would not classify this bug to be a security issue in glibc. Explanation: The currently seen behaviour is expected in the sense of the way how alloca() system call is intended to be used (to allocate space in the stack frame of the caller and automatically free the allocated space when the function from which alloca() was called returned). When the size of memory to be allocated in this temporary space would not fit into the stack frame of the caller (IOW by attempt to write at memory location past the stack frame of the caller), it is expected the application to be terminated. The only consequence of this behaviour (when very long password strings are used) is the termination (crash) of the application. But isn't blowing out the stack subject to the kind of attacks seen in CVE-2012-0864 where passing a "clever" value to alloca causes the stack pointer to point into the heap and the potentially opening up all kinds of interesting attack vectors. Fixed in rawhide, f17 & rhel 7 trees. Not currently planning to backport to f15, f16, rhel5 or rhel6. OpenStack Keystone was changed to limit the length of the passwords it processes - see bug #805551. glibc upstream list on the Jeff's patch to make crypt implementation use malloc instead of alloca for long inputs: http://sourceware.org/ml/libc-alpha/2012-03/msg01138.html http://sourceware.org/ml/libc-alpha/2012-03/msg01158.html |