[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Need -fno-stack-protector to prevent stack corruption



I not in the trap you describe. All the code is fresh compiled on 3.3
or from 3.3 packages. My OpenBSD 3.3 does not have libc.so.25.2.

Rebuilding python from the ports gets the same crash as well.

BArry

-----Original Message-----
From: Henning Brauer [mailto:lists-openbsdtech@bsws.de] 
Sent: 23 June 2003 21:28
To: tech@openbsd.org
Subject: Re: Need -fno-stack-protector to prevent stack corruption

On Mon, Jun 23, 2003 at 11:29:09AM +0100, Barry Scott wrote:
> We're just got to the bottom of a stack corruption in a python
extension
> written in C++.
> 
> I do not know the exact nature of the corruption but adding
> -fno-stack-protector fixes the crash.
> What we see is that the value returned from new is corrupted. The
value
> of this at the end of
> the c'tor was reasonable.
> 
> I can supply source code and test scripts that demonstrates the
problem
> against
> OpenBSD 3.3 Release.

it is quite easy to run into this trap.

say you have an application "X", compiled on an older OpenBSD version.
lets look at ldd output:
        -lpng.1 => /usr/local/lib/libpng.so.1.8
        -lc.25 => /usr/lib/libc.so.25.2
(I just left those two that are needed to demonstrate the problem).
we see it links to an older libc - it doesn't have __guard.
but you updated libpng. thus it needs __guard. libc is already loaded. 
no __guard symbol. kaboom.

clean solution: recompile the binary.

ugly hack:
  rm libc.so.25.2 && ln -s libc.so.29.0 libc.so.25.2
and hope the best.
This is so ugly and error prone that you better don't do it.
you've been warned.

-- 
http://2suck.net/hhwl.html - http://www.bsws.de/
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)