Cooking With Technology

GCJ, the GNU compiler with java extensions, does a great job at compiling Java into bytecode, but still has some bugs in its libraries when dealing with Swing components. Installing Sun’s Java packages on Debian thus is occasionally necessary, and has historically been a chore. I won’t list the process here to even show my distaste for it - it just wasn’t very fun.

Things are much easier now, though. Just make sure a non-free package repository is listed in your sources.list, and things become magic:

sudo echo "deb http://ftp.us.debian.org/debian/ lenny non-free" >> /etc/apt/sources.list

(Note that if you aren’t using lenny, you should change that. Also, feel free to choose a different mirror.)

Now update your package repository:

sudo apt-get update

And finally install whichever Sun Java packages you want!

sudo apt-get install sun-java6-jdk sun-java6-jre sun-java6-plugin

Cheers to Matthias Klose (Ubuntu), Juergen Kreileder (Blackdown), Barry Hawkins, Jeroen van Wolffelaar, and the other folks behind debian-java for adding these packages to Debian’s repositories. It is another push that greatly enhances the usability of the project for both developers and users alike.

My coolest project from work as of late has been to write a program to control the Sharp LCD projectors in RIT’s Software Engineering department through a serial interface. I really like writing code that interfaces with hardware, so this was one I enjoyed doing.

One thing I learned quickly is that debugging serial applications is hard. When my code wasn’t working, I didn’t know if it was because of the hardware, the software, or the command messages I was sending. If serial consoles or line printers were still widely available, it wouldn’t be hard to see what was going on. Since they aren’t, an alternate solution was devised utilizing GNU screen.

With two Linux boxes running Debian, I set one up with my code to send data from, and the other with screen attached to the serial device at /dev/ttyS0. Screen functions normally, but with the added bonus of displaying messages recieved from the serial device, and when entered, sending messages to the device. Screen makes it possible to visualize serial communications and send test messages without having to write or modify any code, making it an infinitely useful tool in debugging serial applications.

My bug turned out to be twofold: one hardware, and one software. The first was that the serial connection to the projector was not complete; there is a break somewhere in the wall. The second was that the manual states only that the command message be followed by a newline character. I was sending Unix newlines, like ‘\n’. The projector was written expecting Windows style newlines, which is a newline prepended by a carriage return, or ‘\r\n’. This simple fix, which I would have never stumbled over without the help of screen, was the source of my software based problems.

Yesterday I gave the second lecture in my “hacking” series. We’ve progressed beyond general descriptions and terminology and moved into the technical aspects of the stack, vulnerable code, and crafting exploits. The lecture ran about 45 minutes, and was accompanied by a live demonstration of exploiting vulnerable code.

For those that came late or missed it, the slides are available here (pdf format), although once again the real content was in the accompanying talk.

The demonstration used three source files. The shellcode was written by BreeZe of binbash.org, while the other two are my own. They are:

• The vulnerable sample program
• The shellcode
• The exploit code

Running the Exploit

First, I only tested the exploit running on Debian Linux, running a 2.6.23 kernel on a 32bit x86 machine. It probably won’t work on Windows or a Mac, and it definitely won’t run on your SPARC.

Second, I used version 3.3 of gcc’s compiler. Newer versions contain checks to make stack smashing harder, but 3.3 is free of any of these security features. You’ll have to use it when compiling these, which can be done by issuing gcc-3.3 -o <name> <name.c>, like:
gcc-3.3 -o exploit exploit.c

Third, Linux kernels after 2.6.12 do virtual address space randomization, which will prevent the exploit from running successfully after being compiled. To disable this, issue (as root):
sysctl -w kernel.randomize_va_space = 0

Fourth and finally, if you want to trigger a core dump in the vuln program, you have to lift any restrictions on dumping core files. Something like the following should work:
ulimit -c 100000

Note that the shellcode file is superfluous, I only included it as an example and guide.

Next Time

At this point, I’m not sure what I’ll be covering next week. There is a lot I could do - writing shellcode, showcase more advanced shellcode, demonstrate gaining a remote shell (remote exploitation is a whole other beast), secure coding, polymorphic and self-modifying shellcode… there are a lot of topics, and only one lecture left before the end of the series.

Regardless, it will be fun, and we’ll all learn a hell of a lot.

I’ll be at Barcamp Rochester 3 this Saturday in GCCIS, and more likely than not I’ll be talking about anything and everything computer security. If you have any questions anything or find something I’ve said interesting, hit me up! I’m friendly, and always up for talking about computer security :)

