[gentoo-hardened] [INFO] SSP protecting glibc functions

[Alexander Gabert]

-----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+ZYuQbRXFBvEKACgg8QP
BivJ0m7N4jRhfCvw24tkkHc=
=2131
-----END PGP SIGNATURE-----
-- 
gentoo-hardened@g.o mailing list