November 2005

The rallying cry around OpenDocument prompted Microsoft to make its counter-move.  As fully expected, Microsoft is trying to create a standard based on Microsoft’s own (until now) proprietary XML formats.  Please tell me you saw this coming, right?

With companies from Novell to Corel standing in support of the OpenDocument format, a new coalition forming in support of the format, and governments agencies such as the State of Massachusetts requiring the use of file formats such as PDF and OpenDocument, clearly Microsoft was worried.  Otherwise, why try to create an alternate standard of your own creation?  Why not just join the existing standards?  Many are also saying that Microsoft’s decision to include PDF support in the next version of Office is another attempt to keep from being shut out.  After all, Office is a major cash cow for Microsoft, so the company will do whatever it can to provent a loss of marketshare (and revenue as a result).

This article discusses a newly-discovered zero-day exploit for Internet Explorer, including IE on fully-patched Windows XP SP2 systems.  (Apparently, only Windows Server 2003 with the Enhanced Security Configuration is immune.)

No patch has been released, and no security advisory had been posted at the time this was written.  A Microsoft security advisory was expected at any moment.

In the meantime, switch to Firefox.  No, really—I’m serious.

UPDATE:  Microsoft has posted a security advisory about this issue.

This new blog is just about ready for public consumption.  I just finished configuring the permalink structure so that all posts have a static URL, using a pretty common structure that includes the date of the post in the URL.  (This seems to be a reasonably well-accepted practice.)

With the static URLs for permalinks also come static URLs for category archives and feeds.  Unfortunately, it looks like I’ll have to go back and rework any internal links I created in my own posts.

In addition, I reworked the template to include a hyperlink for adding a post’s URL to your del.icio.us bookmarks.  Now you can add an entry to your bookmark list with ease!

The furor over the rootkit technology used by Sony in their DRM software continues to grow.  After Mark Russinovich unveiled the truth, Sony released a patch that supposedly allows for the DRM technology to be uninstalled.  Of course, Mark reviewed the uninstallation, and he found it left a little bit to be desired (putting it mildly).  Basically, it left you at risk of a blue screen of death.  And Mark’s not the only one not satisfied—this article cites several other security experts as well who are not happy with this situation.

Then, First 4 Internet (the company behind the cloaking technology that Sony uses for their DRM software) responds to Mark’s posts and attempts to refute his findings.  Finally, today, Mark posted more details on the actual uninstallation process and what is required in order to make it work.

Sony just keeps digging itself deeper and deeper into this hole.  It’s bad enough that the company uses stealth/cloaking technologies to hide their files.  It’s bad enough by itself that the DRM software is communicating back to Sony whenever a CD is played.  It’s bad enough that the uninstallation process requires so many steps and is so complicated.

Finally, to make matters worse…check out this news.

Put it all together, and you get a mistake so massive that it could change Sony’s business fortunes.  Don’t believe me?  Are you going to buy any Sony CDs or software now, after everything that’s been disclosed?  I’m not, that’s for sure.  (Of course, I don’t really have to worry about it that much since I’m using a Mac and not Windows, but that’s a different story for a different day.)

A pair of recent articles (this article at eWeek and this article at NewsForge) have me a bit perplexed.  What’s the real value of MapFS?  I know I have to be missing something here.  Somebody send me an e-mail and explain it to me, or give me an example (other than the Live CD example mentioned in one of the articles above) of how this could be used effectively.

To a certain extent, I agree with the belief that operating systems and applications that don’t have a significant market share like Windows, IIS, and Exchange won’t get targeted as frequently and therefore will have a “better” security track record.  I don’t agree that this is the only reason that Linux, Mac OS X, and others haven’t seen as many security vulnerabilities and the oh-so-fun network worms that invariably accompany them.  But I will agree that as these alternatives gain in popularity, more hackers are going to target them.

As a result, it’s no surprise that a new Linux worm has recently emerged.  I mean, it was bound to happen.  Linux is surging in popularity, as Linus Torvalds and other developers continue to add features to the Linux kernel and more and more corporations deploy Linux.  Of course the malware authors are going to try something like this.  I doesn’t surprise me in the least.  While this one is fairly low-tech, you can bet that future variants of this worm (as well as new worms) will be more complex and more dangerous.

I also fully expect that the anti-Linux crowd will shout that this is the end of the line for Linux, just like the anti-Microsoft crowd shouts “Down with Windows!” everytime Microsoft patches a critical security flaw that could be exploited by an automated worm (side note:  new Microsoft critical security flaw patched yesterday, go have a look and make sure you are protected).  This just isn’t the case.  Neither Windows nor Linux are going to go away, and each of them has value for businesses today.  The best bet for any organization is to use the product that best fits the need and then make sure that the product is:

• properly configured;
• properly patched; and
• properly maintained.

Following these guidelines, businesses and consumers can safely deploy the products, technologies, and platforms that best meet their needs without falling prey to technology bigotry.

Every now and then, I like to post out here a list of my current “tech projects.”  These are the things that I’m working on for my own network, things that I may or may not start recommending to or supporting for customers.

Here’s my current list:

