[insert title here]

I arrived in Las Vegas for DefCon last night.  Exhausted from my travels, once in my hotel room I naturally pulled out my laptop wanting to get online.  I did not remember the SSID of the hotel’s network from last year, so I pulled up the list of available access points:

As you can see, there were a number of Guest_Internet_Access access points.  There were so many that clearly they had to be the official access points of the hotel.  Seeing the name “lodgenet”, I vaguely recalled that as being the SSID of the network I had used last year, but I thought that maybe the hotel had transitioned to a new name.  So I opened up a browser and tried to navigate to “test.com”.  I was then redirected to the following page:

Ok, easy enough.  This page looked quite legitimate, and it was served over SSL.  Firefox indicated that it had a valid SSL certificate, and I even pulled up the details thereof:

But this was DefCon, and one can never be too cautious.  I looked at some of the branding:  copyright the “Guest Internet Access Corporation”?  That was an odd name for a company, especially one whose domain name was ip3networks.com.  I pulled out my iPhone and did some Googling for this name.  No hits.   I navigated to ip3networks.com, but no page loaded.  Something smelled rather suspicious.  I did find a reference to a company or a product of some sort called IP3 Networks, but it seemed to be owned by a different company.  So at this point, I was largely convinced that this was a scam.  To verify, I tried poking at the page a bit.  I pushed the submit button without filling in any data, but the original page just reloaded with no error message.  I then tried adding in some bogus data and submitted the page:

This was the final conclusive evidence that this was a scam.  Look at the URL: this suggests an MVC framework such as Ruby on Rails (pulling up the source, the error div had id errorExplanation, which is a Railsism), and that I was the first person to submit such a form.  The page was clearly not professionally made.  Reloading the page with a GET request resulted in a 500 error.   Clearly, someone had quickly cooked up a Rails and dropped in a bunch of access points, hoping to harvest credit card numbers.

Anyway, needless to say I’m staying off the paid wireless: Guest_Internet_Access or other.  I’m currently on the DefCon wireless, which advertises itself as being one of the most hostile wireless networks in the world, but I’m taking care to tunnel all of my traffic.

I love DefCon.

In some recent discussion on Zephyr, it was noted that since Python 2.7, the optparse library has been deprecated in favor of the newer and fancier argparse library. Newer and fancier means better, right? Well in this case, there’s a regression in the design, which will make the way that Python handles command line arguments to be quite different from how any other language does. This will lead to usability issues, certainly, and I fear it might even lead to security issues.

So what’s the problem, you ask? argparse has this slick “feature” where it will try to detect if a command-line argument looks like an option or an argument. So it will parse

./myprog -x -y

as having two options, -x and -y, and

./myprog -x foo

as having one option, -x, which was passed the value foo. Now, what happens if you actually want to give -x the value -y? It turns out you can do this, by passing it as

./myprog -x=-y

However, no other option parsing library behaves this way. The argparse docs claim that this behavior is desirable because the user probably made a typo and forgot to pass an argument to -x. However, by making this declaration, the library is making the behavior of the library far harder to predict, and can lead to subtle bugs, including security bugs. In particular, this leads to the potential for “option-injection” attacks, where a user manages to pass a script an option it didn’t expect. For example, if I have a remctl script such as
#!/bin/sh
./myprog -x "$1" "$2"

that is callable by an untrusted user, one would expect that I have done my part to avoid unexpected behavior by properly quoting the user’s arguments. However, if the user were to pass, say, a “-o” and a “/etc/remctl/remctl.conf”, depending on my script’s internal workings, I may have just allowed him or her to inject an unintended option, which could lead to privilege escalation.

So why, I ask, is this behavior in argparse? The only way to make your scripts safe is to pass all options in the form -x="$1", but this is unintuitive and nonstandard. Being nonstandard, doesn’t that defeat the point of having a standard option parsing library in the first place? So while argparse does look like it has a lot of genuine shiny, I’m not going to touch it with a ten foot pole unless this behavior is removed.

(Note: after this Zephyr discussion, a few people filed this issue as a bug report, see http://bugs.python.org/issue9334. If no one else takes Steven up on his offer to review a patch, I might be convinced to write one myself.)

See http://blog.ksplice.com/2010/07/source-diving-for-sysadmins/.

That is all.

This week, I made my first contribution to an open-source community besides SIPB or HCS, both organization where I already know everyone who will be looking at my code.  I submitted a bug report and filed a patch for an unrelated issue in Python’s multiprocessing library:

http://bugs.python.org/issue9207 (bug report)

http://bugs.python.org/issue9205 (patch)

When I submitted these items, I was literally shaking with nervousness.  Here I was, about to inject my observations and code into this unknown community.  What would happen if they rejected my changes outright?  Would I be labeled an outcast, forever a reject from the larger open-source community?  I felt that when I clicked “Submit”, I was really submitting a test whose results would determine my future.  I correspondingly spent far longer than was healthy composing those postings.

Fortunately, it looks like a multiprocessing developer is going to do something with both issues.  I’ve had a bit of dialogue with him, and I feel that on the whole my thoughts have been valued.  On the whole, it’s been a reasonable first experience in this field for me.

A few weeks ago I blogged about source diving, and how I’ve recently found myself reading other developers’ production code.  My preliminary reaction is one of amazement.  In particular, I have run into a surprising amount of code that is simply sloppy, broken in edge cases, or is just poorly architected.  I’m not claiming I could have done any better, but all the same I find myself shocked that the world’s standard for production code is not an order of magnitude higher.

I can’t help but wonder why this is the case.  I look at the engineered products around me, and none of them feel like they are lacking in design or execution.  Whether a can of tuna fish or a vending machine, manufactured goods always seem to have a functional perfection about them, conveying the impression that the designer thought through all of their uses, and the builder ensured that every last part worked to perfection.  The same holds true for buildings, airplanes, and cardboard boxes.  So why is it that for any given piece of software, it’s not a question of whether it’s buggy but rather just how buggy it is?  Why is code that is inefficient, or poorly designed, or just plain barely works running on every one of our machines?  And perhaps most importantly, why are the standards for software any different from those for the rest of the engineering world?

I think the answer is far from simple.  The obvious answer, that a lot of this code is written by hobbyists, does not really tell the full story.  In my experience, code produced by companies does not tend to be especially awesome.  I think the real answer has more to do with software being inherently more complicated than other fields of human engineering, coupled with the fact that it’s easy to ship new versions of the product if you mess it up the first time, as well as the fact that failures really don’t cause too much damage.

That being said, I’m still not really sure if software really is all that complicated, or whether that’s just an excuse that software engineers use to justify their laziness.  What are your thoughts?