As a child, I hated musicals. School holiday viewing was full of them. Inevitably there’d be the Wizard of Oz, or.. shudder.. The Sound of Music, or worse, The Pirates of Penzance. It seemed to me that musicals were nothing but crap.

They made a movie of Annie sometime in the early eighties. I saw it with a bunch of friends. I can’t remember much of the story, just some of the songs. Tomorrow, of course, and I could probably hum along to a few others.

But overall, musicals just didn’t do it for me, and I regarded them as a bit of a cultural lost cause. So when I saw that Rent (a recording of the Broadway show, not the cinematic version) was showing on cable, I wasn’t all that interested. But they kept putting it on, so I recorded it and forgot about it until I was bored one day and figured I’d give it a try.

Boy, what an eye-opener. Rent changed everything I’d ever thought about musicals. No overacting, no overly flowery language, no pretensions. Just a moving story, with contemporary themes, set to some incredible music. Throughout the course of the show, I laughed, I cried, I cheered for the characters. I identified with them and their stories. And I loved the music itself. It challenged everything I’d thought musicals to be.

I felt a genuine sense of sadness and loss when I learned that Jonathan Larson had died the night before opening night. Up until that point in my life, I’d never understood why complete strangers cried when some famous artist or producer or actor or whatever died. But now I do. What a tremendous talent.

Search string LOLZ

This month's funniest search engine hits:

"how the fucking christ do you import a table into sql 2008" (been there, buddy, I feel your pain)




"ww2 tank traps at paddy's flat"  (this is probably only funny to me; somehow Google got to a test site that contained these words as part of a description of a four-day bike ride)

Searching all tables in a database

In my recent travels, I've had to do a bit of discovery work.  Specifically, if we move a DB from one server to another, what will break, and how?

SQL Profiler is great at telling me who's doing what with a particular DB.  With it, I can figure out which SQL clients need their connection strings modified.  Great news!  But here's an interesting twist.  In all the Profiles I captured, I noticed that some of the UPDATE and INSERT statements contained references to UNC paths.  Wouldn't you know it, the paths refer to the DB server that's being decommissioned.

So even if we successfully moved the DB and reconfigured its clients, the application would still break because it would query the DB and get a path that didn't exist anymore.  Well, that's nice to know.  But I wanted to know if there was anything else, anywhere, within the DB that made reference to that server.

I found a most excellent procedure here:–1#2  The code trawls through and returns the table and column names that contain the string you're looking for.  It's enough to point you in the right direction.

If you don't feel like trawling through the entire post, here's the relevant TSQL  Call it by running a command like:



All I want to do is draw a simple diagram with Visio.  But with Visio, nothing's ever easy.  Do the connectors attach to the objects the way I want them to?  No, they do not.  Do they snap to objects when I don't want them to?  Yes, they do.  Inexplicably, Visio's "Detailed Network Diagram" template doesn't contain pictures of any switches or routers.

Seriously.  What the fuck.


Finding the biggest tables in a database

Shamelessly lifted from, with thanks.  😀


SQL injection attacks = fun!

My last few posts about SQL have been about how to exploit a SQL box within the confines of a company network.  I wrote about xp_cmdshell and how it can be combined with a poorly-configured SQL box to produce some very unpleasant results.  This week, someone at work (an apps developer, of course), wanted me to publish a SQL box to the internet.  My answer was an emphatic NO, given this particular app person's history for writing crap code.  This person wanted our network guys to poke a hole through the firewall, sending TCP 1433 to the SQL box.  Talk about a disaster waiting to happen.

Long-time followers of my blog know that I have a Masters degree in Networking and Systems Administration.  One of the subjects of that degree was supposedly about Linux, but actually turned out to be more about security.  At the time I was running an e-commerce site, so I had an interest in securing that site.  Learning about my own site, the server it ran on, the applications that ran on it etc was very enlightening.  I was able to see through the web server logs that my server was being hit 24/7 by automated attack scripts.

The scripts weren't really all that interesting; mostly they were remote file inclusion probes.  Some contained URLs to files on servers that had already been exploited.  I downloaded these files and most of them were pretty stock-standard footprinting scripts.  The sort of thing that details what OS the compromised system is running, what version of its components (eg SSH, which at the time had a pretty nasty vulnerability) etc.  One file contained a huge script that created an IRC bot network.  It was actually fascinating.

But that's not what this post is about.  All of this study and research got me onto SQL injection vulnerabilities.  At the time, there was a poorly-coded osCommerce module called something like Customer Testimonials.  It did not sanitise its inputs, so a properly-crafted URL could reveal information contained within osCommerce's tables…. including credit card details, if the site operator was silly enough to save them (BTW, this is a fundamental breach of PCI standards, which I'll not go into, but is worth learning about if you're interested in e-commerce).  I set up a test VM running osCommerce plus the vulnerable version of the testimonials plugin, and sure enough, I was able to exploit it to view data from osC's tables.

