From patchwork Mon Aug 10 18:04:28 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alex Dowad X-Patchwork-Id: 8123 Received: (qmail 75298 invoked by alias); 10 Aug 2015 18:04:41 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 75287 invoked by uid 89); 10 Aug 2015 18:04:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wi0-f176.google.com X-Received: by 10.180.90.198 with SMTP id by6mr18183976wib.82.1439229875502; Mon, 10 Aug 2015 11:04:35 -0700 (PDT) From: Alex Dowad To: libc-alpha@sourceware.org Subject: [PATCH v4] Don't allow attackers to inject arbitrary data into stack through LD_DEBUG Date: Mon, 10 Aug 2015 20:04:28 +0200 Message-Id: <1439229868-20746-1-git-send-email-alexinbeijing@gmail.com> C programs which use uninitialized stack variables can be exploited if an attacker can control the contents of memory where the buggy function's stack frame lands. If the buggy function is called very early in the program's execution, that memory might still hold values written by ld.so, so manipulation of ld.so is one way to carry out such an exploit. But how can an unprivileged user, running a set-UID program, cause ld.so to write arbitrary data onto the stack? One way is to assign it to LD_DEBUG. When printing the resulting warning message, ld.so uses alloca to create a buffer on the stack, and copies the entire contents of LD_DEBUG into it (even if it is dozens of kilobytes long). Of course, people shouldn't write programs which use uninitialized variables, but it is easy enough to plug this hole if they do. Simply avoid copying the string onto the stack. Because the string may not be null-terminated, we need to provide a string length to _dl_error_printf. --- As suggested by Paul Eggert, the warning message printed when LD_DEBUG has an unrecognized value is now limited to a reasonable length. elf/dl-misc.c | 7 ++++--- elf/rtld.c | 9 +++++---- 2 files changed, 9 insertions(+), 7 deletions(-) diff --git a/elf/dl-misc.c b/elf/dl-misc.c index 8fd6710..81b332c 100644 --- a/elf/dl-misc.c +++ b/elf/dl-misc.c @@ -143,7 +143,7 @@ _dl_debug_vdprintf (int fd, int tag_p, const char *fmt, va_list arg) ++fmt; } - /* See whether with comes from a parameter. Note that no other + /* See whether width comes from a parameter. Note that no other way to specify the width is implemented. */ if (*fmt == '*') { @@ -205,9 +205,10 @@ _dl_debug_vdprintf (int fd, int tag_p, const char *fmt, va_list arg) case 's': /* Get the string argument. */ iov[niov].iov_base = va_arg (arg, char *); - iov[niov].iov_len = strlen (iov[niov].iov_base); if (prec != -1) - iov[niov].iov_len = MIN ((size_t) prec, iov[niov].iov_len); + iov[niov].iov_len = strnlen (iov[niov].iov_base, (size_t) prec); + else + iov[niov].iov_len = strlen (iov[niov].iov_base); ++niov; break; diff --git a/elf/rtld.c b/elf/rtld.c index 6dcbabc..088431e 100644 --- a/elf/rtld.c +++ b/elf/rtld.c @@ -2404,10 +2404,11 @@ process_dl_debug (const char *dl_debug) if (cnt == ndebopts) { /* Display a warning and skip everything until next - separator. */ - char *copy = strndupa (dl_debug, len); - _dl_error_printf ("\ -warning: debug option `%s' unknown; try LD_DEBUG=help\n", copy); + separator. */ + int deblen = MIN(len, 100); + _dl_error_printf ("warning: debug option '%.*s%s' unknown;" + " try LD_DEBUG=help\n", + deblen, dl_debug, len <= 100 ? "" : "..."); } dl_debug += len;