I had a really fantastic time at OSCON this year. When I went to OSCON in 2006, I was a little put off by the fact that there seemed to be very little focus on systems administration, and meanwhile systems administrators are responsible for huge swaths of open source software growth in businesses large and small. I’m happy to report that this year’s OSCON had quite a bit of focus on topics of interest to systems folks, including myself. Thanks, ORA!

But on the 5-day flight back to the east coast (ok, maybe it just felt like 5 days), I had a chance to think more about what I had seen and heard. I had a lot of conversations, mostly with developers, about cloud computing initiatives like AppEngine, Amazone Web Services, BigTable, and the like. My take on this is that Amazon and Google are providing developer-centric interfaces to help them solve traditional systems administration problems…. and they appear to be doing it with some success.

So one might ask… “where does this leave the lowly sysadmin?”

It leaves you in an extremely fast-paced, ever-changing technological landscape with a set of needs, tools, and technologies that never stop evolving, and cause a lot of perceived community fragmentation while everyone scrambles to figure out which direction is “the way to go”. Sound familiar? It should. It’s exactly where you’ve been for your entire career. Some would say it’s the fact that things never seem to stagnate that makes them love system administration in the first place!

What I view as being pretty exciting (and I hope this continues - call me a blasphemer) is that, because of these developer-centric systems interfaces, there’s a bit of a forced convergence: developers have no choice but to have some understanding of what’s happening under the hood, because they’re going to have to write tools to essentially “rope in the cloud” — to manage all of this stuff. On the other hand, systems administrators would probably do well to take this opportunity to do more interesting stuff with code than the typical pushing out of account information, watchdog scripts, custom log parsers, system tool wrappers, and the like.

It’s a great time to pick up a new language, too, if you have an interest. Lots of sysadmins have picked up Ruby and/or Python as a means of broadening their horizons. If you use and like Perl, there’s no reason you can’t use it, but seeing what the hubbub is about surrounding newer stuff that looks like it’s more than a fad by now can’t hurt. I personally chose Python as my primary language because I never liked Perl, and Ruby *looks* like Perl to me (though I still dabble with it just to be famiiliar). If you *like* Perl, check out Ruby. If you only use Perl because you have to, give Python a shot! There are client libraries for a lot of these new services available in Ruby, Python, Perl, and PHP.

Dive into the cloud! The water’s fine!

I’ve been seeing this SQL Server code running wild for the past few days:

