This site is now 100% read-only, and retired.

Stack Smashing Protection for Debian

Posted by Steve on Fri 23 Jun 2006 at 14:02

Since we last covered the use of Stack Smashing Protection (SSP) the default compiler for Debian Sid has been upgraded to include it, with no need for custom patching. Read on for a brief demonstration of how it can be used to prevent attacks.

The default C compiler for Sid, which will be used in Etch too, is GCC v4.1. This releasecontains the SSP patch which previously needed to be applied manually (we demonstrated applying this patch for GCC v3.4 a long time ago).Since the SSP patch is included in the compiler by default it is suddenly a lot easier to start working with it.

A vulnerable Program

Lets look at an example first of all, this is a common sample of a vulnerable C program:

#include <stdio.h>
#include <stdlib.h>

int main( int argc, char *argv[] )
{
   // Static buffer on the stack.
   char buffer[1024];

   if ( argc != 2 )
   {
      printf("Usage: %s argument\n", argv[0] );
      return( -1 );
   }
 
   // Unbound string copy.
   strcpy( buffer, argv[1]);

   printf( "Copied argument\n" );

   return(0);
}

This simple program accepts one argument and copies it into a static buffer. This is a classic programming mistake, and were this program compiled into a setuid/setgid binary it would easily allow an attacker to gain enhanced privileges.

Since we're going to highlight the new facilities of the newer compiler be sure to compile this example with gcc-3.3.

To test this program compile it as normal:

skx@desktop:/tmp$ gcc-3.3 -o buggy buggy.c

Now lets see if we can break it. First of all two test executions:

skx@desktop:/tmp$ /tmp/buggy
Usage: /tmp/buggy argument
skx@desktop:/tmp$ /tmp/buggy test
Copied argument

Both of these runs worked as expected. Now lets try passing a large argument to see if we can overflow the static buffer:

skx@desktop:/tmp$ ./buggy `perl -e 'print "X"x2048'`
Copied argument
Segmentation fault

Success: we overflowed the buffer with our 2k argument, and we resulted in a segmentation fault. If we can produce a core file we can debug this:

skx@desktop:/tmp$ ulimit -c 09999999
skx@desktop:/tmp$ ./buggy `perl -e 'print "X"x3333'`
Copied argument
Segmentation fault (core dumped)

Running gdb we can now look at the program:

skx@desktop:/tmp$ gdb ./buggy core
GNU gdb 6.4.90-debian
...
Program terminated with signal 11, Segmentation fault.
#0  0x58585858 in ?? ()
(gdb) info registers eip
eip            0x58585858       0x58585858

Here we see the instruction pointer is at 0x58585858 (the hex for 'X' is 0x58). This means we've effectively taken control of the binary with our malicious input.

From here to actually exploiting the binary to run a shell is trivial and can frequently be automated:

skx@desktop:~/cvs/cmd-overflow$ make
gcc-3.3 -o cmd-overflow -Wall -ggdb cmd-overflow.c
gcc-3.3 -o cmd-vuln -Wall -ggdb cmd-vuln.c
skx@desktop:~/cvs/cmd-overflow$ ./cmd-overflow --target=/tmp/buggy --args='%' --size=2048
Copied argument
sh-3.1$ id
uid=1000(skx) gid=1000(skx) groups=29(audio),44(video),46(plugdev),100(users),1000(skx)
sh-3.1$ exit
exit

Here we used a simple program to create an argument of length 2048 bytes which contains the code required to run a shell, then invoked our buggy program with this constructed argument.

The buffer was then overflowed and our code ran, this resulting in a shell being executed. ("Shellcode"). Had our buggy program been setuid we'd have gained root privileges!

Note:

Starting sometime in the life of the Linux 2.6.x kernel series a new security measure was introduced, to randomise heap addresses. If you're running such a kernel all of these examples will fail.

To disable this protection run:

root@desktop:~# sysctl -w kernel.randomize_va_space=0