This past academic quarter I elected to do an independent study. A lot of hype has been surrounding web development over the past few years, and the python scripting language for even longer than that. Figuring it was time to immerse myself in both subjects and the technologies related to them, the independent study turned into a full four credit project aimed toward creating a web application for administering quizzes. Because I only had ten weeks to learn everything involved with developing a web application on top of the language, I coerced my good friend David Brenner into doing it with me. Development is done, and I now feel like I can talk intelligently about my experiences.

The project was developed using straight python, utilizing the mod python Apache module to serve Python Server Page (psp) files. Python isn’t my favorite language to code with, it is lacking some things that I’ve come to expect from a scripting language, and some things are just silly. Examples of lacking features include the ability to get an iterator for a collection. Iterators that grant references both to the next and previous element of a collection grant superior control and the ability to keep state while iterating. Python only allowing you to move forward through a collection with its “for x in collection:” construct really hurts while parsing large sequences of text, and having to revert to array notation and keep an index is much less human readable than just manipulating an iterator.

Annoyances with the language include python being a scripting language that doesn’t default to printing the string value of non-string objects, and using procedural style method calls intermixed with object-oriented style. For example, to print an object (say an array), you can’t just do print(“Array contents: “ + arrayName). You have to manually return the string value by using print(“Array contents:” + str(arrayName)) in order to avoid an error that print() was expecting an object of type string. I know python’s mantra is “explicit over implicit,” but languages are tools that you learn how to use. As I learn more, I expect to gain proficiency with the tool in order to save me time in the future. Python is easy to learn and easy to use, but I have yet to find any tricks with the language that save me time or make my job easier than it would be with another language. One last thing that I simply do not understand is the necessity to include a reference to “self” in method and constructor definitions. I strongly prefer the method signature to match the required call, python’s decision to branch from that convention is one that I can’t imagine will have a justification strong enough to alter my opinion of the practice.

As it goes with web development, we also used javascript, a MySQL database backed with InnoDB table engines, LDAP for authentication, HTML, and CSS. Development was utterly boring. Being a computer science student, I enjoy working on new things that present challenges and reward creative solutions. The most thought intensive part of this project was the parser run on imported quizzes using a format we decided on – and that was developed in the fourth week. Everything else was the brainless transfer of requirements to code. Some of the people I go to school with are attracted this kind of development, and I think I know why: frontend web dev is easy. Writing the backend logic isn’t bad, but the interface code and associated handlers could be composed by a high school student with some spare time and only rudimentary knowledge. The things learned in computer science definitely aren’t applied in that domain.

Finally, to wrap up loose ends: object relational database design is neat and very handy, javascript is odd at first but easy to pick up, dealing with web requests and forms is tedious, debugging web applications is a *bitch,* and Debian Linux with Apache, Subversion, screen, and vim makes for a great development and hosting environment.

Web development has its place, but it isn’t for me. I’m capable with python, but I’ll stick with ruby. And if you introduce yourself to me, try to be more descriptive than “I’m a web developer” so my experiences don’t tarnish my opinion of you – because I bet you are more skilled at writing code than that title would suggest.

I’m one of those people that tends to get distracted when I’m procrastinating. Most often, this comes out when I’m doing a programming assignment and I go to open documentation in my browser. For those of you that weren’t aware, Firefox and Stumbleupon are a developer’s worst nightmare - so many interesting things, only a click away! It had to stop.

So I hacked up DocBrowser, a minimalist’s web browser created solely for the purpose of quickly accessing documentation and APIs. It is free of clutter and distractions, leaving only you and the information you seek on the screen. It is not extendable, and its feature set is limited. It is therefore exactly what I had in mind when I started coding it.

I’ve created a page for it here. It is free, and is only 1.5mb, so why not download it and give it a shot?

Windows only, requires .NET 2.0.

As previously mentioned in this blog, I’m taking a programming skills course focusing on Aspect Oriented Programming (AOP) using AspectJ. I am using eclipse with the AspectJ plugin to develop, and recently came across a situation where I wanted to define a pointcut based on an object that uses generics. In attempting to do so, I got the following error in eclipse:

parameterized types not supported for this and target pointcuts (erasure limitation)

While the error puzzled me momentarily, a quick hop over to the AspectJ developer notebook sorted things out. The full description of the solution is there if you want to read, but the quick fix is easy: remove the generic identifier of whatever you are trying to match against.

For example, this is incorrect:

pointcut badPointcut(): target( List<String> );

While this is the fixed version:

pointcut goodPointcut(): target( List );


Now get back to work :)

