More On Migrating From Drupal To Blogofile

I wrote an earlier post on converting a Drupal site to Blogofile. I couldn’t be happier with how that turned out as it allowed me to immediately start using Blogofile while still keeping my old Drupal content online. Sweet! But who wants to continue running the two systems in parallel forever? I certainly don’t, and after a code sprint I came up with a way to completely transition off Drupal.

First, I manually converted the most popular nodes on my Drupal site to Blogofile. I moved all of my Project content to GitHub, and wrote a Blogofile photo album that replaced 99% of the Drupal photo album functionality that I actually used. At the end of this process, there were only Blog, Story, and Page nodes left in Drupal.

Next, I changed drupalmigrate.py to generate a bunch of Blogofile post files for each of those remaining Drupal nodes. I added these settings to my _config.py:

controllers.drupalmigrate.makeposts = False
controllers.drupalmigrate.mainusername = 'kirk'
controllers.drupalmigrate.startpostnum = 1000

then ran “../bin/blogofile build -v” to create about 70 new post files. When that finished successfully, I removed those settings.

Finally, I added new code to drupalmigrate.py to generate a different set of RewriteRules that redirect the old Drupal node permalinks to their new Blogofile locations. It makes rules like:

RewriteRule ^/yet-another-python-map(/|$) /2008/04/16/yet-another-python-map/ [R=301,L]

where /yet-another-python-map is the node’s old location in Drupal and /2008/04/16/yet-another-python-map/ is the new Blogofile URL. To activate that, I added this to my _config.py:

controllers.drupalmigrate.makepermalinkredirs = True
controllers.drupalmigrate.redirectrulefile = '_generatedfiles/redirectrewriterules.txt'

With this in place, there was nothing left in Drupal so I decommissioned it and changed my Apache configuration to something like:

    <VirtualHost *:80>
        ServerName honeypot.net
        ServerAlias www.honeypot.net
        CustomLog /var/log/httpd/honeypot.net-access.log combined
        DirectoryIndex index.html
        DocumentRoot /usr/local/www/honeypot.net/honeypot/_site
        <Directory /usr/local/www/honeypot.net/honeypot/_site>
            Order Deny,Allow
            Allow from All
        </Directory>

        RewriteEngine On
        Include /usr/local/www/honeypot.net/honeypot/_generatedfiles/redirectrewriterules.txt
    </VirtualHost>

I’ll leave the Drupal node redirects in there permanently so that all the links to my site will continue to work.

On Generated Versus Random Passwords

I was reading a story about a hacked password database and saw this comment where the poster wanted to make a little program to generate non-random passwords for every site he visits:

I was thinking of something simpler such as “echo MyPassword69! slashdot.org|md5sum” and then
“aaa53a64cbb02f01d79e6aa05f0027ba” using that as my password since many sites will take 32-character long passwords or they
will truncate for you. More generalized than PasswordMaker and easier to access but no alpha-num+symbol translation and only
(32) 0-9af characters but that should be random enough, or you can do sha1sum instead for a little longer hash string.

I posted a reply but I wanted to repeat it here for the sake of my friends who don’t read Slashdot. If you’ve ever cooked up your own scheme for coming up with passwords or if you’ve used the PasswordMaker system (or ones like it), you need to read this:


DO NOT DO THIS. I don’t mean this disrespectfully, but you don’t know what you’re doing. That’s OK! People not named “Bruce” generally suck at secure algorithms. Crypto is hard and has unexpected implications until you’re much more knowledgeable on the subject than you (or I) currently are. For example, suppose that hypothetical site helpfully truncates your password to 8 chars. By storing only 8 hex digits, you’ve reduced your password’s keyspace to just 32 bits. If you used an algorithm with base64 encoding instead, you’d get the same complexity in only 5.3 chars.

