ARTeam Tutorial

Visit: http://cracking.accessroot.com | http://forum.accessroot.com

A funny view on int smashing v 1.1


Information A little tutorial which introduces int smashing and shows how PC doesn't like buffer overruns
Target -
Available -
Tools OllyDbg 1.10
Protection --
level Beginner
Category int smashing and Buffer Overruns
Author(s) Shub-Nigurrath Dec 2005
Requirements Windows XP, IE 5.5 and above for best viewing


1. Introduction

Hi all today's today I'll demonstrate how our PCs doesn't like buffer overruns and int smashing.

This code is a modification of the code inside this tutorial: Blexim, Basic Integer Overflows, Phrack 60, www.phrack.org/show.php?p=60&a=10 but isn't strictly required to understand what I'm describing. Anyway take a look at it you'll learn something interesting..

This is not a tutorial about smashing tecniques but rather a tutorial on a funny situation happened to me, and that I wanted to share with you, however at the end I included a complete references guide where to take your moves on this mines field .. there’s no doubt that there will be significant new vulnerabilities discovered due to integer errors in any of the thousands applications in use.
 



2. Description of the bug


Integer overflows are not like most common bug classes. They do not allow direct overwriting of memory or direct execution flow control, but are much more subtle. The root of the problem lies in the fact that there is no way for a process to check the result of a computation after it has happened, so there may be a discrepancy between the stored result and the correct result. Because of this, most integer overflows are not actually exploitable. Even so, in certain cases it is possible to force a crucial variable to contain an erroneous value, and this can lead to problems laterin the code.

Because of the subtlety of these bugs, there is a huge number of situations in which they can be exploited, so I will not attempt to cover all exploitable conditions. Instead, I will provide examples of a situations which is exploitable, in the hope of inspiring the reader in their own research :)

This tutorial applies to this code:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main(int argc, char *argv[]){
try {
	unsigned short s;
	int i;
	char buf[80];
	if(argc < 3){
		return -1;
	}
	i = atoi(argv[1]);
	s = i;
	if(s >= 80){            /* [w1] */
    	printf("Oh no you don't!\n");
        return -1;
	}
	printf("s = %d\n", s);
	memcpy(buf, argv[2], i);
	buf[i] = '\0';
	printf("%s\n", buf);
	return 0;
}
catch(...) {
	printf("Oh my God!\n");
}
}

While a construct like this would probably never show up in real life code, it serves well as an example. Take a look at the following inputs:


c:\tmp\smash 5 hello
s = 5
hello
 

c:\tmp\smash 80 hello
Oh no you don't!


c:\tmp\smash 65536 hello
s = 0
Segmentation fault (core dumped)


The length argument is taken from the command line and held in the integer.

When this value is transferred into the short integer s, it is truncated if the value is too great to fit into s (i.e. if the value is greater than 65535). Because of this, it is possible to bypass the bounds check at [w1] and overflow the buffer. After this, standard stack smashing techniques can be used to exploit the process.





3. Studying the problem