GOTO is a statement all programmers know. Most of us are too young to have ever actually used it, but anyone with a formal education has been provided with GOTO as an example of the worst enabler of ’spaghetti code.’ So after accepting that something called GOTO is bad, we return to thinking about what we’ll do after class. But why, WHY is GOTO gone?

The disappearance of GOTO can be attributed to multiple factors, most of them well presented by the famous Edsger Dijkstra back in freaking 1968 in a letter to the editor of “Communications of the ACM.” He made some humorous points, such as “the quality of programmers is a decreasing function of the density of ‘go to’ statements in the programs they produce.” Maybe I’m further gone than most (run while you can!), but it made me chuckle. The main points that he was trying to convey however are less humorous: GOTO makes it harder to ‘prove’ programs[1], removes the ability for a programmer to determine the progress of the program in execution[2], and that GOTO is just too primitive of a statement.

After some jokes among computer scientists (see COME FROM - yes, our sense of humor is in need of calibration), GOTO really did start to disappear. Most major language designs lacked official GOTO reserved words, and others like ADA included it using a syntax unique only to that statement so it may be easily found in programs. This disappearance is only surface deep, however.

It turns out that while an unbounded GOTO may result in obnoxious and nondeterministic code, the ability to jump to a segment of code outside the normal flow of execution is pretty handy. ‘Case’ statements are a popular implementation of a restricted GOTO, with one conditional evaluation resulting in a jump to one of many locations in code. More importantly, error handling would be near impossible to implement without the concepts on which GOTO was founded.

Unless the developer is an idiot, error handling is implemented as a catch in case something unexpected happens (I’ve seen it used as part of normal execution, ick). When something unexpected happens, you can no longer depend on the state of execution within the program. In this case, using a GOTO is the only way to break away from whatever caused the error and make some attempt to either rectify it or exit cleanly. Even the parody COME FROM statement has a hidden usage. In debugging, the concepts in which the COME FROM statement was founded are used to handle breakpoints.

So GOTO isn’t really dead, it is just hidden and stripped of its freedom. And more importantly, it can’t die. We rely on its concepts far too much in structured programming to do away with it. Now that you know, spread the word that GOTOs aren’t inherently bad! They are like kids: they just need boundaries.

[1] Loops and conditional statements, and of course functions, can all be reduced to formal mathematical language. Especially when converted to their recursive forms, loops are incredibly easy to prove as being valid with induction. GOTO statements broke this by making code execution able to change state at any time, greatly reducing the ease in which algorithms could be reduced to and proven with math.

[2] Some people might say “hey, loops are kind of like GOTOs. What is the difference?” Or maybe not, but here is the difference anyway. As pointed out by Dijkstra, loops are able to have some index applied to their current iteration or state in recursion (think for(int i=0; i<end; i++) - i is the index). This allows the programmer to have definite knowledge of the state of execution through using multiple indexes as “coordinates.” With a GOTO, this idea breaks because it is trivial to jump to anywhere in the program at any time, making the current indexes useless.

Ajax and the fancy “Web 2.0″ trend are causing all sorts of web applications to pop up. The most familiar examples are the many services that google is making available, and gmail especially. Gmail is, for many people, a desktop mail client replacement. And why not? It contains the functionality that one would expect in a desktop application - viewing mail, composing new messages, and creating filters to sort incoming articles of text. It is a nicely packaged application with a decent interface. It does however have one major flaw: it doesn’t control the application used to view it.

We aren’t talking cross-browser compatibility problems or the folks using text-only browsers such as lynx. The issue that spans all browsers is that they contain navigation buttons. Back, forward, and refresh, these are all elements that can make the execution of a web application occur in an order unintended by the developer. From a software engineering perspective, this presents new problems previously not encountered when designing and developing software. From a programmer’s perspective, this introduces new complexities in the code because the state of execution can change at any time. Additionally, the code monkeys have to handle sessions that may not terminate properly, half-open connections, and navigation issues that will creep up from the user jumping around your application.

A solution to this problem that hasn’t been completely explored is to combine the benefits of desktop applications with the advantages of web applications. Desktop applications are self contained, meaning the interface to that application is completely controlled by the developer. The state of execution again becomes reliable, hooks into the process’ termination can execute cleanup code, and even cross-browser issues may be ignored. Web applications need only a web browser to load them. By embedding the rendering engine of your web browser of choice (as far as I know, Mozilla’s, Internet Explorer’s, and Safari’s rendering engines can be embedded) in an application, the only thing the user see is exactly what you want them to.