Despite what you claim, you’re really much better off using a secure storage app that creates truly random passwords for you and stores them in a securely encrypted file. In another post here I mention that I use 1Password, but really any reputable app will get you the same protections. Your algorithm is a “security by obscurity” system; if someone knows your algorithm, gaining your master password gives them full access to every account you have. Contrast with a password locker where you can change your master password before the attacker gets access to the secret store (which they may never be able to do if you’ve kept it secure!), and in the worst case scenario provides you with a list of accounts you need to change.

I haven’t used PasswordMaker but I’d apply the same criticisms to them. If an attacker knows that you use PasswordMaker, they can narrow down the search space based on the very few things you can vary:

  • URL (the attacker will have this)
  • character set (dropdown gives you 6 choices)
  • which of nine hash algorithms was used (actually 13 – the FAQ is outdated)
  • modifier (algorithmically, part of your password)
  • username (attacker will have this or can likely guess it easily)
  • password length (let’s say, likely to be between 8 and 20 chars, so 13 options)
  • password prefix (stupid idea that reduces your password’s complexity)
  • password suffix (stupid idea that reduces your password’s complexity)
  • which of nine l33t-speak levels was used
  • when l33t-speak was applied (total of 28 options: 9 levels each at three different “Use l33t” times, plus “not at all”)

My comments about the modifier being part of your password? Basically you’re concatenating those strings together to create a longer password in some manner. There’s not really a difference, and that’s assuming you actually use the modifier.

So, back to our attack scenario where a hacker has your master password, username, and a URL they want to visit: disregarding the prefix and suffix options, they have 6 * 13 * 13 * 28 = 28,392 possible output passwords to test. That should keep them busy for at least a minute or two. And once they’ve guessed your combination, they can probably use the same settings on every other website you visit. Oh, and when you’ve found out that your password is compromised? Hope you remember every website you’ve ever used PasswordMaker on!

Finally, if you’ve ever used the online version of PasswordMaker, even once, then you have to assume that your password is compromised. If their site has ever been compromised – and it’s hosted on a content delivery network with a lot of other websites – the attacker could easily have placed a script on the page to submit everything you type into the password generation form to a server in a distant country. Security demands that you have to assume this has happened.

Seriously, please don’t do this stuff. I’d much rather see you using pwgen to create truly random passwords and then using something like GnuPG to store them all in a strongly-encrypted file.


The summary version is this: use a password manager like 1Password to use a different hard-to-guess password on every website you visit. Don’t use some invented system to come up with passwords on your own because there’s a very poor chance that we mere mortals will get it right.

Migrating Drupal To Blogofile

I have a Drupal site with nearly a thousand nodes, several having over 100,000 hits. I wanted to migrate to Blogofile but absolutely did not want to start over or make this a major hassle. Instead, I used some Apache RewriteRules to gradually and seamlessly switch from Drupal to Blogofile one post at a time. Here’s how I did it, using my site’s real name of http://honeypot.net/ to give concrete examples:

  1. Migrated my comments to Disqus. Drupal’s own disqus module has built-in export functionality to make this a snap.
  2. Set up internal DNS to add a new A record, drupal.honeypot.net, for my Drupal site. Since this is a site that no one ever needs to visit directly, an entry in /etc/hosts should work just as well.
  3. Renamed my Apache’s honeypot.net.conf to drupal.honeypot.net.conf and changed the ServerName to “drupal.honeypot.net”.
  4. Created a new honeypot.net.conf to serve only static Blogofile files while passing all other requests through to drupal.honeypot.net. Here’s the shortened version of it:

    <VirtualHost *:80>
        ServerName honeypot.net
        ServerAlias www.honeypot.net
        CustomLog /var/log/httpd/honeypot.net-access.log combined
        DirectoryIndex index.html
        DocumentRoot /usr/local/www/honeypot.net/honeypot/_site
        <Directory /usr/local/www/honeypot.net/honeypot/_site>
            Order Deny,Allow
            Allow from All
        </Directory>
    
    
    
    # Serve some stuff locally but pass everything else through to Drupal
    RewriteEngine On
    Include /usr/local/www/honeypot.net/honeypot/_generatedfiles/rewriterules.txt
    RewriteRule ^/?(.*)$ http://drupal.honeypot.net/$1 [P,L]
    

    </VirtualHost>

