blog.dt.org

Entropy in Cloud Computing Applications

Entropy, as it pertains to computer science and cryptography, is one of those topics that most of us (myself included) largely take for granted these days. In this context, entropy is a source of pseudorandomness that is typically collected by the operating system and made available to applications via a pseudorandom number generator (PNRG). We tend to implicitly trust that our applications have a source of entropy that is sufficiently random to ensure that the strength of our cryptographic techniques — SSL handshakes, SSH keys, and the wide variety of other cryptographic techniques used in modern public-facing applications that rely upon a pseudorandom number generator — is as strong, algorithmically speaking, as expected. But what happens when that source of entropy is not as strong as we think it is?

An excellent case study of what happens when a source of entropy is not as random as expected can be found in the weakness that was introduced into the Debian Linux package of the OpenSSL library in May of 2008 (see http://www.debian.org/security/2008/dsa-1571). A change was made to a single line of code in the open source OpenSSL package in order to clean up the output of purify and valgrind as part of the build and test sequence. This minor change had a side effect; it caused the pseudorandom number generator within the OpenSSL library to be predictable because it tightly constrained the number of possible seed values that could be used. Consequently, any cryptographic keys generated using this source of entropy could be guessed within a relatively short period of time using a brute force attack, constrained by the small set of possible seed values to the pseudorandom number generator. This issue was found and addressed quickly, but it illustrates an excellent point about entropy in software applications: a reduction in the quality of a source of entropy can be very difficult to detect if you are not specifically looking for it.

So what does any of this have to do with cloud computing? The current “best practice” for the collection of entropy by an operating system is to collect keyboard timings, mouse movements, network interrupts, disk drive head seeks, and other operating system events that are collectively random and can be processed to generate a stream of randomness to seed the pseudorandom number generator. This works reasonably well for a desktop or laptop that has a keyboard and a mouse and is being used interactively in an arbitrary fashion by a human. It also can be made to work for server hardware, although the rate of entropy generation is slower (and thus activities like key generation are slower) when a human with a keyboard and a mouse is not actively involved, since the technique relies more heavily on unattended events like network and disk use. And this is where a potential problem arises for entropy in cloud computing: a set of virtual machine instances running within a cloud-based virtualization service could potentially share a source of entropy from the underlying hardware. If the instances all share a single piece of underlying physical hardware, then they also all share the same set of network and disk events, and thus a clever attacker might be able to predict the stream of entropy that might be utilized by an application on one of those instances.

There are other techniques for entropy generation (e.g. hardware entropy generators, software techniques involving samples from a microphone or webcam, and entropy services available via the internet) that can be employed to attenuate or eliminate the potential threat of shared entropy sources in cloud computing environments, and as cloud computing environments continue to mature there will undoubtedly be advances in this area to address this issue. In the interim, however, we should all take a closer look at the use of entropy within our cloud-based applications to ensure that we haven’t introduced a “side effect” that will have serious security implications.

Tags: entropy

How to Jailbreak iPhone 3.01

Apple just released the iPhone 3.01 firmware update, and that means it is time to update my jailbroken iPhone to 3.01 and then jailbreak it again. In the past, I have been a happy user of PwnageTool for the jailbreak, and I would be again except that PwnageTool hasn’t been updated yet for the 3.01 firmware. Doh! I could just wait for the PwnageTool update, but the firmware update is to address a SMS crack that can give someone root on your phone. So I guess I better find a way to do this without PwnageTool.

After the requisite sync and aptbackup, I decided I would first try a quick hack and see how smart PwnageTool is. I put PwnageTool in expert mode and browsed to the 3.01 firmware IPSW to see if I could trick PwnageTool into building a custom IPSW from the 3.01 IPSW. No such luck — PwnageTool checks the firmware and simply won’t do it if it isn’t a supported IPSW version (and 3.01 is not supported in the current version of PwnageTool). So I guess I really do need to use something other than PwnageTool for the jailbreak.

Luckily, I found a post on the dev-team blog that says you can use redsn0w 0.8 to jailbreak the 3.01 firmware provided that you use the 3.0 IPSW as a base. Apparently the changes in 3.01 are very minimal and the redsn0w jailbreak procedure only changes a few things within the existing firmware, rather than completely overwriting it as PwnageTool seems to do. I couldn’t find any good postings with a complete set of instructions on how to do this with redsn0w, but here is what ultimately worked for me:

1. Connect your phone to iTunes and do a sync. Always good to start with this.
2. Run aptbackup and select “Backup” so we can restore Cydia after the upgrade and jailbreak.
3. In iTunes, restore your iPhone. This will also upgrade the firmware to the official 3.01 from Apple.
4. Run redsn0w 0.8, and select the 3.0 IPSW (iPhone1,2_3.0_7A341_Restore.ipsw) firmware from ~/Library/iTunes/iPhone Software Updates
5. Follow the instructions to put the phone in DFU mode. Note these are different than how PwnageTool does it, and you need to start with your phone off and connected to iTunes.
6. Once you are in DFU mode, kickoff the jailbreak.
7. At some point during the jailbreak, redsn0w told me it was waiting for a reboot. I waited quite a while, and it seemed to be hung. As a last resort, I decided to unplug the iPhone and start over. I unplugged the iPhone and plugged it back in, and…viola! The phone jumped into the redsn0w firmware loader screen and the jailbreak proceeded to completion. I don’t know if I was supposed to do this or not (like I said, I don’t normally use redsn0w)…but it worked.
8. After a little while my phone came back to life and rebooted and the jailbreak appeared to have succeeded, with Cydia installed.
9. Run aptbackup and select “Restore”. As part of the process, Cydia asked to upgrade a bunch of essential packages.
10. One more reboot to check everything and…all done. The firmware revision is now 3.01 according to iTunes, and I have all of my jailbroken applications restored and in place.

That’s it. I hope this helps. And I hope to see PwnageTool updated in the near future, since it has several features (like custom boot images) that I would like to use with my iPhone.

Tags: iphone

How to Detect the Front (Home) Page of a Wordpress Blog

I recently wanted to add a Wordpress widget that would be conditionally visible in the sidebar of the front (home) blog page only. A reasonable search on this topic turns up a large collection of information and discussion — most of which turns out not to work. The following is a brief overview I what I tried and what I ultimately did.

Most of the information on this topic points to either the is_home() or is_front_page() Wordpress PHP functions. In theory, you can use either of these functions in a conditional expression and detect if you are in the front (home) page. In practice, however, it is a little more complicated. These functions are not based on the URI of the page that is being loading; instead they are based on several global boolean variables that are set based on what queries have occurred in a page. I imagine there is probably a good reason for this in Wordpress-land (and I am not a Wordpress expert), but it seems to me that if I call is_front_page() within the front page of a Wordpress blog then it should reliably return true, and conversely if I call is_front_page() from any other page in the blog then it should reliably return false. In my case, I was trying to create a conditionally visible widget in the sidebar by modifying wp-include/widgets.php to contain a conditional expression within wp_widgets_init(). What I found was that is_front_page() always returned true when called from within widgets.php for any page on my blog. I traced this to the fact that the values of the global variables upon which is_front_page() is based are changed by some of the standard activities performed within wp_widgets_init() — specifically any query to get posts or categories to populate standard widgets that show archives and categories. The is_home() function seems to suffer from the same issue, as it appears to be based on the same global variables. Several posts described interesting ways to combine is_front_page() or is_home() with other functions to get the correct conditional behavior, but none of these worked in my case, and all of them seemed to be specific to their context, rather than general purpose solutions to the problem.

After banging my head against this for a while, I decided to try a different approach. The is_front_page() and is_home() functions are based on global variables rather than the URI of the blog page. So forget those functions…and find an expression that checks the URI directly. It seems simple enough, and it is:

if ( $_SERVER["REQUEST_URI"] == '/' )
{
/* do something */
}

And that’s it. This block of code works reliably throughout the pages of my blog. I am willing to bet that there might be some peculiar Wordpress configurations (e.g. using a custom page as the front page, etc.) for which this does not work, but like I said, I am not a Wordpress expert, so your mileage may vary.

Hope this helps.

Tags: wordpress