O= /) FLIPPERSMACK 014 `= culturemag for a penguin generation http://www.flippersmack.com x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x Welcome to issue 14: the first issue to have articles written by five very different people! First we have poetry, dished out from SlapAyoda and Peter Katz. Next is a probing insight to a girl's mind when it comes to geek boyfriends, complete with advice to the ladies out there. Then we have an incredible intro to programming by Loophole of hhp. [ www.hhp-programming.net ] And finally an article by me about the history of CGI animation, from Toy Story to Final Fantasy. I hope that you enjoy this week's issue. Keep sending articles in! pinguino [pinguino@comicartist.com] Flippersmack Archives: http://www.penguinpalace.com/ http://www.nettwerked.net/ http://www.ghu.ca/ tABLE oF cONTENTS A Dark Room ...........................................SlapAyoda LA ...................................................Peter Katz Tech-Heads and Those Who Love Them ...............Melinda Ambill Programming and Programming Securely ...................Loophole History of CGI .........................................Pinguino .x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x A Dark Room by SlapAyoda (slapayoda@yahoo.com) dark rooms hosting withdrawn shadows slivers of blue light wholly static dust gathering quietly in a corner completely without movement, we travel coughing amidst the blue smog of unknown emotions the skinny one remembers his time in the desert we're laughing and staring blankly at walls white noise feels somehow black i'm not sure how we got here if you close your eyes you can hear the insects crawling away crawling inside the paint chips fall in slow, silent patterns completely unnoticed and alone the single candle already burnt it lights easily, wax already unshapen meanwhile the fat one asks himself how in the world could he forget something that was with him for so long his eyes indicate to us his sorrow outside of this collection of wooden beams and fears dirt still warm from the set sun waiting for the leaves to fall -.x.x.x.- LA by Peter Katz (FIENDzine@aol.com) A footsoldier priest warning pedestrians of the sign of the beast, You can sell your body or you can sell your soul A star burnt out before she could reach her goal, I carefully step with my feet over broken bottles and broken men who occupy the street Cops and the o-zone can't protect me from LA heat, Behind the peoples cold stares You can drown in a ocean of all their tears. -.x.x.x.- Tech-Heads and Those Who Love Them By Melinda Ambill (scgal1@excite.com) I admit, I never thought that one day I'd look at my guy and say, "Yeah, he's my dork." And yet, here I am, not only in a relationship with but sharing a home and a cat with one. Yes, I'm in love with a tech-head. Over the past few months, I've realized that tech-heads are a rare bunch, a group that needs special care and attention. And so, without further ado, here is the first in a series of observations from my little microcosm of life. The first thing to know when getting involved with a tech-head, be they male or female, is that Fry's Electronics is not just a store - it is Mecca to all tech-heads. If you choose to accompany your darling to this uber-dork's paradise, be prepared for a long trip. Basic rules for a Fry's trip: 1) There is NO SUCH THING as a quick Fry's trip. They may swear up and down that they know exactly what they want and will "only take a couple minutes"; but trust me, you will still spend 30-45 minutes waiting for him or her to decide between two power supplies that look exactly the same to you. 2) Nothing is ever where the salespeople claim. Your tech-head will still insist on searching the areas that he/she is directed to look in. Usually, it will be you who will find the SCSI cable they are searching desperately for. 3) There is ALWAYS A LINE. Allow at least 15-20 minutes to get through said line. One good thing is that the line winds through junk food heaven and by the time you get to the front you will have already eaten whatever you pick up. 4) Never, under any circumstances, accompany your tech-head to RETURN something to Fry's. These trips always anger them because of Fry's ineptitude when it comes to doing returns. It is not a pretty sight. 5) Take a book. I learned this trick from a friend. While there are some things of interest for us non-techies to look at (like a decent music and movie section), the longest I've managed to stretch out my own browsing is about 45 minutes (my friend gives up after 30 minutes). Then you can tell your tech-head that you are going to be in the café and they can come find you there after they finish drooling over the latest flat screen monitors and the newest version of Final Fantasy. The café is like the non-techie haven - a cold drink or some coffee, no tech products and time to sit and read your book without having to nod when he/she asks if the purple exhaust fan will look okay with the black case on his/her computer. It is the only way to survive. A trip to Fry's is something every tech-head's significant other must be ready to live through. In a way, it's cute - kinda like a kid in the McDonald's Playland after being hyped up on that sugary orange drink. Be flattered if your tech-head takes you to Fry's with you, because it is after all their special place. Next week: The Advantages of Dating a Tech-Head -.x.x.x.- Programming and Programming Securely by Loophole (pigspigs@yahoo.com) Every programmer has to have something to program, whether it's work related, hobby related, for a friend, or even just a quick script for an automation. We will discuss hobby programming. When sitting at home and pondering upon ideas to program you sometimes get stumped and feel halted. This is a term in the programming world called "coders block", yes... exactly like a "writers block". I can speak from experience and from other documentation on steps to overcome this block, I will try and combine the both. The first thing to do is get focused, you don't want to be distracted while trying to program, just as you don't want to be distracted while taking a biology test. Keep your environment quiet or even put on some music to your liking that doesn't get you singing along... the slightest things can get us side tracked and off course. A lot of coders create a coding playlist, like myself. Furthermore the time of day you chose to program is a big part as well. From experience I do not like to program when I get off work or get in from a long day, instead I like to program when I wake up after eating breakfast and have started a fresh day. So if you're starting or working on a big project, try and schedule in worthy time to code. After you have got all this situated it is now time for step 2, finding something to program. Remember that programming is an art and is only limited to your imagination and programming skills. If you have coders block try and create a list of situations you have encountered in which a tool did not exist for what was needed. Once you have thought of something don't stop adding ideas, you can add several and the next time you are in need of something to program you can go back and find previous self suggestions. If you still can't think of anything, like a lot of us do time to time then just go search freshmeat.net and read the latest released projects and even search the previous released. Try and spawn a totally new idea. If a paper could help expand your imagination then no one would ever be in search of projects. Once you have created an idea, the next step is to chose a programming language. I can not tell you what to chose, but when I chose a language I think of: 1. How fast does the program need to be. 2. How much data is actually user/client supplied. 3. How much regular expression and parsing will it need. 4. How secure does it need to be, (s*id/daemon?). After I compile a list I go from there. I like to program in C when the software needs to be fast and secure, especially for daemon/client type software. I also like to program in Perl if the input is mainly user supplied and heavily based on parsing and regular expression or I'm racing a clock. I obviously do not know every programming and scripting language existent so it's totally up to you and your preferences, my suggestions are not near any type of standard. Once you have chose a programming language a lot of people like to gather all references needed, as in books and online technical documentation like RFC's and such. Once all if this has been gathered it is time to setup your programs operation outline and build a mental list of functions, modules?, objects, and techniques in which you intend to use. You now want to sketch down a design in which you intend to guide and follow while programming your project. Without a guide you might end up forgetting something and having to redesign your entire project. Always plan ahead and have an overall understanding of what is ahead of you. It is now time to code... securely. I will now try and include guidelines which are needed to be followed in order to produce secure programs. I will focus on s*id and network applications. If you don't know what a s*id application is, in short it is a program that requires different privileges (sometimes root) to do operations. An example would be /usr/bin/passwd which requires access to read and modify the passwd and or shadow file. When programming a s*id application you want to be positive that you handle these given privileges with extra care and contain them only when actively using them. You want to try and put these operations that need extra privileges in the beginning of your code so when they are finished you can drop these privileges right afterwards. This prevents any holes found in the source extending the privilege drop that an attacker may exploit from spilling those privileges. If these operations can be done sgid new group just as they can suid root, do not make it suid root. Remember the whole reason we are programming securely is to prevent bugs and mostly preventing an attacker from gaining privileges that he currently does not have, whether it's a remote attack on a daemon like telnetd or a local attack on a program like su. If you're coding a network daemon you want to make sure every single instruction, operation, and routine you use is foolproof. Holes exploitable remotely are the worst to exist and the most dangerous. Trust nothing and no one, ever. Trust should never be apart of your program. Picture everything as an enemy to break your program. You have to build a defeatless set of operations and routines, create a flawless and unbreakable structural design, and still contain full functionality. In C this is not even near an unreachable goal when utilizing the right functions and routines which are clearly at hand. I will now list some guidelines while programming: 1. Argument checking. (Vital) A. Perform bounds checking on everything. B. Become a semiotician and cross verify all syntactics. C. Watch carefully over the handling of command line arg- uments and bound everything. D. Verify all typecast variables. E. Verify system function arguments going outbound. G. Try and prevent from pulling arguments from the env- ironment. If you have to, make triple sure that you perform bounds checking and monitor everywhere the var- iable can go. This is a major commonly known mistake. 2. Arbitrary lengths. A. Don't use functions that omit buffer bounds checking. Example: - sprintf(), vprintf(), vsprintf(), etc. - strcpy(), strcat(). - gets(), scanf(), sscanf(), etc. B. Make double sure all your variable sizes are calculated correctly. C. Don't trust strings to be all null('\0') terminated and remember strlen() does not include this null. In real- ity the string is always one byte larger. D. Don't allow overwriting of the null terminated byte when using read() and fgets(). 3. Program equipment. A. If you must run operations via higher privileges, be careful what your program is equipped with, like stated earlier... trust nothing. GTK+ for one has been an example recently shown to allow a library hijacking which was attackable via any s*id application which had GTK+ equipped while running in 'higher privilege mode'. B. If outside "equipment" has to be used, I myself would audit it. 4. Execution via shell escapes - functions with suction. A. Do not use system(), popen(), or exec(). These methods are way too sketchy. Arbitrary commands are commonly known to find their way to the arguments of these calls which escape the real intended usage and give an attacker easy access to gain shell access as a superuser. DO NOT USE THESE FUNCTIONS. B. Be sure you include full pathnames when using execl() and execvp(), these use $PATH if no '/' is found. C. If they must be used for some twisted situation, make triple sure that you parse out any type of escaped shell escape characters (meta characters, etc). D. Make sure you include full pathnames to all outside pro- grams being called. $PATH can be enabled to use '.' (Trust no one). I would suggest creating your own $PATH and make sure you do not trail it with ":", that in- cludes '.' in the paths. 5. Preventing race conditions. A. Do not use mktemp() when creating temp files, instead use mkstemp()/tmpfile(). B. Use file locking for modified files. Leave yourself a recovery method in case of an emergency(crash, etc). Catch signals. C. When using open() to create a 'new' file, always use the O_EXCL and O_CREAT flags to cause failure if the file already exists. D. Also when manipulating a file always remember to utilize fchown(), fchmod(), and fstat() to prevent any type of race condition or an unexpected file replacement. E. Make sure a link does not exist with lstat(). F. Make sure your sequence of operations are correct. ie. Don't expect a file you just stat'd to be the same file 5 seconds later. (Trust no one). 6. Other sly tricks and misc things. A. Always check anything going to be created that is user supplied for meta characters... a filename, anything shell related, etc. (vital). B. Dynamically link all libraries, this will prevent any pseudo system libraries from being created and switched. C. Setup limit values so your program does not leave a core file. Catch SIGABRT. D. In Perl try not to use `...` this too is a shell escape. 7. Implement logging / syslog'ing and debugging messages. A. Log the PID, time, user(*uid/*gid), and terminal. B. Log the command line arguments and caught attempts to breach your programs security. C. Do this while not flooding syslog. D. In the most vital positions of your programs you want to implement verbose messages. Also debugging messages are a big help when working on a huge project that starts to get confusing of what's doing what and what is going where. Lots of debugging messages are very good. Create a 'Debug mode' in which you can turn on internally with a switch, debug=1, etc. 8. Release everything evil you have inside you. A. Try and BREAK, hurt, SMASH, trick, BEAT, and kill your program in any and every possible situation. You can also go download several 'lint' programs which scan your source and often highlight subtle unforeseen problems. O`reilly has a book called 'Checking C programs with lint' which can be bought via http://www.oreilly.com/catalog/lint/. After you have finished your project you want to make sure it is disposed of all bugs and errors. While you're in the beta stages you want to allows friends or a selected few to 'beta test' this software and have a few more brains try and wreck it. When all seems well then it is up to you to release it. -.x.x.x.- History of CGI Animation by pinguino (pinguino@comicartist.com) Final Fantasy: The Spirits Within drives animation to a level of reality never before seen on the big screen. The first hyper-realistic CGI-animated movie of its kind, Square Pictures based the style off it's popular Final Fantasy video game series. Final Fantasy breathes life to animation, with superior attention to detail and breakthroughs in texturing, animation, and character modeling. It has only been six years since the release of the first fully animated computer generated movie: Disney's Toy Story. How has the industry evolved? GoGo Magazine explores by taking a trip back in time. Booked as a cartoon that's "realer than real," Toy Story broke box office records with $354 million in global revenues. It was the first fully computer-generated full-length feature film, released November 22, 1995. The characters were modeled in three dimensions by scanning actual sculpted objects. The images required 800,000 hours generation time. Directed by Academy Award®-winning filmmaker John Lasseter and featuring the voices of Tom Hanks and Tim Allen, Toy Story broke the ground for computer generated movies, and found their audience with a compelling story and characters the audience could relate to. The second and third animated movies came out together in 1998: Antz from Dreamworks and A Bug's Life from Pixar and Disney. Released by rival studios, both focused on the underground world of insects. The year 2000 brought us Chicken Run from Aardman Animations and Dreamworks. Although it looked like a computer generated movie, it was actually stop-motion clay animation with CGI used for minor effects. Animators at Aardman see increased CG development as a good thing, because it would cut their workload immeasurably. At the time Chicken Run was in production, no technology existed that could mimic the effects and expressions they wanted to convey. Earlier this year we got to see animated expressions reach a new high with Dreamworks's Shrek. Amazing animation combined with superior storytelling made this movie popular with adults and children alike. Shrek was vivid and expressive; the graphics were a part of the story instead of the focal point. Some people had problems enjoying Antz because the characters were not believable enough, and the animation distracted them. In the early days of CG, the world was blocky. The first transition was to cleaner curves and more seamless movement. Toy Story relied heavily on a unique art style, good story, and dialogue. The story moved as quick as any slapstick cartoon on network TV. Antz and A Bug's Life brought the intensity of higher quality animation and texturing. In 1999, Disney made epic breakthroughs with manipulating muscles under skin for Dinosaur. Twelve years of production and over 1,300 individual special effects brought together a meeting of live-action background footage and intensely lifelike computer-generated dinosaurs. Only through computers can the world of the dinosaurs be experienced. Final Fantasy represents the first attempt in history to realistically simulate human emotions and movements through CGI animation. The models are the most complex used in the industry- the lead character, Aki Ross, has 60,000 individually rendered hairs on her head. Square took a new twist to promoting the characters as more "real" by putting Aki on the cover of Maxim. Where will the movie studios take us in the future? Some believe that animation will continue to push the envelope until there is no need for actors, but others argue that level of realism is available today and that audiences wouldn't accept it. Either way, with the developments from Final Fantasty, expect to see other studios compete to achieve their own hyper-realistic human successes. +-----------------------------------------------------+ Flippersmack (c) 2001 Flippersmack All Rights Reserved. Penguins do it better.