The last lines are where the magic happens. I created a new Blogofile controller: drupalmigrate.py. It creates the file mentioned above (rewriterules.txt) that tells Apache not to tamper with any file generated by Blogofile. That file has entries like:

RewriteRule ^/$ - [L]
RewriteRule ^/2011(/|$) - [L]
RewriteRule ^/archive(/|$) - [L]
RewriteRule ^/category(/|$) - [L]
RewriteRule ^/favicon.ico$ - [L]
RewriteRule ^/feed(/|$) - [L]
RewriteRule ^/filtering-spam-postfix(/|$) - [L]
RewriteRule ^/index.html$ - [L]
RewriteRule ^/my-ecco-shoes-are-junk(/|$) - [L]
RewriteRule ^/page(/|$) - [L]
RewriteRule ^/robots.txt$ - [L]
RewriteRule ^/scam-calls-card-services(/|$) - [L]
RewriteRule ^/theme(/|$) - [L]

for every file in Blogofile’s _site directory. When an incoming web request matches one of those patterns, Apache stops processing any further RewriteRules and serves the file directly from the DocumentRoot directory. If none of those pattern matches, the final RewriteRule in my honeypot.net.conf file makes a proxy request for the same path from http://drupal.honeypot.net/ .

That is, if a visitor requests http://honeypot.net/robots.txt, the RewriteRule in rewriterules.txt will cause Apache to serve the file from /usr/local/www/honeypot.net/honeypot/_site/robots.txt. If a visitor requests http://honeypot.net/something-else, Apache will request the file from http://drupal.honeypot.net/something-else and return the results. None of this is visible to the user. They don’t receive any redirects, links to drupal.honeypot.net, or any other indication that they’re seeing content from two different systems.

The controller also creates a list of every node in my Drupal database so I can <%include /> it into my site’s index.html.mako file like this:

<hr />
<p>These posts haven't been converted to the new system but are still available:</p>
<%include file="_templates/olddrupalindex.mako" />

When drupalmigrate.py is generating the site index, it skips any Drupal nodes that have the same permalink as a Blogofile post. As I take my time converting my Drupal content, more and more will be served by Blogofile until eventually none is left.

By starting with the most popular content and working my way down, I can make sure that all my heavy-traffic pages are served as lightning-fast static pages. This could even work as a form of website accelerator where popular pages are “compiled” by Blogofile for fast access. By fast, I mean that my untuned home server can sustain about 9,100 hits and 240MB of traffic per second. Until Google decides to use me for their home page, I think that’ll be sufficient for my little site.

Making DOS USB Images On A Mac

I needed to run a BIOS flash utility that was only available for DOS. To complicate matters, the server I needed to run it on doesn’t have a floppy or CD-ROM drive. I figured I’d hop on the Internet and download a bootable USB flash drive image. Right? Wrong.

I found a lot of instructions for how to make such an image if you already have a running Windows or Linux desktop, but they weren’t very helpful for me and my Mac. After some trial and error, I managed to create my own homemade bootable USB flash drive image. It’s available at http://www.mediafire.com/?aoa8u1k1fedf4yq if you just want a premade ready-to-download file.

If you want a custom version, or you don’t trust the one I’ve made – and who’d blame you? I’m some random stranger on the Internet! – here’s how you can make your own bootable image under OS X:

Relax!

  1. There are a lot of steps, but they’re easy! I wanted to err on the side of being more detailed than necessary, rather than skipping “obvious” steps that might not be quite so easy for people who haven’t done this before.

Download VirtualBox and install it

  1. Download VirtualBox. I used version 4.1.4. The version available to you today might look different but should work mostly the same way.
  2. Open the “VirtualBox-[some-long-number]-OSX.dmg” disk image.
  3. Double-click the “VirtualBox.mpkg” icon to run the installer.
  4. Click “Continue”.
  5. Click “Continue”.
  6. Click “Install”.
  7. Enter your password and click “Install Software”.
  8. When it’s finished copying files, etc., click “Close”.

