Red Hat Bugzilla – Bug 159196
multiple memory management issues
Last modified: 2007-11-30 17:11:07 EST
After your recent fixes for strace crashes, I reviewed strace for other memory management issues. I found 8 bugs which could lead to easily reproduced crash, and 4 bugs which are unlikely to be triggered. Still unclear, whether some of these overflows could lead to privilege escalation or not, so setting "security" tag in case they are not just crash bugs.
Created attachment 114990 [details]
strace-4.5.11-alt-mem-fixes.patch for cvs snapshot 20050526
Created attachment 114992 [details]
This program demonstrates crash in print_xattr_val().
Test with "strace -e trace=fsetxattr ./xattr".
Created attachment 114993 [details]
This program demonstrates crash in tprint_iov().
Test with "strace -e trace=writev ./iov".
Created attachment 114994 [details]
This program demonstrates crash in get_nodes().
Test with "strace -e trace=get_mempolicy ./nodes".
Created attachment 114996 [details]
This program demonstrates crash in printcmsghdr().
Test with "strace -e trace=sendmsg ./msg".
Created attachment 114997 [details]
This program demonstrates another crash in printcmsghdr().
Test with "strace -e trace=sendmsg ./msg2".
Created attachment 114998 [details]
This program demonstrates crash in sys_setgroups32().
Test with "strace -e trace=setgroups32 ./setgroups".
Created attachment 114999 [details]
This program demonstrates crash in sys_poll().
Test with "strace -e trace=poll ./poll".
Created attachment 115000 [details]
This program demonstrates crash in sys_sysctl().
Test with "strace -e trace=_sysctl ./sysctl".
Well, it is not easy to use these bugs to get something more than instant crash.
Let's remove "security" tag then?
Thanks for all those test cases, and the fixes! I've put the patch in upstream.
I'll check with our security folks whether they think these problems need to be
treated as security issues.
If there is no potential for arbitrary code execution, then I don't see any of
these as being security issues.
I also do not think these are security bugs. That's because the program being
traced is already granted the ability to execute arbitrary code/syscalls.
strace is not a policy enforcement tool, and not even an interactive debugger
where one may single-step or the like not letting the program do nasty things.
But we need to get the bugs fixed indeed.
(Should the Summary read "multiple", not "multiply"?)
I know that strace is oftenly used by root user to trace various applications,
including less privileged ones. These bugs allow applications to overwrite
arbitrary address of strace memory, but I found no way (yet?) how it can be used
to gain control over strace itself. Ok, lets hope it is not possible.
Oh, you're referring to strace's ability to attach to already-executing
processes, which may be _known_ to be _already_ running as non-root, correct?
This is something I've overlooked when writing my previous comment.
OK, these may be security bugs, then.
These fixes are in the upstream cvs, lifting embargo.
Fixed in strace-4.5.12.