New User? Register here - Existing Users: Username: Password: [Advanced Login]

 

 

Current Poll

Your preferred Interactive shell?









( 1026 votes ~ 11 comments )

 

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.

Share/Save/Bookmark


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 | Reply to this comment ]

Posted by Steve (62.30.xx.xx) on Fri 23 Jun 2006 at 20:41
[ Send Message | View Steve's Scratchpad | 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 | Reply to this comment ]

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 | Reply to this comment ]

Posted by Steve (62.30.xx.xx) on Sat 24 Jun 2006 at 16:37
[ Send Message | View Steve's Scratchpad | 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 | Reply to this comment ]

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 | Reply to this comment ]

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 | Reply to this comment ]

Posted by PJ_at_Belzabar_Software (59.176.xx.xx) on Mon 26 Jun 2006 at 05:02
[ Send Message | 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 | Reply to this comment ]

Posted by Steve (62.30.xx.xx) on Mon 26 Jun 2006 at 09:01
[ Send Message | View Steve's Scratchpad | 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 | Reply to this comment ]

Posted by PJ_at_Belzabar_Software (59.176.xx.xx) on Mon 26 Jun 2006 at 11:28
[ Send Message | 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 | Reply to this comment ]

Posted by Steve (62.30.xx.xx) on Mon 26 Jun 2006 at 11:35
[ Send Message | View Steve's Scratchpad | 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 | Reply to this comment ]

Posted by PJ_at_Belzabar_Software (59.176.xx.xx) on Mon 26 Jun 2006 at 12:17
[ Send Message | 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 | Reply to this comment ]

Posted by Steve (62.30.xx.xx) on Mon 26 Jun 2006 at 12:21
[ Send Message | View Steve's Scratchpad | 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 | Reply to this comment ]

Posted by PJ_at_Belzabar_Software (59.176.xx.xx) on Mon 26 Jun 2006 at 12:34
[ Send Message | 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 | Reply to this comment ]

Posted by toote (200.82.xx.xx) on Mon 26 Jun 2006 at 05:13
[ Send Message ]
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 | Reply to this comment ]

Posted by simonw (212.24.xx.xx) on Mon 26 Jun 2006 at 14:09
[ Send Message | 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 | Reply to this comment ]

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 | Reply to this comment ]

Posted by Steve (62.30.xx.xx) on Tue 27 Jun 2006 at 06:32
[ Send Message | View Steve's Scratchpad | View Weblogs ]

Compile the test programs with gcc-3.x?

Steve

[ Parent | Reply to this comment ]

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 | Reply to this comment ]

Posted by ronjohn (70.171.xx.xx) on Tue 8 May 2007 at 21:58
[ Send Message ]
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 | Reply to this comment ]

Posted by Pooya (2.146.xx.xx) on Thu 6 Jan 2011 at 10:22
[ Send Message | 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 | Reply to this comment ]

Posted by Steve (2001:0xx:0xx:0xxx:0xxx:0xxx:xx) on Thu 6 Jan 2011 at 11:48
[ Send Message | View Steve's Scratchpad | 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 | Reply to this comment ]

Posted by Pooya (2.146.xx.xx) on Thu 6 Jan 2011 at 12:11
[ Send Message | 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 | Reply to this comment ]

Posted by Steve (2001:0xx:0xx:0xxx:0xxx:0xxx:xx) on Thu 6 Jan 2011 at 12:15
[ Send Message | View Steve's Scratchpad | View Weblogs ]

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

Steve

[ Parent | Reply to this comment ]

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 | Reply to this comment ]

 

 

Flattr

Related Links