Download FreeDOS and create a virtual machine for it

  1. Download the FreeDOS “Base CD” called “fdbasecd.iso”. Note: the first mirror I tried to download from didn’t work. If that happens, look around on the other mirrors until you find one that does.
  2. Open your “Applications” folder and run the “VirtualBox” program.
  3. Click the “New” button to create a new virtual machine. This launches the “New Virtual Machine Wizard”. Click “Continue” to get past the introduction.
  4. Name your new VM something reasonable. I used “FreeDOS”, and whatever name you enter here will appear throughout all the following steps so you probably should, too.
  5. Set your “Operating System” to “Other”, and “Version” to “DOS”. (If you typed “FreeDOS” in the last step, this will already be done for you.) Continue.
  6. Leave the “Base Memory Size” slider at 32MB and continue.
  7. Make sure “Start-up Disk” is selected, choose “Create new hard disk”, and continue.
  8. Select “File type” of “VDI (VirtualBox Disk Image)” and continue.
  9. Select “Dynamically allocated” and continue.
  10. Keep the default “Location” of “FreeDOS”.
  11. Decision time: how big do you want to make your image? The full install of FreeDOS will take about 7MB, and you’ll want to leave a little room for your own files. On the other hand, the larger you make this image, the longer it’ll take to copy onto your USB flash drive. You certainly don’t want to make it so large that it won’t actually fit on your USB flash drive. An 8GB nearly-entirely-empty image will be worthless if you only have a 2GB drive. I splurged a little and made my image 32MB (by clicking in the “Size” textbox and typing “32MB”. I hate size sliders.). Click “Continue”.
  12. Click “Create”.
  13. Make sure your new “FreeDOS” virtual machine is highlighted on the left side of the VirtualBox window.
  14. On the right-hand side, look for the section labeled “Storage” and click on the word “Storage” in that title bar.
  15. Click the word “Empty” next to the CD-ROM icon.
  16. Under “Attributes”, click the CD-ROM icon to open a file chooser, select “Choose a virtual CD/DVD disk file…”, and select the FreeDOS Base CD image you downloaded at the beginning. It’ll probably be in your “Downloads” folder. When you’ve selected it, click “Open”.
  17. Back on the “FreeDOS – Storage” window, click “OK”.

