" /> UrlBlogGrey: April 2006 Archives

« March 2006 | Main | May 2006 »

April 26, 2006

TrustDecider for Verifying JAR Files

I've been working on an approach for verifying Java JAR files at runtime in Java 1.3+ environments. Unfortunately, I've noticed a serious lack of information with regards to what verification facilities are provided with Java and to what extent they do their job.

One of the most promising tools I've come across is the TrustDecider class. It is available to all Applets in JRE 1.3+ (plugin.jar), and to all Java Web Start applications in JRE 1.5+ (deploy.jar). In my case, I have a digitally-signed Java Applet that downloads digitally-signed content which must be verified programmatically at runtime. TrustDecider provides a method called isAllPermissionGranted that returns a boolean value indicating whether certificates associated with a CodeSource (JAR file) have AllPermissions privileges, which is to say that they are trusted.

In JRE 1.3, the TrustDecider class has the full-name sun.plugin.security.TrustDecider; however, in JRE 1.5, the full-name is com.sun.deploy.security.TrustDecider. Locating the appropriate implementation of the class can be accomplished with Java's Reflection capabilities.

To verify the integrity of an archive, you must enable verification when constructing the JAR instance, and then actually read each entry in the JAR to trigger verification of the entry's digital signature(s). The last part is not so obvious to people, since it seems like just constructing the JAR instance with verification enabled should be enough.

To verify the authenticity of each archive entry, you can invoke the isAllPermissionGranted method in TrustDecider. The user's Java keystore will be accessed by the TrustDecider class to determine if the certificate is already trusted. If not, the user will be presented with a dialog prompting them if they trust the certificate subject and signer. They will then have the option to approve the certificate for that invocation, or all future invocations. Problem solved!

As a word of warning, the TrustDecider class is part of the com.sun.* and sun.* packages and is not guaranteed to work in any version of Java. It should be used at your own risk.

Here's a method that verifies a JAR file using the TrustDecider class:

private boolean checkArchivePermissions(File file)
    {
        if (null == file || !file.exists() || !file.getName().endsWith(".jar"))
        {
            return false;
        }

        Class trustDeciderClass;
        try
        {
            trustDeciderClass = Class
                    .forName("com.sun.deploy.security.TrustDecider");
        }
        catch (ClassNotFoundException e)
        {
            System.out.println("Trying Plugin TrustDecider...");
            try
            {
                trustDeciderClass = Class
                        .forName("sun.plugin.security.TrustDecider");
            }
            catch (ClassNotFoundException ee)
            {
                System.err.println("TrustDecider not found, cannot verify archive");
                return false;
            }
        }

        Object trustDecider;
        Method verifyMethod;
        try
        {
            trustDecider = trustDeciderClass.newInstance();
            verifyMethod = trustDeciderClass.getMethod(
                    "isAllPermissionGranted", new Class[]
                    { CodeSource.class });
        }
        catch (Exception e)
        {
            e.printStackTrace();
            return false;
        }

        JarFile jarFile = null;

        try
        {
            // attempt to load a Java class from the JAR
            jarFile = new JarFile(file, true);
            Enumeration fileEntriesEnum = jarFile.entries();

            while (fileEntriesEnum.hasMoreElements())
            {
                JarEntry je = (JarEntry) fileEntriesEnum.nextElement();

                if (je.isDirectory())
                {
                    continue;
                }

                // Verify the integrity of the file against the digest
                InputStream is = null;
                try
                {
                    is = jarFile.getInputStream(je);
                    JarUtilities.getDataFromZipInputStream(is);
                }
                finally
                {
                    if (null != is)
                    {
                        is.close();
                    }
                }

                // Verify that the certificates used to assert the integrity are trusted
                if (!je.getName().startsWith("META-INF"))
                {
                    Certificate[] certs = je.getCertificates();
                    CodeSource cs = new CodeSource(file.toURI().toURL(), certs);
                    if (!Boolean.TRUE.equals(verifyMethod.invoke(trustDecider,
                            new Object[]
                            { cs })))
                    {
                        System.err.println("Not Trusted: " + jarFile.getName());
                        return false;
                    }
                }
            }
        }
        catch (Exception e)
        {
            e.printStackTrace();
        }
        finally
        {
            if (null != jarFile)
            {
                try
                {
                    jarFile.close();
                }
                catch (IOException e)
                {
                    e.printStackTrace();
                }
            }
        }

        return true;
    }