Well, try now to insert this input to start looking at the stack buffer (I'll not cover it completely indeed).

c:\tmp\smash 65536 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaDEADBEEF

There are 80 'a' and “DEADBEEF” is the overrun

Let's now open ollydbg on smash.exe (in this tutorial archive) to see what happens..


First of all insert the program's arguments:

65536 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaDEADBEEF

then run the program and place these two breakpoints

0040105C . /7C 12 JL SHORT xx.00401070

and

00401096 . E8 55000000 CALL xx.004010F0

When you land here, verify that the JL isn't taken and "correctly" our program ignores the security warning labelled [w1] in the source code above.

Now, happily go forward till the second breakpoint and enter the corresponding call.

 

We are now testing if the buffer which has a maximum lenght of 80 characters can be overrunned.

 



Enter the call, as you might see it's working on the buffer we provided:

step through the instructions till you get to this one:

00401123 . F3:A5 REP MOVS DWORD PTR ES:[EDI],DWORD PTR DS:[ESI]

step this also and you should get this interesting thing

look at the registers of the application, and specially at the EIP



 

Wow, it seems like our computer doesn't like our DEADBEEF :-D

 



5. References

Nontraditional literature on buffer overruns

Well in order to give to you also something interesting on which to study and start learning something new, I thought to also place here a reference guide to "non traditional" literature on smashing (stack, as well as heap and so on). I think might of some interest to the most beginners of you (but not only indeed). This material comes partially from a publication I found and of which sincerely I don't remember the name (who cares afterall) ;-)

Although very little work has been published on exploitation in traditional conferences and journals, there is a lively parallel world —where the work is often of surprisingly high quality (don't you think so ?). This important resource is often left untapped by security researchers. The exploit techniques nowadays around come from four major threads of nontraditional literature, with a fair amount of crossover between them: Web sites and advisories from security companies and individual researchers; mailing lists, most notably the Security Focus VulnWatch and VulnDev mailing lists; hacker conferences such as Black Hat (www.blackhat.org); and Phrack magazine (www.phrack.org).

Stack smashing
AlephOne’s 1996 Smashing the Stack for Fun and Profit (in Phrack 49 at www.phrack.org/show.php?p=49&a=14) and DilDog’s The Tao of Windows Buffer Overruns (www.cultdeadcow.com/cDc_files/cDc-351/) are classic introductions to stack-smashing techniques and trampolining. Murat Balaban (www.enderunix.org/docs/eng/bof-eng.txt) first described the technique of storing the executable code in an environment variable. eEye’s Blaster Worm Analysis (www.eeye.com/html/Research/Advisories/AL20030811.html) discusses the Blaster worm in detail.

Arc injection
Return-into-libc attacks were pioneered by Solar Designer in 1997 (www.securityfocus.com/archive/1/7480) and refined by Rafal Wojtczuk (1998’s Defeating Solar Designer’s Non-executable Stack Patch at www.insecure.org/sploits/non-executable.stack.problems.html, and 2001’s The Advanced return-into-lib(c) Exploits in Phrack 58 at www.phrack.org/show.php?p=58&a=4. K-otic describes a return-into-libc exploit for MS03-026 at www.k-otik.com/exploits/11.07.rpcexec.c.php.

Pointer subterfuge
Pointer subterfuge attacks were developed largely in response to the introduction of stack canary checking in StackGuard and other products. Matt Conover’s 1999 paper on heap exploitation (www.w00w00.org/files/articles/heaptut.txt) discusses this and has several examples of pointer subterfuge attacks; he cites Tim Newsham’s earlier mail suggesting this approach. Bulba and Kil3r’s Bypassing Stackguard and Stackshield (Phrack 56 at www.phrack.org/show.php?p=56&a=5) and Gerardo Richarte’s similarly titled Bypassing the Stackguard and Stackshield Protection (www2.corest.com/common/showdoc.php?idx=242&idxseccion=11) are two early examples here. David Litchfield discusses exception-handler hijacking in his 2003 paper on Variations in Exploit Methods Between Linux and Windows (www.nextgenss.com/papers/exploitvariation.pdf); his Defeating the Stack Buffer Overflow Prevention Mechanism of Microsoft Windows 2003 Server (www.nextgenss.com/papers/defeating-w2k3-stack-protection.pdf) discusses both pointer subterfuge in general and exception handling hijacking in particular. Rix described Smashing C++ VPTRs in Phrack 56 (at www.phrack.org/show.php?p=56&a=8).

Heap smashing
Conover’s 1999 paper (mentioned above) first described heap exploitation techniques, although he noted “... heap-based overflows are not new.” A pair of articles in Phrack 57 (Michel Kaempf’s Vudo Malloc Tricks at www.phrack.org/show.php?p=57&a=8 and Anonymous’ Once Upon a Free ... at www.phrack.org/show.php?p=57&a=9) introduced heap smashing in mid 2001. Halvar Flake’s Third Generation Exploits (www.blackhat.com/presentations/win-usa-02/halvarflake-winsec02.ppt) first applied this to Windows; Litchfield’s Non-stack Based Exploitation of Buffer Overrun Vulnerabilities on Windows NT/2000/XP
(www.nextgenss.com/papers/non-stack-bo-windows.pdf) expands on these concepts. JP’s Advanced Doug Lea’s Malloc Exploits (Phrack 61 at www.phrack.org/show.php?p=61&a=6) elegantly analyzes heapbased exploits in terms of primitive operations and covers several techniques for extracting information from the target program to make exploits more reliable. Pheonlit’s description of exploiting a Cisco IOS heap overrun (www.phenoelit.de/ultimaratio/index.html) shows how attackers can work around partial defenses. Frédéric Pierrot and Peter Szor of the Symantec Security Response Center analyzed the Slapper worm’s use of the heap-smashing technique (securityresponse.symantec.com/avcenter/reference/analysis.slapper.worm.pdf). Dave Aitel’s excellent two-part series Exploiting the MSRPC Heap Overflow (www.immunitysec.com/downloads/msrpcheap.pdf and www.immunitysec.com/downloads/msrpcheap2.pdf) gives a good feel for how to develop exploits in practice, and also illustrates the technique of providing the “payload” in an operation distinct from the buffer overrun itself.

 

Notable vulnerabilities caused by integer errors

The int smashing is a new tecnique raising attention as you can see. Integer errors caused some notable vulnerabilities. They are referenced by their BugTraq number.

  • Apple QuickTime/Darwin Streaming Server QTSSReflector Module Integer Overflow Vulnerability (Bugtraq ID 7659); www.securityfocus.com/bid/7659. Sir Mordred discovered this and published it on 22 May 2003.
  • Sendmail Address Prescan Memory Corruption Vulnerability (Bugtraq ID 7230); www.securityfocus.com/bid/7230. Michal Zalewski discovered this and published it on 29 March 2003.
  • Snort TCP Packet Reassembly Integer Overflow Vulnerability (Bugtraq ID 7178); www.securityfocus.com/bid/7178. Bruce Leidl, Juan Pablo Martinez Kuhn, and Alejandro David Weil of Core Security Technologies discovered this and published it on 15 April 2003.
  • OpenBSD setitimer(2) Kernel Memory Overwrite Vulnerability (Bugtraq ID 5861); www.securityfocus.com/bid/5861. Open BSD reported this on 2 October 2002.
  • Apache Chunked-Encoding Memory Corruption Vulnerability (Bugtraq ID 5033); www.securityfocus.com/bid/5033. ISS X-Force discovered this and published it on 17 June 2002.
  • SSH CRC-32 Compensation Attack Detector Vulnerability (Bugtraq ID 2347); www.securityfocus.com/bid/2347. Michal Zalewski discovered this and published it on 8 February 2001.
  • Sendmail Debugger Arbitrary Code Execution Vulnerability (Bugtraq ID 3163); www.securityfocus.com/bid/3163. Cade Cairns of SecurityFocus discovered this and published it on 17 August 2001.

Further reading about int smashing:


 

6. Conclusions

Lesson Learnt

a new interesting way to ROFL and some starting points where to learn new things..




 
7. Greetingz

[MAIN TEAM]
| Nilrem | Enforcer | Ferrari | Pompeyfan(ex-member) | MaDMAn_H3rCuL3s | EJ12N | Kruger |
Shub-Nigurrath | Jdog45 | R@adier | Teerayoot | ThunderPwr | Eggi | Bone Enterprise

*****************************

Exetools | Woodmann | VCT | TSRh | Sir JMI | | FEUERRADER | Britedream | cl0ud (Mephisto) | Zest | Hobgoblin | Nullz | Everyone I missed & you


(.|.)
 ).( (¯`·._.·[¯¨´*·~-.¸¸,.-~*´¨&8~) Ŝħůβ¬Ňïĝµŕřāŧħ ¨´*·~-.¸¸,.-~*´¨]·._.·´¯)
( v )
 \|/