SSP protecting glibc functions

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear Mr. Etoh,

i am asking myself the question whether compiling some
object code of
glibc makes sense with SSP being instrumented on some high
level user
visible glibc functions.

As far as my understanding goes, a user that is attacking an
executable
with malformed overflow data cannot get this
"overflow" data into glibc
functions directly anyway.

When a user is abusing a size restriction on the commandline
arguments
for example, the very long commandline argument argv[1] for
example is
put on the stack by the operating system kernel during
launching the ELF
binary.

Then the argument sits there for the badly written program
with a
vulnerable function to strcpy() it into a too small buf[].

The strcpy() function inside glibc is not vulnerable to this
attack
itself because it is receiving a pointer to the data that
has to be
copied as well as a pointer to the space in memory where it
has to be
stored.  It's just doing the work.

So, strcpy() begins happily copying the massive amount of
rubbish from
the long commandline argument upwards into the space on the
stack, which
is too small, thus overwriting room above the stack, which
happens to be
the frame pointer or return address of the function inside
the
executable that called strcpy() in glibc and the function
stack frame of
the function "above" on the stack.

But there is the __guard instrumented in the function of the
executable
compiled with SSP and all goes well because the guard is
destroyed and
the attack unveiled.



Now for theory, if there would be one or more glibc
functions, for
example one called glibc_vulnerable_func_with_buffer() that
takes data
as a pointer and copies it from the pointer into a local
buffer before
processing.  The buffer is too small and the copying of the
data
overwrites the stack frame of the glibc internal function
upwards.

To protect our said glibc function from overwriting the
local buffer and
overwriting the stack frame of itself we would be forced to
instrument
SSP on these internal glibc functions too, right?

And if yes, i would need to search explicitly for glibc
functions taking
data from user programs and copying the data around inside
their own
local buffers in the glibc using unsafe and
overflow-possible strcpy()
instead of length-limited versions like strncpy(), right?


Perhaps, can you shed some light on these thoughts, am i
right or is
there a technical mistake i have not recognized?

Regards and thanks for your work,


Alex
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


iD8DBQFFF2SylpSgoWRXlxURAgDCAJ9wdrnf4/z9AuPG+ZYuQbRXFBvEKACg
g8QP
BivJ0m7N4jRhfCvw24tkkHc=
=2131
-----END PGP SIGNATURE-----
-- 
gentoo-hardenedgentoo.org mailing list

On Mon, 25 Sep 2006 07:10:10 +0200
Alexander Gabert <a.gabertfh-trier.de> wrote:

> i am asking myself the question whether compiling some
object code of
> glibc makes sense with SSP being instrumented on some
high level user
> visible glibc functions.

The point of building glibc with SSP enabled has to be to
protect
against bugs in glibc itself.  Clearly one would hope that
glibc
doesn't contain any such bugs, and we have no evidence to
suggest that
it does, however the possibility remains.

-- 
Kevin F. Quinn