April 24, 2006

Reflections on the MAKER Faire

Last Sunday, my Dad & I went to the first MAKER Faire, which was held at the San Mateo Fairgrounds. The location was really convenient, as it was took just a short drive from Oakland over the San Mateo to get to the event. There was a really good turn-out, and a broad range of displays. Some were interesting, others I could have done without.

One of the highlights was seeing the cast of the television-show "Myth Busters". Adam, a.k.a. "The Orange Guy" (Natalie's doing), was present. He is actually an acquaintance of Natalie's sister, Jill, which I find very amusing. I'm a big fan of the show, and think it reflects the creativity and ingenuity in the San Francisco Bay Area. I don't think the show's cast did much except pose for photos and participate in Segway Polo. My Dad and I found the polo event a bit obnoxious, as there were two people participating in the game who compete in an actual Seqway Polo league. I called it "a sport for geeks of privilege."

Segway Polo

The display I enjoyed most was the Autonomous Light Air Vehicles (ALAVs). I had seen videos from the designer's website a couple months ago and was really excited by the concept and implementation. At the ALAV booth, the blimps were set free and allowed to roam about the hall. It was a very peaceful and intriguing presentation. I would love to create something similar to this project.

Blimp Creatures

April 21, 2006

Moleskin with Folders/Pockets

I found on Amazon the Moleskin featured in my last blog entry. It's only $10, so I think I'll grab one of these with my next order. One more thing for me to carry in my already-overloaded pants pockets!

Other Hipster PDA Interpretations

My fascination with personal organization strategies in the vein of Getting Things Done remains alive and well. I enjoy looking at other people's interpretations of the book's suggestions, and many of the currently-popular web tools do a great job of encouraging the sharing of these ideas. The most popular mediums are blogs, photo-sharing (i.e. Flickr), and wikis.

While browsing photos on Flickr, I found what might be the basis for my next Hipster PDA incarnation. It uses the Moleskin 3"x5" card wallet to hold index cards which form the backbone of the Hipster PDA. This addresses many of the concerns I have with my current system: loose cards, geeky undertone, and little support for sorting cards. Plus, the sticker r0x.

April 19, 2006

Outfit Misfit

I'm in the process of looking for a suit to wear in the wedding ceremony Natalie & I are having in Kauai this June. Finding clothing for me has long been a problem due to unusual dimensions (tall, skinny). Prior to meeting Natalie, I usually wore loose-fitting clothes that could be found anywhere; however, now I dress in better-fitting clothes which are naturally more difficult to find.

A couple of weeks ago, Natalie & I were in San Francisco looking for suits at several department stores in the Union Square area. The only suit we found that was to our liking was an $1800 Prada suit in a perfect shade of "taupe". Unfortunately, a suit at that price is out of reach for me at this time.

I just heard a radio performance by the band Belle and Sebastian on a KEXP prodcast. The male lead singer for the band said that he often gets compliments on his suit blazers, most of which he buys in Japan because they are designed for a smaller, more snug fit. Unfortunately, I think that if I were to fly to Japan in order to buy a suit for our wedding, the cost of travel might exceed the cost of the Prada suit I admired. Sigh.

April 18, 2006

Netgear WGPS606, Follow-Up

It has been a few weeks since I installed the Netgear WGPS606 wireless printserver on our home network. It has been working great, and I have no complaints to speak of. This is significant considering that we run a pretty diverse network - one Fedora Core 5 machine, two Macs, and a Windows XP system.

I recently installed the OpenWRT firmware on our Linksys WRT54GS wireless access point (AP). The Netgear WGPS606 connects to the AP in order to interact with the other systems on our network. The stock Linksys firmware doesn't make much of a distinction between WPA and WPA2 when accessed through the adminstration interface. However, the OpenWRT admin interface does make a clear distinction between the two, including the encryption algorithms they use. According to the WPA and WPA2 specifications, their primary differrence is that WPA2 uses the more cryptographically-robust (and computationally-expensive) AES algorithm used by the U.S. government, while WPA uses a relatively weak TKIP/RC4 algorithm that is much faster (hence it runs well on cheap hardware, like the WGPS606). I don't mean to knock RC4, as it is perfectly acceptable for my home network, though AES is the current standard for high-grade encryption. So, I'd rather use WPA2 if given the choice.

I tried using just WPA2 with AES on the AP but was unable to get the Netgear WGPS606 to join the network. Only when I enabled WPA with TKIP/RC4 did the WGPS606 join.

My conclusion is that the Netgear WGPS606 supports WPA with the TKIP/RC4 encryption algorithm, but does not support the newer and more robust WPA2 standard. Hopefully this can be remedied by a firmware upgrade for the WGPS606 in the near future.

Wake-On-Lamb (WOL)

Last Sunday, I installed the OpenWRT firmware on our Linksys WRT54GS Access Point. It's pretty sweet, especially since there is a large assortment of software available to run on this little consumer device. Because the Access Point is on 24x7, I figured it might be useful to have it turn on our other computers using the Wake-On-LAN (WOL) feature present in most Ethernet cards these days. The system I had in mind was the Linux box stuffed in the closet. I typically press the pow-pow button every morning, except for those mornings on which I forget and have to ask Natalie. Per usual, I decided to spent 4 hours automating a task that takes 5 seconds.

The Linux box includes the Asus P4C800 Deluxe motherboard, which has a built-in 10/100/1000 Ethernet adapter. Since the Ethernet adapter already works well in Linux, I figured it would just be a matter of configuring the card to generate a Power Event when it encountered the appropriate WOL Magic Packet (yes, that's the correct term). I issued the following command as 'root' to configure the Ethernet adapter:

    ethtool -s eth0 wol g

I was able to confirm my changes by again invoking 'ethtool':

    ethtool eth0

I then learned that WOL settings are only active for one boot-cycle. So, after configring the adapter using ethtool and powering-down, the computer should respond to WOL and boot but then need to be reconfigured using ethtool. This wasn't a huge hurdle since I could easily create a script in the /etc/init.d directory to automate the ethtool command during boot-up.

But WOL didn't work. It simply did not work. I googled the problem a bit and learned that the Ethernet NIC in my motherboard is not well-supported by the stock Linux driver. I even went so far as compiling a custom kernel with the vendor driver, but had no luck. It looked like WOL was a wash.

So, I went with the old-school solution of configuring the BIOS to generate a Power Event at a pre-determined time every day to start the system, and a CRON job in Linux to shut-down the system at the end of the day. Total time spent on that solution: 15 minutes. The joy experienced in fooling with NIC, kernels, and Linux: priceless.

April 10, 2006

Attacks on Public Internet Nodes

About a year ago, I installed OpenBSD on my spare PC and opened up a hole in our residential firewall to allow SSH traffic from the Internet to pass to the BSD system. My goal was to be able to securely access the BSD system from Internet-accessible systems, such as from work or on the road.

SSH (Secure Shell) is an Internet service suitable for controlling computers remotely through a text-based console. It can also be used to tunnel traffic for other services the the secure channel it establishes between the client and server machines. The SSH service I was running on the BSD system was now open for business, which meant that anyone, including attackers, could access the machine at any time and from anywhere.

I didn't expect to be the target of automated-attacks, but within a matter of hours a couple of machines located in Brazil began a brute-force dictionary attack on the SSH service. The attacks continued for as long as the service was left accessible through the firewall. I kept the BSD system running for a few more days, and then discontinued my experiment mostly due to a loss of interest. Still, the intensity of the attacks left an impression on me.

Recently I opened a hole in our residential firewall to allow external access to the SSH service running on a Linux box I own. However, this time I chose to expose the service on a different Internet port, one not typically used for SSH. A simple port-scan on the firewall would reveal the open port, but it wouldn't be obvious that the port was being used by an SSH service. Surprisingly, there haven't been any attacks launched against the machine since using the non-standard port. Running a service on a non-standard port does not improve the security of the service, but it dramatically reduces the obviousness of the service to people who have no business knowing. If someone else requires access to the SSH service, I can simply inform them of the port number on which it is running.

April 7, 2006

Obsolescence and Poor Design

I just finished reading an interesting write-up on an accidental Denial-of-Service (DoS) attack launched against network-time servers at the University of Wisconsin by consumer network equipment made by Netgear. More than 700,000 Netgear broadband routers made around 2003 had hard-coded entries for Network Time Protocol (NTP) servers to access for time updates. At the top of the list of servers to use was a system at UWisc. Even worse, if the Netgear routers were unable to contact the UWisc servers, they would repeatedly send requests every second. This created a flood of traffic against UWisc that paralyzed their public Internet infrastructure.

Netgear created patches for the offending routers which updated the NTP client implementation and the list of NTP servers to use. However, there are always going to be unpatched consumer systems in use that will continue to access the UWisc server. The patches must be applied by the consumer, which implies that the customer is knowledgable about product defects in the first place (certainly not the majority of consumers). The only thing that will ultimately solve the problem is product obsolescence. The offending Netgear routers were made in 2003 and featured 802.11b technology, which is becoming less prevalent due to the entry of much-faster 802.11g wireless technology. As consumers upgrade their home-networks to use 802.11g, they will likely discard their old equipment such as the Netgear routers responsible for this DoS attack. I actually owned one of the Netgear products involved in the attack (MR814) until I upgraded to 802.11g and gave the router to my parents for use as SPI firewall on their broadband connection.

It's all too easy for product designers to compromise long-term thinking when dealing with bleeding-edge technology. Yes, the product will ultimately be part of a "dumpster-upgrade", but the damage that consumer technologies are capable of when networked en-masse must be respected.

April 6, 2006

Rockin' Out with the Kids

Last night, Natalie and I saw the band "Taking Back Sunday" at the Fillmore in San Francisco. She and I have enjoyed the band's first two CDs that came out in 2003, 2004. We didn't realize that the band's popularity has spilled over into the mainstream - like, totally.

We were probably in the Top 25 Oldest People in Attendance. Out of a couple hundred. The sea of teenagers sporting acne, wine coolers, and curfews was really difficult to not notice. A highlight, or what might be considered the most awkward moment I've ever witnessed at a concert, was when some random guy came on-stage during one of the opening acts and proposed marriage to his girlfriend. It was supposed to be an aggro', neo-punk rock show; instead, it seemed more like a high-school dance or sporting event.

...Anyhow, it was a good wayto spend what would have otherwise been an average Wednesday evening. But one can't help but wonder "what's next?" when you find yourself feeling too old to be at a concert.

April 4, 2006

Online Collaboration and Wikis

I heard a segment on the KUOW show "The Works" about the role of web-based Wikis in the growing popularity of online collaboration. A Wiki is a great way for multiple parties to asynchronously contribute information and ideas to a shared, outward-facing medium. They differ from Blogs in that Blogs are usually maintained by an individual, while Wikis are cooperatively maintained by a group with the occasional involvement of editors.

I had experience with Wikis when working for a start-up company in 2004. The engineering team was geographically-distributed, so it was incredibly valuable to have a Wiki server as a global repository for information that could be accessed via the Web. It was most effective because we were dealing with "hard", factual data. There wasn't much need for an editorial role since the data posted to the site was hard to dispute.

Many Wikis aren't so factual; or, if they are fact-based, the facts can be interpreted in many ways (such as with the edit-wars that occur on Wikipedia). So, an editor might be needed in order to provide direction and stability to the collaborative work occurring on the Wiki.

Some people wonder if the popularity of Wikis and group-think is heralding the end of the autonomous, lone writer. I don't think so. Collaboration through a Wiki is appropriate when direction among a group is required. When a person's goal is to simply express their opinion with the non-essential goal of interesting or persuading others, writing a Blog or individual column is perfectly fine. I think that individual authors might serve as a catalyst for Wikis. You don't know the popularity of a topic until you begin to see a lot of individuals expressing interest in it. Once the topic is recognized as important, discussion can be facilitated using Wikis. Blogs and Wikis are hardly mutually-exlusive; instead, they go hand-in-hand.