Remote File Inclusion attacks are pretty easy to defend against.  Tell the web server (or relevant module eg PHP) not to run content from URLs or remote file systems.  Defending against SQL Injection attacks can be more complicated.  At its worst, it means checking hundreds of lines of code for silly things like (pseudo-code): 


There are server-level defences to filter out SQL injection attacks, which I won't go into here, but the reality is that bad code will always be bad code.  And bad coders often don't know their code is bad until long after it's in the wild.  With that in mind, and bearing in mind some of the xp_cmdshell exploits I demonstrated in my previous posts, have a wander over to this page.  What I really like about some of the stuff demonstrated here is that one of the examples (example 8) leverages bad SQL security to inject a file, which in turn can be run to perform some malicious task.. or even better, run as part of an IRC botnet.  The possibilities really are endless.  Click some of the links at the bottom of that page to read some very interesting articles on SQL injection attacks.

Bad configuration within a corporate network is one thing.  Sure, it sucks, but it can usually be contained (perhaps by design of other systems such as firewalls, content filters etc).  An internet-facing server, once compromised, can be used to do some pretty bad stuff.  Anyone who thinks publishing a SQL box to the internet consists of only poking a firewall hole on port 1433 needs to rethink their approach to system security.  Actually, anyone who thinks whacking a firewall in front of an internet-facing server will magically protect it.. think again.

What I find really interesting about SQL injection attacks is that they are a multi-layered thing.  They rely on poorly-configured web servers, crappy code, badly-configured SQL boxes etc.  But what's really cool is that the SQL boxes themselves don't need to be presented to the internet.  The only requirement is that a the web server (or more generically, the application server) have connectivity to the SQL box.  Hiding those SQL boxes on a private subnet won't help.  Hiding them behind an internal firewall won't help.  Hiding them on protected VLANs won't help.  It won't matter.  Because once the web server manages to talk to the SQL box, once the web-server-generated query traverses the wire from web box to SQL box, the scope for damage is already present.

What I'm saying, folks, is that security is a multi-layered thing.  I don't claim to have all the answers.  I'm not a security expert.  But I am security-aware.  All good sysadmins ask questions about the code that's running on their boxes.  What does this code do?  Why does it do it that way?  Can it be done in a more secure fashion?  What does it really need access to?  Can the code be run isolated?  Do we have sufficient logging to keep track of breaches?  If this box is compromised, what else can it access?  If there is a breach, what is the scope of information disclosure?  There's so many questions to ask.  Don't be afraid to ask them.  If your apps people can't tell you this stuff off the top of their heads, stamp a great big red DENIED across the request.


SQL 2008 schema explanation

I've been struggling to get my head around schemas in SQL 2008.  BOL has this incredibly useful piece of wisdom to impart:  "Database schemas act as namespaces or containers for objects, such as tables, views, procedures, and functions, that can be found in the sys.objects catalog view".  Erm.  OK.

That actually didn't help me much.  What do they do?  What are they for?  Why not just apply permissions directly?

Finally, I read this article.  I know Googling will provide lots of hits on "SQL 2008 schema", and all of them say much the same as this article, but for some reason, this article made it all click.  Schemas are roughly analagous to folders in a file system.  An individual file can only live within a single folder at any given time.  A folder can contain lots of files.  In order to apply permissions within the file system, one doesn't waste one's time by applying permissions against each and every file within a folder.  Permissions are applied at the folder level, and the files within the folder inherit those permissions.  That's kind of how SQL schemas work.  I think.

I'm still getting it all straight.  But I think this article does a good job of putting it together.  Unless I've got it all wrong.  In which case, it's a terrible article.

Joy from simple things

Two things have happened recently that make me giddy with joy.


  1. I installed the latest beta nVidia driver, and whaddya know, the crashing has stopped.  Thankyou, whichever deity is responsible for this.


  1. I've had a longstanding problem with iTunes not working or playing well with my G15 keyboard.  Every once in a while, a new release of iTunes comes out and it's fixed.. until the next update.  The last two updates have been consistently bad.  The short story is that unless iTunes is in the foreground, pressing "Play/Pause" on the keyboard will pause it for a second, then resume playing.  Very fucking useful.  I mean, if I need to bring iTunes to the foreground for the button to work, it defeats the whole fucking purpose of the button.  I've Googled about this problem in the past, but have never found a satisfactory solution until now.  This post describes a very simple fix.  And damn, it works!