DECLARE @T varchar(255), @C varchar(255);
DECLARE Table_Cursor CURSOR FOR
SELECT a.name, b.name
FROM sysobjects a, syscolumns b
WHERE a.id = b.id AND a.xtype = 'u' AND
(b.xtype = 99 OR
b.xtype = 35 OR
b.xtype = 231 OR
b.xtype = 167);
OPEN Table_Cursor;
FETCH NEXT FROM Table_Cursor INTO @T, @C;
WHILE (@@FETCH_STATUS = 0) BEGIN
EXEC(
'update [' + @T + '] set [' + @C + '] =
rtrim(convert(varchar,[' + @C + ']))+
''Explot JavaScript goes here'''
);
FETCH NEXT FROM Table_Cursor INTO @T, @C;
END;
CLOSE Table_Cursor;
DEALLOCATE Table_Cursor;

Actually, the insertion of this code into web servers happens from a DECLARE statement that encodes the entire payload in hexadecimal characters, which is then helpfully translated into exploit code by your own database server. In a way, your SQL Server database hacks itself.

It’s been around since January, but the payloads have been different. Either multiple people are using the exploit, or the exploits are modified on a per-hire basis and delivered through the same bot network. One hacker with a client hack pays some other hacker with a server hack, and they go to town. The process attacks hundreds of insecure websites, which in turn attacks thousands of client hosts.

The interesting thing is that this code doesn’t really have a catchy name like all of the other exploits. Server exploits never get much attention in the media compared to viruses that attack millions of workstations at once, like Nimda, Melissa, or others.

DBA1: “Hey, did you hear that one website got compromised by ‘Column Smasher’?”

DBA2: “No, I thought it was called ‘Lemon Pledge’.”

DBA1: “Why would a database exploit be called ‘Lemon Pledge’?”

DBA2: “Because it cleans everything from your tables.”

There have been a few reports of these attacks hitting Cold Fusion servers. Thanks to Google and the .cfm file extension, it isn’t too hard to find a Cold Fusion server out there. And if someone is using Cold Fusion, they’re probably just coding in CFML, which isn’t a very robust language.

Remember FormMail? Formmail was that horrible CGI script that everyone abused to send out spam. Well, it seems like people haven’t taken the hint. All that information passed from a web client to the server through a GET or POST method should be considered dangerous. Web page constraints, JavaScript/AJAX validators, and hidden form fields can’t protect your database. Depending on how your web forms and server applications are written, you’re allowing outside input from unknown sources to be inserted into the middle of your humble SQL statement. The most important firewall to protect your database is your server side application.

Here’s a few things you can do to protect your database from SQL injection attacks. Suggestions 1 through 3 range from low level sanitation to high level extreme SQL programming. Suggestion 4 is geared more towards administrative efforts for a Database Administrator to protect their system from a web developers badly programmed application.

1. Sanitize the input. Run regular expresison filters that will ideally work on a pattern of allowed characters, Accept only alphabetical characters and numerals, but strip everything else out.

2. Use SQL bind variables to contain web application input, after it’s been filtered.

3. Using stored procedures can give you the benefit of limiting what statements your web application can execute on the database server. Keep in mind that stored procedures are still pretty complex, and unless they’re coded properly, they may not add additional security from the application.

4. Block select privileges to the sysobjects and other system tables. And just because you’re not running SQL Server, don’t assume you’re in the clear. Check with your DB vendor to see specific instructions on how your server handles the Information Schema portion of the SQL-92 standard.

“(Twitteriffic/Urban Spoon/Where) would like to use your current location”

Once I select “Ok” two times while running the program, the iPhone no longer asks; it assumes the program has carte-blanche to know my location. I haven’t been prompted for any other security issues yet, but I’ve only used about six or seven applications so far.

Granting privilege escalation on an application by application basis is good, but I’d like to make a couple of recommendation for the next release of the iPhone OS.

1. From the “Settings” application, give me a master list of all installed applications, so I can say in advance whether an app can have, cannot have, or must always ask for the privilege it is requesting.

2. Clearly identify that the OS is prompting for privilege escalation, and not the application itself.

3. Create more privileges. For example, Twitteriffic needs permission to know where I am; but MyStreets doesn’t need permission to read and sort all of the contacts on my phone. And with VoiceRecord, I was never prompted for permission for the application to listen to my microphone. That would suggest that any application could just read the contact info or use the microphone at any time. Maybe I’m wrong, or maybe Apple’s application screeners check this out beforehand.

I came, I saw, I conquered, and somehow, I also managed to activate my new 3G iPhone. And I seem to be the only guy I know in my area that has made it past that final step.

Early this morning, Two co-workers, assorted friends, and myself, found each other at different points in the line. The following is a transcript of the events, recreated from SMS messages and Twitter posts

6:00 Woke up late.
6:41 (incoming SMS from Clay) Where are you?
6:42 (reply to Clay) Sorry, woke up late. ETA to MoA = 12 minutes
6:55 (to Clay) Fyckinf light rail car blocking mall entrance!
6:56 (reply from Clay) LOL!
7:00 Parked at west entrance, standing in line.
7:20 I download an app to my old EDGE phone to pass the time.
7:35 I can’t believe she cut in front of me and 8 other people. Is she married to that guy?
7:55 Curtains are down
8:00 Line’s moving
8:03 People cheer and applaud at the first sale. (this is starting to make my cynical)
8:30 In store
8:35 With personal concierge. Handled upgrade of At&t account.
8:40 Sign-in to iTunes failed.
8:45 Bought hard plastic case from Contour Design. Unlike the old metal phone, the plastic case could never look badass.
8:47 Heading in to the office
8:50 Neither phone works. EDGE unavailable on old phone, but Wi-fi works on both phones.
9:03 Try plugging new phone into PC, and running iTunes. No joy.
9:39 Receive SMS page from At&t.
10:13 Receive second SMS page from At&t. Unexpected incoming call arrives.
10:14 Confirmed that phone is working.

My activation process never was fully completed, but it seems to work. This was my first time camping for an Apple product, so I’ll give the experience a 6 on a scale of 1-10 for excitement. The store purchase flow was smooth (despite the iTunes unresponsiveness), employees were helpful and friendly, and they managed to handle the crowd pretty quickly.

New York and the East Coast had a one hour advantage over us mid-westerners, so there was already a strain on the sale process by the time we were let in. I’m guessing if you are currently holding a brick, it’ll either self activate, or you’ll have better luck with iTunes this afternoon.