
Smashing the stack for fun & profit. - jdeseno
http://www.phrack.org/issues.html?issue=49&id=14&mode=txt
======
tptacek
It's interesting to compare exploit tech from today to how simple things were
back in '97. In '97, a complex exploit meant you couldn't have lowercase ASCII
equivalents in your shellcode. Now, you scan the target for info leaks that
will disclose stack cookies, and spray the heap to increase the odds that
you'll hit your exploit in randomized memory, and forge stack frames that will
return to mprotect or VirtualProtect, and and and.

So much of "security research" over the last 10 years has basically danced
around a fundamental fact: if you lose control of the runtime memory of your
program, you lose control of the whole program.

~~~
swolchok
If you get lucky, your target won't bother with all these new-fangled
protections and run on WinXP (no ASLR) and the only thing you'll have to
contend with is non-executable stack. Our original exploit for Green Dam used
a heap spray only to make writing it easier, and the underground exploit uses
a really awful behavior of IE w.r.t. running .NET DLLs --
<http://www.milw0rm.com/exploits/8938> . Other than that, there are no
defenses to speak of.

~~~
tptacek
Even that really awful behavior of IE, that's a Black Hat '09 talk, isn't it?

~~~
swolchok
Black Hat talks are not necessarily "new". Black Hat is not an academic
security conference. The exploit was released months before BH09.

------
mahmud
A classic. The most referenced underground paper, ever!

 _112,605 documents found_

[http://citeseerx.ist.psu.edu/search?q=Smashing+The+Stack+For...](http://citeseerx.ist.psu.edu/search?q=Smashing+The+Stack+For+Fun+And+Profit&submit=Search&sort=rel&ic=1)

------
lg
Ah, fond memories of my computer security class, where this was assigned
reading. We also studied format string vulnerabilities:
<http://julianor.tripod.com/bc/formatstring-1.2.pdf>

~~~
alecco
If we are going down memory lane, check out JP's "Advanced Doug lea's malloc
exploits"
[http://www.phrack.org/issues.html?issue=61&id=6#article](http://www.phrack.org/issues.html?issue=61&id=6#article)

~~~
shykes
And you might as well read Doug Leas's paper, too
<http://g.oswego.edu/dl/html/malloc.html>

------
scythe
In one of my freshman CS courses, one of our last assignments was to read this
paper (as well as a more approachable tutorial written by our TAs) and carry
this out on a toy architecture (LC3) that we had been working with for the
whole course. It was probably the most interesting assignment we had that
semester.

~~~
Oompa
I had a similar class. CS2110 at Georgia Tech. I will never forget it :)

~~~
scythe
Funny, I was referring to the same class!

When did you take it?

~~~
Oompa
Just last year. Taught by the fantastic Bill Lehey.

~~~
scythe
Really? Fall or Spring? We might have been in the same class!

~~~
Oompa
Spring 2009.

------
jacquesm
Funny how the first example contains a subtle bug, the string termination is
never done, if the stack wasn't zeroed prior to running that program, you may
not only overflow 'buffer' on purpose, you may overflow it a lot further than
you'd think by just reading the code.

large_string[255] = 0;

Would solve that.

------
wclax04
I remember reading this paper as an undergrad at Rutgers. We had to do a stack
smashing project based on this with different stack protection methods
(canaries/ASLR)

This was probably one of the most important things I learned in school.

------
haupt
I remember reading this and finding an error in one of the examples. In
addition to learning about the stack, I also realized that superheroes are
human, too. <3

------
MtL
Funny, I just re-read that paper yesterday =) Aleph One is a hero in my eyes,
he made my childhood much more interesting.

------
sown
For a lot of these tutorials to work, you also have to turn off SELinux or any
other stack protection.

~~~
petsos
This paper was written 7 years before SELinux was merged.

~~~
sown
Yes. And the examples won't always work on modern linux distros depending on
configuration

~~~
petsos
Well, I would hope so that exploiting techniques written 13 years ago won't
always work on modern distros.

~~~
jacquesm
Your hope is unfortunately misplaced, the 'always' is the operative word.

Probably we will never see the end of this kind of attack until we switch to
some radically different architecture.

~~~
jrockway
"Managed code."

~~~
jacquesm
That's limited to the microsoft platform for now isn't it ?

Or does the term also apply to java ?

One of the things that I've been wondering about, that maybe you can answer is
this: If languages such as javascript, lisp, python and so on (as opposed to
say C) treat functions as first class citizens, doesn't that open up a
completely new can of worms with respect to security ?

~~~
tptacek
A strange question. Almost every language we use today is "managed", by the
Microsoft definition; "Managed C++" is a Microsoft term for bare-metal C++
with extra runtime protections. Of course Java is "managed".

~~~
jrockway
Yes, "managed C++" is very poorly managed. You can still do things like:

    
    
       char foo[42];
       foo[-4] = 0xcafebabe;
    

and watch your program crash and burn. (Sometimes, though, you get an
exception you can catch with try{}/catch{}, instead of an actual segv. It
would be hilarious... if only the app I was working on did not use this
behavior as part of its string-parsing routine...)

~~~
tptacek
Managed C++ isn't really designed to bulletproof C++; it's designed to make it
possible to field C++ code without allowing attackers to upload their own
programs into your program's memory.

Kicking Managed C++ for not being C# is a bit of a cheap shot.

------
omouse
And the lesson is, try to avoid using C :)

~~~
tptacek
And C++.

------
ecq
wow I still remember this. a classic by Aleph One.

Another tutorial pre-dates this by ~1 year. It was written by mudge.

<http://biblio.l0t3k.net/b0f/en/howto_write_buffer.txt>

~~~
tptacek
The first published x86 shellcode-style overflow was splitvt, which was
announced "officially" just weeks after this tutorial was dated:

<http://seclists.org/bugtraq/1995/Dec/2>

(My business partner co-authored it).

The first shellcode-style buffer overflow (besides the rtm worm) was Thomas
Lopatic's HPUX HTTPd vulnerability from a few months earlier:

<http://seclists.org/bugtraq/1995/Feb/109>

There was a frantic race to get the first overflow out after 8lgm capped off
their run of zero-days with an announcement of a Sendmail 8.6.12 remote that
relied on a syslog() overflow (yes, in 1995, syslog(3) had an overflow). I was
sitting next to Pieter when he wrote part of the tutorial you linked to. I was
pretty young (maybe 19?) but even so, it was a pretty electric time to be
involved in security.

------
c00p3r
Oh, that romantic feeling from the boyhood... =)