Install FreeDOS

  1. Back on the main VirtualBox window, near the top, click “Start” to launch the virtual machine you just made.
  2. A note about VirtualBox: when you click the VM window or start typing, VirtualBox will “capture” your mouse cursor and keyboard so that all key presses will go straight to the VM and not your OS X desktop. To get them back, press the left [command] key on your keyboard.
  3. At the FreeDOS boot screen, press “1” and [return] to boot from the CD-ROM image.
  4. Hit [return] to “Install to harddisk”.
  5. Hit [return] to select English, or the up and down keyboard arrow keys to choose another language and then [return].
  6. Hit [return] to “Prepare the harddisk”.
  7. Hit [return] in the “XFDisk Options” window.
  8. Hit [return] to open the “Options” menu. “New Partition” will be selected. Hit [return] again. “Primary Partition” will be selected. Again, [return]. The maximum drive size should appear in the “Partition Size” box. If not, change that value to the largest number it will allow. Hit [return].
  9. Do you want to initialize the Partition Area? Yes. Hit [return].
  10. Do you want to initialize the whole Partition Area? Oh, sure. Press the left arrow key to select “YES”, then hit [return].
  11. Hit [return] to open the “Options” menu again. Use the arrow keys to scroll down to “Install Bootmanager” and hit [return].
  12. Press [F3] to leave XFDisk.
  13. Do you want to write the Partition Table? Yep. Press the left arrow to select “YES” and hit [return]. A “Writing Changes” window will open and a progress bar will scroll across to 100%.
  14. Hit [return] to reboot the virtual machine.
  15. This doesn’t actually seem to reboot the virtual machine. That’s OK. Press the left [command] key to give the mouse and keyboard back to OS X, then click the red “close window” button on the “FreeDOS [running]” window to shut it down. Choose “Power off the machine” and click “OK”.
  16. Back at the main VirtualBox window, click “Start” to re-launch the VM.
  17. Press “1” and [return] to “Continue to boot FreeDOS from CD-ROM”, just like you did before.
  18. Press [return] to select “Install to harddisk” again. This will take you to a different part of the installation process this time.
  19. Select your language and hit [return].
  20. Make sure “Yes” is selected, and hit [return] to let FreeDOS format your virtual disk image.
  21. Proceed with format? Type “YES” and hit [return]. The format process will probably finish too quickly for you to actually watch it.
  22. Now you should be at the “FreeDOS 1.0 Final Distribution” screen with “Continue with FreeDOS installation” already selected. Hit [return] to start the installer.
  23. Make sure “1) Start installation of FreeDOS 1.0 Final” is selected and hit [return].
  24. You’ll see the GNU General Public License, version 2 text. Follow that link and read it sometime; it’s pretty brilliant. Hit [return] to accept it.
  25. Ready to install the FreeDOS software? You bet. Hit [return].
  26. Hit [return] to accep the default installation location.
  27. “YES”, the above directories are correct. Hit [return].
  28. Hit [return] again to accept the selection of programs to install.
  29. Proceed with installation? Yes. Hit [return].
  30. Watch in amazement and how quickly the OS is copied over to your virtual disk image. Hit [return] to continue when it’s done.
  31. The VM will reboot. At the boot screen, press “h” and [return] to boot your new disk image. In a few seconds, you’ll see an old familiar “C:\” prompt.
  32. Press the left [command] key to release your keyboard and mouse again, then click the red “close window” icon to shut down the VM. Make sure “Power off the machine” is selected and click “OK”.

Convert the VirtualBox disk image into a “raw” image

  1. Open a Terminal.app window by clicking the Finder icon in your dock, then “Applications”, then opening the “Utilies” folder, then double-clicking “Terminal”.
  2. Copy this command, paste it into the terminal window, then hit [return]:

    /Applications/VirtualBox.app/Contents/Resources/VirtualBoxVM.app/Contents/MacOS/VBoxManage internalcommands converttoraw ~/"VirtualBox VMs/FreeDOS/FreeDOS.vdi" ~/Desktop/freedos.img
    

This will turn your VirtualBox disk image file into a “raw” image file on your desktop named “freedos.img”. It won’t alter your original disk image in any way, so if you accidentally delete or badly damage your “raw” image, you can re-run this command to get a fresh, new one.

Prepare your USB flash drive

  1. Plug your USB flash drive into your Mac.
  2. If your Mac can’t the drive, a new dialog window will open saying “The disk you inserted was not readable by this computer.” Follow these instructions:

    1. Click “Ignore”.
    2. Go back into your terminal window and run this command:

      diskutil list
      
    3. You’ll see a list of disk devices (like “/dev/disk2”), their contents, and their sizes. Look for the one you think is your USB flash drive. Run this command to make sure, after replacing “/dev/disk2” with the actual name of the device you picked in the last step.

      diskutil info /dev/disk2
      

    Make sure the “Device / Media Name:” and “Total Size:” fields look right. If not, look at the output of diskutil list again to pick another likely candidate and repeat the step until you’re sure you’ve picked the correct drive to complete eradicate, erase, destroy, and otherwise render completely 100% unrecoverable. OS X will attempt to prevent you from overwriting the contents of drives that are currently in use – like, say, your main system disk – but don’t chance it. Remember the name of this drive!

  3. If your Mac did read the drive, it will have automatically mounted it and you’ll see its desktop icon. Follow these instructions:

    1. Go back into your terminal window and run this command:

      diskutil list
      
    2. Look for the drive name in the output of that command. It will have the same name as the desktop icon.

    3. Look for the name of the disk device (like “/dev/disk2”) for that drive and remember it (with the same warnings as in the section above that you got to skip).
    4. Unmount the drive by running this command:

      diskutil unmount "/Volumes/[whatever the desktop icon is called]"
      
    5. This is not the same as dragging the drive into the trash, so don’t attempt to eject it that way.