The only complication that arises from this situation is the initial distribution of your application. But because the desktop ‘launcher’ application is going to be nothing more than a frame with some logic to handle any initializing or cleanup you wish to do, it is going to be a very small download. And if you are a company that produces a lot of applications, your launcher can be modified easily to support all of them from a single application. Attractive, isn’t it? This also allows for targeting an older demographic that has been slow to catch on to web trends by deploying to them something familiar: an icon on the desktop to be click clicked.

Now for the business stuff. If you already have a solid web application that conquers the navigation and other issues that plague them, you are one step away from redeploying your application to a new market. And while speaking of markets (and thus money), if your application is driven by advertisements, controlling the platform means that the user won’t be able to block your ads. Physical distribution also becomes possible at this point. Your launcher could be bundled with an installer and distributed by CD to be sold on the shelves in brick and mortar establishments. Now your application will be reaching all corners of the current software markets, bridging gaps of technical understanding, and all without your users blocking the media you want them to see. If you are just starting development with this paradigm in mind, you are going to save development time which can be refocused on implementing features for your users. The result is a better web application that is available to everyone.

The benefits gained don’t take a lot of convincing to sell. Simplified development, a cleaner application, and reaching broader markets all from changing the means of distribution?

Money. 

We’ll start this one off with a link. Don’t worry, it is just an image (safe for work, too).

The Greatest Programming Tip Ever.

I laughed when I saw that initially, then the title hit me. That really is the Greatest Programming Tip ever. Or at least it should be on the list of top 10 Great Programming Tips, if there were such a thing. Regardless of whether you are working on an assignment for a class, a personal project, or a product for your employer, it is almost certain that someone is going to look at your code. Writing readable and easily maintained code is important for this reason, but for different reasons.

If you are going to be writing code for a class, you had better put some time in making sure your code adheres to your department’s style guidelines. For the computer science department at RIT, this was actually factored into our grades on labs and projects. Even if it weren’t, your professor is going to be more frustrated than impressed with a piece of code that lacks comments and is filled with ternary operators. Comment your code to explain things that aren’t immediately obvious to a first year CS student, name your variables to be descriptive of their function, and make sure your program flows well (no spaghetti code). This will make your professor happy, thus boosting your grades.

For personal projects, it is just as important to follow the guidelines above. While there may be no one grading your work, consider that friends, future employers, and future-you may look at the code later. Embarrassingly, I can’t even count the number of times I’ve rewritten those run-once-every-three-months kind of scripts because I didn’t take the time to comment them. And if I had put those scripts on a public source repository (which I fully plan to set up soon), employers would eventually see it. I want the code I present to the world to reflect that I am a proficient, clean coder. You should want that for yourself.

Now here is the big one, your employers. If you are working for someone, that almost definitely means you are working on a team. In this case it isn’t just a matter of writing readable code so you can remember what you’ve done when you later have to fix a bug in the code. No - things have become amplified to a factor determined by the number of people on your team and the number of those team members that have to maintain your code. I know from experience the pain and delays that can be caused by terrible code, and I won’t lie: it happened way more often than I’ve blogged here. It dragged down the morale of our project team, caused huge delays in our production (on the magnitude of weeks of developer time over the past six months), and made the codebase impossible to maintain cleanly. You do not want to be the guy that is responsible for that. Best case is you lose your job, worst case is management turns a blind eye to the project team hiding organic material in the corners of your office (give it a couple of weeks, you won’t enjoy it).

Go out and do some reading on writing readable and maintainable code. Aside of learning the basics of a language, it is the single greatest thing you can do to improve your abilities as a programmer.

This happened last month, so to some of you I am sure this is old news. But for those of you who just want a great read, you should check out this article on Linux kernel developer Con Kolivas, and why he quit kernel development forever.

Why I quit: kernel developer Con Kolivas | APC Magazine

Con did a lot for the kernel as far as desktop enhancements go, so anyone who has used Linux with a kernel >2.4.18 owes him some measure of thanks. I really recommend the article above, the guy had no formal training in computer science, nor did he know how to code before he started working on the kernel. He taught himself how to code by looking at other people’s patches being submitted to the kernel, and became the most well known developer-advocate for Linux on the desktop. Kudos to him - I’m sorry to see him go.

Now all we need are replacements! To anyone who may stumble across this blog, why not take an interest in the Linux kernel? A great introduction on how to get started comes from another kernel developer, Greg Kroah. This is a link to his presentation (it reads very well) on the Myths, Lies, and Truths About the Linux Kernel from his OLS 2006 keynote. All you have to lose is time with your girlfriends!