• InterNetNews (INN):  I had an installation of INN up and running a short while back, but had to resort to an ugly hack with stunnel in order to make SSL work from a newsreader.  To get a clean build, I’ve decided I’ll just start from scratch with a clean installation.  I’ll be using CentOS 4.1 again as I work on transitioning all my Linux-based servers to a newer Linux distribution, and I’ll be compiling INN from source instead of using a package.
• OpenBSD-based antispam gateway:  I’ve got an antispam gateway running right now (uses Red Hat Linux, Postfix 2.1, SpamAssassin, Postgrey, Razor, DCC, and ClamAV), but I want to try building one using OpenBSD 3.8 (just recently released) and newer builds of Postfix, SpamAssassin, and Amavisd-New.  In particular, I’m interested in the advanced integration of newer versions of Postfix and Amavisd-New.
• XC Connect:  I’ve also mentioned XC Connect before as well, but a previous installation proved to be unstable, and the Apache integration was less than stellar.  In fact, the integration was nonexistent.  I’m going to try a clean build of CentOS 4.1 and XC Connect to see if that will correct the stability and integration problems.

I also need to wrap up the documentation for a few completed items, such as the Cisco VPN integration with Active Directory.  Mac OS X integration with Active Directory is also on the “to do” list, but it will have to wait a little while—I’ll need to find another Mac to “experiment” with instead of using my own PowerBook.

Well, sort of resolved.  I was never able to make the pcn driver (from OpenBSD 3.8) actually work under VMware, but I did find information on how to disable the pcn driver and revert to the older le driver.

This archived Neohapsis discussion, followed by a quick e-mail exchange with the author of the thread (who, thankfully, was very responsive and very helpful) led me to the solution.  Some of it I had to improvise on the fly, but here’s the overall process:

1. Boot from the OpenBSD 3.8 boot CD image (I pointed the virtual CD-ROM drive in the VM directly to the corresponding ISO image).
2. At the OpenBSD “boot>” prompt, type -c and press Enter.  This takes you into User Kernel Config, or UKC.
3. At the UKC prompt, type “disable pcn” to disable the pcn driver.
4. Type “quit” at the next UKC prompt to exit the kernel config and proceed with the boot process.  If you watch the boot process, you will see OpenBSD load the le driver and identify the virtual NIC as le1.

That’s all well and good, but how do you make the changes stick between reboots?  Here’s how.

1. Once you’ve gotten OpenBSD fully installed and are rebooting for the first time after installation, follow the steps above to use the le driver for the next reboot.
2. Use the “config -e -o nbsd bsd” command (see the relevant man page for details) to modify the kernel again, only this time saving the changes to the file named “nbsd”.
3. Upon the next reboot after using the config command to create a new kernel file, specify the name of that new kernel file (“nbsd” in our example here) at the OpenBSD “boot>” prompt.
4. Assuming that everything works OK (it did for me), rename the original kernel to “bsd.original” and rename your new kernel to just “bsd”.  Then, upon the next reboot, the pcn driver should be disabled and everything should work just fine.

Using this process, I now have two OpenBSD 3.8 VMs running and haven’t experienced any issues.  Now, on to installing ClamAV on OpenBSD….(more details soon)

UPDATE:  The pcn0 network driver from OpenBSD 3.9 works perfectly under VMware (at least, on ESX Server).  I have posted more information here.

A very in-depth article by Mark Russinovich unveiled that DRM technology shipping with recent Sony BMG CDs actually installs rootkit components onto your system.  Now, I don’t know about you, but I don’t like the idea of a vendor unknowingly installing software on my computer(s) that contain rootkit components—especially when those rootkit components could be used by malicious software packages to hide themselves.

I’m glad to see that eWeek picked up the story as well.  (Note that O’Reilly’s ONLamp.net is mentioning it as well.)  Mark’s research is fantastic (as always), but not many people will get exposed to this news through him alone.  Computer geeks like myself would, of course, but the people that really need to know this are the non-geeks.  Any reasonably computer-savvy user is likely to want to pick up your average CD (from any number of distribution channels, including Amazon.com) and copy the music off the CD.  There are a number of very valid reasons for this—ease of access, personal backup copy (ever scratch a CD?), etc.  Copy-protected CDs limit your ability to do this without also installing stealthy rootkit components onto your system.

More links to other discussions on this topic can be found in section 8 of this Wikipedia rootkit article (also linked above).

In my opinion, this is just plain wrong.  It’s wrong to install this kind of software onto someone’s system.  I can understand their desire to want to protect their “intellectual property,” but there’s got to be a better way than installing rootkits on your customers’ computers.

My attempts to deploy the latest version of OpenBSD, version 3.8 (released yesterday), have run into what I hope is only a small speed bump.

In previous versions of OpenBSD (I first started using OpenBSD only a couple of versions ago, with the release of OpenBSD 3.6), the AMD PCnet adapter that VMware presents to virtual machines was detected using the “le” driver.  So, the virtual network adapter in a VM running OpenBSD 3.6/3.7 (and earlier versions, presumably) would be le1.  With the release of OpenBSD 3.8, the driver has changed to pcn (making the virtual network adapter pcn0), and this doesn’t seem to work—at all.  Several attempts last night failed miserably.

Fortunately, there is hope on the horizon.  A Google search turned up an archived Neohapsis discussion that raises the possibility of disabling the pcn driver and using le instead.  I hope to try that in the next couple of days to see how it works, and I’ll post the results here.