bugtraq - Re: [ANNOUNCE] glibc heap protection patch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3FCC9BBE.60604@suspekt.org>
Date: Tue, 02 Dec 2003 15:03:42 +0100
From: Stefan Esser <stefan@...pekt.org>
To: William Robertson <wkr@...ucsb.edu>
Cc: sectools@...urityfocus.com, bugtraq@...urityfocus.com,
	focus-ids@...urityfocus.com
Subject: Re: [ANNOUNCE] glibc heap protection patch

Hello,

I looked onto your site for a few seconds and saw that you use magic
values.

> I'd just like to announce that we have a heap protection system for 
> glibc available for download. The system detects and prevents all heap 
> overflow exploits that modify inline control information from succeeding 
> against a protected application, can be installed system-wide or on a 
> per-process basis using LD_PRELOAD, and is transparent to existing 
> applications.

Nice advertisement but you should underline the fact, that it only
protects against glibc malloc()/free() problems. There are a number
of software packages that implement their own heap wrappers or work
with linked lists. They still are vulnerable to heap overflows.
f.e. PHP.

And on the other hand there is a much simpler way to protect any
unlink from a linked list from ever beeing exploited.

1.5 years ago I added code to my glibc (and to the PHP malloc/free
wrappers (only on my system cause PHP group wanted this code
not in official Zend Engine)) that simply checks on unlink if my
backward pointed block really points with his forward pointer
to me and if my forward pointed block points with his backward
pointer to me. This makes the unlink process unexploitable, while
your approach is still attackable if someone guessed the magic
value. (Even if that sounds unrealistic it is still possible.)

The unlink macro would then look like

#define unlink(P, BK, FD) { \
FD = P->fd; \
BK = P->bk; \
if (FD->bk != P || BK->fd != P) ATTACK_ON_UNLINK; \
FD->bk = BK; \
BK->fd = FD; \
}

(I am writing this down from my memory, I have the code
not here at the moment)

Stefan Esser

---------------------------------------------------------------------------
---------------------------------------------------------------------------