Copy your drive image onto the USB flash drive

  1. Go back to your terminal window.
  2. Run these commands, but substitute “/dev/fakediskname” with the device name you discovered on the previous section:

    cd ~/Desktop
    sudo dd if=freedos.img of=/dev/fakediskname bs=1m
    
  3. After the last command finishes, OS X will automatically mount your USB flash drive and you’ll see a new “FREEDOS” drive icon on your desktop.

Add your own apps to the image

  1. Drag your BIOS flasher utility, game, or other program onto the “FREEDOS” icon to copy it onto the USB flash drive.
  2. When finished, drag the “FREEDOS” drive icon onto the trashcan to unmount it.

Done.

  1. You’re finished. Use your USB flash drive to update your computer’s BIOS, play old DOS games, or do whatever else you had in mind.
  2. Keep the “freedos.img” file around. If you ever need it again, start over from the “Prepare your USB flash drive” section which is entirely self-contained. That is, it doesn’t require any software that doesn’t come pre-installed on a Mac, so even if you’ve uninstalled VirtualBox you can still re-use your handy drive image.

Just Get Home Already

While waiting for Jen to return from a conference, I thought about calling her to get her estimated time of arrival, or her ETA. I realized she might be might be pretty far away still and thought I better ask for an estimate of the accuracy of the estimate, or meta-estimate: her META. Hey, neat! META can be a recursive acronym for “meta-ETA”, so it also references the nature of the acronym itself, sort of making META a meta-acronym, which truly makes it both meta and META.

In Defense Of The Model M

There are few joys in life like using something that is the perfect expression of its intent. Each trade has its representative tools, and their common trait is quality, even if it’s not obvious to the casual observer, and often counterintuitive. The best tools in a category are almost always the least flashy, and rarely the ones a new practitioner would choose.

The Model M keyboard is like that: it’s loud, ugly, heavy, and utterly lacking modern niceties like buttons to change your sound volume or check your email. And yet, it has that transcendent feeling that’s hard to explain, that sense of rightness where you realize that you’re using the best that’s ever been made, that every change since then has been superfluous and cosmetic. With time, the loud clacking becomes the background music of your work, the harmony that tells you that your thoughts have become words. Its beige boxiness yields to elegant simplicity and the realization that true beauty is born of function, not appearance. The sheer weight of the thing turns to solidity and the confidence that it will stay where you put it. The dearth of features becomes the singleminded dedication to the parts that really matter and a proud disregard of unneeded distractions.

A tool attains its peak when a craftsman forgets that he’s using it because it has become an extension of himself. Thus the humble Model M has become the iconic favorite of hackers everywhere, an ode to the engineers who grasped for excellence and acheived it.

Komando Gorilla

A man calls into a radio show because his son received an obviously-spam email telling him that he’s been kicked off of Facebook. The host gets worked up and sympathetic and wants to handle it like a legitimate eviction notice, even though no one’s verified whether the kid can still log into his account.

Another man calls a radio show because his business stores a lot of personal information about its customers, and he wants to know what he should do to keep that data safe. The host tells him to install Norton Internet Security.

What do they have in common? They made the mistake of asking Kim Komando for help.

Honestly, for being the self-proclaimed “America’s Digital Goddess”, she gives the worst advice I’ve ever heard. Every time I accidentally hear her show, I end up screaming invectives at my car radio.