This will allow you to experiment with buffer overflows, whilst avoiding the need to use advanced exploitation techniques. (Which can be a lot of fun if you're bored :)

Preventing This Attack With SSP

Now that Debian contains the 4.1 compiler we can use the new -fstack-protector argument to compile in automatic buffer overflow protection.

Before we do this we'll need to install a new package:

desktop:~# apt-get install libssp0-dev
Reading package lists... Done
Building dependency tree... Done
The following extra packages will be installed:
  libssp0
Suggested packages:
  lib64ssp0
The following NEW packages will be installed
  libssp0 libssp0-dev

Once this is installed we can recompile our buggy program:

skx@desktop:/tmp$ gcc-4.1 -fstack-protector -o buggy buggy.c
buggy.c: In function ��main��:
buggy.c:16: warning: incompatible implicit declaration of built-in function ��strcpy��

This binary should now be protected against simple buffer overflows. Let us test it as we did before:

skx@desktop:/tmp$ ./buggy `perl -e 'print "x"x2048';`
Copied argument
*** stack smashing detected ***: xxxx .. xxxx terminated
Illegal instruction

Neat, huh?

Now we'll try to repeat the exploitation which succeeded previously:

skx@desktop:~/cvs/cmd-overflow$ ./cmd-overflow --target=/tmp/buggy --size=2048 --args='%'
Copied argument
*** stack smashing detected ***: terminated
Illegal instruction

It all looks good, and the protection works as designed. (Note that this protection will not help against "advanced" exploitation, such as return into libc.

Using this library you can add simple buffer overflow protection to your binaries with only a minor performance hit. If you maintain a package it might be worth rebuilding using this support to see how well it works in practise.

Rebuilding all the packages on security-critical host might be something worth trying, now that the tools are easily available.

 

 


Re: Stack Smashing Protection for Debian
Posted by Anonymous (137.110.xx.xx) on Fri 23 Jun 2006 at 19:25
SSP should prevent 'return-into-libc' due to the canary being overwritten when changing the return address. Wikipedia says about return-into-libc via the link you provided, "Stack-smashing protection can prevent or obstruct exploitation, as it can detect the corruption of the stack.".

[ Parent ]

Re: Stack Smashing Protection for Debian
Posted by Steve (62.30.xx.xx) on Fri 23 Jun 2006 at 20:41
[ View Weblogs ]

There are papers discussing weaknesses in stackguard, ssp, and similar technologies. The first one I came across with a quick search was this one - caution PDF.

Some of the references aren't valid, but sites such as Phrack have covered this stuff previously too.

Steve

[ Parent ]

Re: Stack Smashing Protection for Debian
Posted by Anonymous (81.57.xx.xx) on Sat 24 Jun 2006 at 16:30
Are there any hope that the use of -fstack-protecor become one of the defaults CFLAGS for building debian packages (as it is the whole Fedora Core build, and also OpenBSD forn a long time, and -with an equivalent for vc++- Windows 2003) ? Would be neat to have a protected archive !

Or at least, would the maintainers of sensitives (network services and clients, suid/sgid binaries, ...) packages think about using this ?

As a side benefit, not speaking about security, this gcc features make those kinds of bugs more visibles and more debugguables (segfaulting & logging is better than accepting silently corrupted data structures, from a bughunting viewpoint).

[ Parent ]

Re: Stack Smashing Protection for Debian
Posted by Steve (62.30.xx.xx) on Sat 24 Jun 2006 at 16:37
[ View Weblogs ]

I'd love to see it personally. The only way I see it happening is if many maintainers would test their packages with the new flag and see what breaks.

The more people that test it the better chances we have of making it the default behaviour; hence this introduction.

Steve

[ Parent ]

Re: Stack Smashing Protection for Debian
Posted by Anonymous (81.57.xx.xx) on Sun 25 Jun 2006 at 12:07
Well, there's no much risk for this to become a release blocker:

- The gcc option can be inhibited for any problematic package (at the end of the day, any possible bug introduced in a package by SPP can be fixed with a one-liner in debian/rules - no long standing RC bugs).

- Being on by default in Fedora Core 5, most packages (and at least, the vital ones) had been tested with SPP. Also, Debian-Hardened, Gentoo-Hardened and OpenBSD had cleaned the road for us with propolice. The later (OpenBSD) runs on about the same hardware architectures than Debian.

- If for whatever reason things goes too bad, removing this default behaviour would only imply recompiling the packages. It's not like the protected packages would become dependant of a functionality.

- If it has to be widely tested, it's the time to do it: before the (planned soon) toolchain freeze. Furthermore activating it require recompiling the archive, that's inconvenient for most developpers if they need to do it by themself: it won't be intensivly tested unless activated on the archive.


I hardly can see any dramatic effect of activating this by default, even if
bugs raises on.

[ Parent ]

Re: Stack Smashing Protection for Debian
Posted by Anonymous (84.194.xx.xx) on Mon 26 Jun 2006 at 08:55
The next Ubuntu release will include this compiling option in the next release (Ubuntu Edgy). It has been labeled as "must have" at the Ubuntu summit in Paris! Look at Enabling SSP for increased proactive security

Finally we see security measures against script kiddies as standards in operating systems.
Thanks for the article Steve ;)

Fred
Linox.BE

[ Parent ]

Re: Stack Smashing Protection for Debian
Posted by PJ_at_Belzabar_Software (59.176.xx.xx) on Mon 26 Jun 2006 at 05:02
[ View Weblogs ]
This was actually quite an educational breeze-through to stack smashing, along with fine examples for you to try. (Do try this at home, script kiddies!)

Every larval cracker should bookmark this splendid article along with the classic
phrack text "smashing the stack for fun and profit" (http://seclists.org/lists/bugtraq/1996/Nov/0017.html).





[ Parent ]

Re: Stack Smashing Protection for Debian
Posted by Steve (62.30.xx.xx) on Mon 26 Jun 2006 at 09:01
[ View Weblogs ]

All of this stuff is common knowlege to people who are interested in the topic, so I'm going to assume your sarcasm wasn't terribly serious.

After reading Aleph One's classic paper a good thing to read next is something about format string attacks, something I still struggle to exploit but other people can manage just fine!

Steve

[ Parent ]

Re: Stack Smashing Protection for Debian
Posted by PJ_at_Belzabar_Software (59.176.xx.xx) on Mon 26 Jun 2006 at 11:28
[ View Weblogs ]
I was approaching your article with a didactic [1] perspective, and I realised it was something a script kiddie could actually get their teeth into. Some script kiddies will never graduate, but for the ones that want to, you wrote something engaging, introductory, and easy to get into deeper.

No sarcasm intended in my previous post at all - it's just the way I burble on [5] sometimes.

[1] "didactic": for the pleasure of teaching [2]

[2] I am not trying to patronise [3] you with explaining the word didactic either, since I am pretty sure you know what it means. The footnote above was to help out the non-english people.

[3] "patronise": acting smug and superior (for the non-english speakers)

[4] you may note that this series of didactic footnotes is itself very didactic

[5] "burble on": (somewhat slang-like expression) meaning to go on and on like this.

[6] I'll get my coat now.

[ Parent ]

Re: Stack Smashing Protection for Debian
Posted by Steve (62.30.xx.xx) on Mon 26 Jun 2006 at 11:35
[ View Weblogs ]

Fair enough, I read your comment it in a sarcastic fashion, but I guess it is hard to tell a lot of the time.

Nice collection of footnotes!

For what its worth I think helping the kiddies actually do things for themselves rather than rely upon pre-cooked exploits is only liable to make them experiment more, and grow out of it. I guess that is part of the reason I rarely provide exploit code when I report vulnerabilities nowadays.

Steve

[ Parent ]

Re: Stack Smashing Protection for Debian
Posted by PJ_at_Belzabar_Software (59.176.xx.xx) on Mon 26 Jun 2006 at 12:17
[ View Weblogs ]
Exactly. Inside every script kiddy is a potential hacker (in the good, tinkering sense).

Following on from that line of thought, I've just added a poll to the queue, asking if any site visitors have ever run exploits themselves.

PJ

[ Parent ]

Re: Stack Smashing Protection for Debian
Posted by Steve (62.30.xx.xx) on Mon 26 Jun 2006 at 12:21
[ View Weblogs ]

I'd be happy to post a poll like that, but the options are way too long + complex.

Wanna try a simpler one?

Steve

[ Parent ]

Re: Stack Smashing Protection for Debian
Posted by PJ_at_Belzabar_Software (59.176.xx.xx) on Mon 26 Jun 2006 at 12:34
[ View Weblogs ]
Ah, well, let it be. That poll wouldn't work too well if I try to condense it that much. (You can cannibalise it yourself if you like - I have no hangups on that score).

all the best
PJ

[ Parent ]

Re: Stack Smashing Protection for Debian
Posted by toote (200.82.xx.xx) on Mon 26 Jun 2006 at 05:13
You can read this article in Spanish too: Desbordamiento de buffer

Thanks for such a good article Steve.

--
Because it's unnatural to read bottom-to-top
> Why is it so annoying?
>> 'cause it's completely annoying
>>> Why do you think top-posting is so bad?

[ Parent ]

Re: Stack Smashing Protection for Debian
Posted by simonw (212.24.xx.xx) on Mon 26 Jun 2006 at 14:09
[ View Weblogs ]
<blockquote>Starting sometime in the life of the Linux 2.6.x kernel series a new security measure was introduced, to randomise heap addresses.</blockquote>

Wikipedia says "2.6.12", but that might be simplifying a rather complex process down to one set of patches.

The article doesn't remind people to reenable the randomisation of address spaces ;)



[ Parent ]

Re: Stack Smashing Protection for Debian
Posted by Anonymous (213.5.xx.xx) on Tue 27 Jun 2006 at 01:12
Hm, doesn't work here.
Both the article's example program and cmd-vuln segfault but they're not exploitable (at least not by cmd-overflow anyway).
SSP doesn't detect a stack smashing either.

I run an up-to-date (as of today) Debian sid with Linux 2.6.15-1-686.
I did run 'echo 0 > /proc/sys/kernel/randomize_va_space' before trying.

Any thoughts?

[ Parent ]

Re: Stack Smashing Protection for Debian
Posted by Steve (62.30.xx.xx) on Tue 27 Jun 2006 at 06:32
[ View Weblogs ]

Compile the test programs with gcc-3.x?

Steve

[ Parent ]

Re: Stack Smashing Protection for Debian
Posted by Anonymous (196.12.xx.xx) on Wed 24 Jan 2007 at 12:24
Very useful Information ... Actually after encountering this problem I came to understand the vulnerability of my code

[ Parent ]

Re: Stack Smashing Protection for Debian
Posted by ronjohn (70.171.xx.xx) on Tue 8 May 2007 at 21:58
Now that it's May 2007, any more news on SSP?

How does one determine whether a package has been built with -fstack-protector?

[ Parent ]

Re: Stack Smashing Protection for Debian
Posted by Pooya (2.146.xx.xx) on Thu 6 Jan 2011 at 10:22
[ View Weblogs ]
i copied your buggy program on my ubuntu 10.10
and i downloaded cmd-overflow.c and compiled it by gcc.
but when i used ./cmd-overflow --target=/home/pooya/tmp/a.out --args='%' --size=2048

but didn't happen anything! just seg fault! :)
i think shell code need to change.
but what else should i change?

[ Parent ]

Re: Stack Smashing Protection for Debian
Posted by Steve (2001:0xx:0xx:0xxx:0xxx:0xxx:xx) on Thu 6 Jan 2011 at 11:48
[ View Weblogs ]

In the years since the code the kernel has had changes - asrl, and the compilers have ssp in by default. This article should be ignored.

If you want to make it work you'll need to study hard..

Steve

[ Parent ]

Re: Stack Smashing Protection for Debian
Posted by Pooya (2.146.xx.xx) on Thu 6 Jan 2011 at 12:11
[ View Weblogs ]
i know that compilers have ssp by default! but on our local computers we can turn off ssp or aslr or ...
i turned ssp of but cmd-overflow didn't work.

you said study hard. what do you mean? what should i study on?

tnx .

[ Parent ]

Re: Stack Smashing Protection for Debian
Posted by Steve (2001:0xx:0xx:0xxx:0xxx:0xxx:xx) on Thu 6 Jan 2011 at 12:15
[ View Weblogs ]

You have a segfault? You have a debugger? Thats what you should study in this case..

Steve

[ Parent ]

Re: Stack Smashing Protection for Debian
Posted by Anonymous (82.234.xx.xx) on Mon 7 Nov 2011 at 23:58
Does someone know where the lib64ssp0 vanished under Debian Squeeze ? I'm trying to compile a kernel with -fstack-protector-all and without this lib, it seems impossible.

[ Parent ]

Re: Stack Smashing Protection for Debian
Posted by suspended user alex_puchades (84.126.xx.xx) on Sun 29 Apr 2012 at 04:21
I have found a lot of mistakes in this post: firstly, randomize_va_space does not only randomize "heap addresses", it randomizes the entire virtual space (heap, stack, loaded libraries,...) except the prog's code section; secondly, the -fstack-protector places a "canary" between the stack vars and the saved eip, ebp, the args,... so that it protects us from a plain eip overwrite (which ret2libc is also based on, too) though it can be bypassed with rop and the like.

[ Parent ]