Seriously, do not take her advice. Ever. It is awful, varying only in the degree of its incompetence, and is likely to do more harm than good in every case I’ve ever heard her discuss. As much as I don’t like doing a lot of tech support on my off time, I’d much rather help my family and friends from the start than spent twice the time trying to undo her suggestions.

Yet Another Python Map

In another article, I described a replacement for Python’s built-in map() function that could take advantage of multi-processing systems. That one was based on the standard Unix fork(). Since then, I’ve written another based on Parallel Python that is much simpler and lets other, better-tested code do all the hard work. It could also be easily extended to run on a cluster instead of just the local system, but I haven’t been inclined to tinker with that too much yet.

Note one possibly important difference from the builtin map() function: this version returns a generator that yields values as they are calculated. That way, you can launch the parallel processes then go on with other work while you give the workers a chance to finish their jobs.

Kudos to Connelly for nudging me to finally publish this.

Download: ppmap.py

Fun With Software Licenses

Did you know that you’re probably not allowed to make backups of your computer? It’s true, if you believe in the legal fiction known as “End User License Agreements” (or EULAs), which are those annoyingly long contracts where you have to click “I Agree” before you’re allowed to install some program or another.

For example, here’s a snippet of the Adobe Integrated Runtime (AIR) End User License Agreement:

2.3 Backup Copy. You may make one backup copy of the Software, provided your backup copy is not installed or used on any computer.

Nice, huh? If you install this software, its EULA forbids you from making more than one backup copy. This is a deal-breaker for business which keep multiple backup archives from days, weeks, and months past. According to this agreement, you could hypothetically alter your corporate storage system to ignore each of the files that would be installed, but realistically no one would ever even attempt this.

This is just one more reason to be grateful that EULAs are almost universally believed to be legally unenforcable. However, unless you’re willing to tell a jury that you don’t think you’re bound by such an agreement, remember that every piece of software with a similar license is a potential time bomb. Theoretically, you could be sued just for having it, even if you probably wouldn’t be found liable.

Fans of commercial software often talk about the “impracticality” of Free or Open Source Software, but the alternatives are starting to look a lot worse.

Buffer Overrun In Antitrust

Skip this unless you’re really, really geeky.

Still with us? OK. In the movie “Antitrust“, there’s a screenshot of some code that has a possible Denial Of Service vulnerability:

 /* are we doing a GET or just a HEAD */
            boolean doingGet;
            /* beginning of file name */
            int index;
            if (buf[0] == (byte)'G' &&
                buf[1] == (byte)'E' &&
                buf[2] == (byte)'T' &&
                buf[3] == (byte)' ') {
                doingGet = true;
                index = 4;
            } else if (buf[0] == (byte)'H' &&
                       buf[1] == (byte)'E' &&
                       buf[2] == (byte)'A' &&
                       buf[3] == (byte)'D' &&
                       buf[4] == (byte)' ') {
                doingGet = false;
                index = 5;
            } else {
                /* we don't support this method */
                ps.print("HTTP/1.0 " + HTTP_BAD_METHOD +
                           " unsupported method type: ");
                ps.write(buf, 0, 5);
                ps.write(EOL);
                ps.flush();
                s.close();
                return;
            }

Because I can’t resist such things, I paused the movie to read over the code. Now, I’m assuming this is Java instead of C++ because “boolean” wasn’t spelled “bool”, although I’m not sure why they’d be using Java for performance critical code. Anyway. See the “ps.write(buf, 0, 5);” line near the end? Well, “buf” is presumably the string that the client sent to the server. If the client is broken (or malicious) enough to misspell “GET” and “HEAD”, then the server politely tries to tell the client what it did wrong by sending “buf”‘s value back.

Which brings us to the hack. If “buf” is less than five characters long, then that “ps.write” line will attempt to read past the end of “buf”. If the calling function doesn’t handle index error exceptions, boom! The service crashes: Denial Of Service. Note that this is still better than the C++ equivalent, which would write the contents of memory immediately following the end of “buf” back to the client.

No, I’m not exactly good at sitting back and watching movies.