The old saying goes “You learn something new every day.” Yesterday, Ed Bott and others helped me to learn about the Microsoft Enhanced Mitigation Experience Toolkit (aka EMET). This free download enables users or IT departments to add extra layers of protection to software that otherwise might remain vulnerable to attack. Not coincidentally what with a slew of zero-day exploits in the recent news, Internet Explorer is amenable to extra protection from EMET that might be well worth adding to whatever mix of anti-malware and security software you already have in place on your Windows machines.
The download is a mere 6.0 MB in size, and both quick and easy to download and install. It also works with Group Policy settings and is thus Active Directory friendly as well. It’s absolutely true some of the program’s security settings are available in other forms, but these generally require access to (and recompiling) source code to be put to work, whereas EMET can protect applications with no need for source code access and recompilation. As the MS Download page says “This is especially handy for deploying mitigations on software that was written before the mitigations were available and when source code is not available.” To that latter end, recompiling IE isn’t an option for most of its users, so EMET’s protection comes doubly welcome.
The program’s Application Configuration screen lists the mitigations that EMET can wrap around already-installed programs on Windows PCs:
Here’s a little more information on the seven mitigations, in the same order in which they appear in the preceding screen capture:
- DEP (Data Execution Prevention): a method for invoking modern processor-level protections that block segments of information labeled as data from being executed as a series of processor instructions. Enabling DEP helps stymie dangerous and frequent attacks based on buffer overflow and other techniques that seek to trick computers into executing instructions included in Web page or program input.
- SEHOP (Structured Exception Handler Overwrite Protection): Introduced with Windows Vista, and present in all more modern forms of Windows, this setting blocks exploits that seek to overwrite exception handling routines with their own (rogue) code, especially in older programs that may not have been able to use a /SAFESEH compile setting when compiled. See this Uninformed.org discussion for more details.
- NullPage: Allocates the first page of memory — a predictable and obvious target for malware attacks — before a program is initialized, then blocks attackers from seeking to exploit NULL references in user mode. This prevents attackers from exploiting known and obvious code entry points, or using empty/null values or entries to open applications to various forms of attack.
- HeapSpray: Frequent use of address randomization techniques makes it hard for attackers to predict (or insert) their own code at known addresses within the runtime environment for vulnerable applications. The heap is a working area of memory available to running programs that attackers “seed” with injected code at a wide variety of known addresses — hence the term “heapspray” — that they can attempt to access, one location at a time, if they gain a toehold within an application. This technique prevents such injections by pre-allocating memory addresses to block them from illicit use.
- EAF (Export-Address-Table Access Filtering): This is a table of addresses that program modules use to call various Windows application programming interfaces or APIs. For a module to call an API, it must know the address at which the API has been loaded. To this end, such code works through the export table for all loaded modules, seeking out elements that reference useful or interesting functions (often this involves the kernel32.dll or ntdll.dll modules). This technique filters access to the Export Address Table (EAT), and permits or denies read/write access based on the calling code. If EMET is in use, illicit code will be blocked when it seeks to look up or use APIs it needs to execute its payloads.
- MandatoryASLR (ASLR = Address Space Layout Randomization): In general, ASLR randomizes the addresses where modules are loaded to prevent attackers from using data stored at predictable locations. Normally, using ASLR requires a program to use compile-time flags, but EMET forces modules to load at randomized locations, regardless of compilation flags used. This foils all kinds of attacks based on known address, or address prediction techniques.
- BottomUpASLR (ASLR = Address Space Layout Randomization) Randomized base addresses for bottom-up memory allocations — such as for heaps, stacks, and other commonly used memory structures in programs — so that attackers cannot predict or manipulate these structures for their own purposes.
EMET works with Windows XP at SP3 and higher, Vista SP 1 and higher, and all versions of Windows 7 and 8. It also works with Windows Server 2003 SP1 and higher, Windows Server 2008 (and R2) at all service packs, and Windows Server 2012 (which doesn’t have any Service Packs at this writing, the product only having attained GA status earlier this month on 9/4/2012).
Again, EMET is quick and easy to download and install. The companion User’s Guide explains how to use it through a GUI interface, via Group Policy, or at the command line. Interested readers will also find Ryan Naraine’s and Ed Bott’s coverage of this tool quite useful as well. And don’t forget: it’s free!
Last week, after upgrading my 119 GB (actual) SATA II OCZ Vertex-2 SSD to a 167 GB (actual) SATA III Intel 520 SSD, I quickly realized that the SATA III Marvell 9128 controller on my Asus P6X58D-E motherboard wasn’t completely compatible with the SATA III implemented in the Intel drive (see my previous blogs “Interesting Wrinkles” and “Giant PITA” on this subject for more background and details). Before I switched the controller connection from the Marvell 9128 controller on my PC to an open ICH10R port, I ran CrystalDiskMark to record the following results:
But with this controller in use, I couldn’t get the Intel SSD Toolbox to work properly and comprehensively. It wouldn’t permit me to use the optimization tool (to my way of thinking, the best and primary reason to use Intel’s Toolbox in the first place), nor could I ever use it in the future should the drive’s firmware need an update, either. After switching the motherboard end of the drive’s SATA cable to an ICH10R port, all of these problems were resolved, as shown in the following series of screen captures from the Intel SSD Toolbox:
Furthermore, the Intel SSD Optimizer is now available to be used (and scheduled) as the software’s developers intended:
Even the SMART drive details are now completely populated and accessible:
But there’s a cost to the increase in compatibility, though it’s not as severe as I had feared. A re-run of CrystalDiskMark shows that there is a perofrmance price to pay for my ability to make full use of the Intel SSD Toolbox:
Interestingly, sequential read and write speeds actually improve slightly (from 260.1 to 271.7 MB/sec for write, and from 212.5 to 221.2 MB/sec for read) while 512 K block reads decline substantially (from 330.4 to 253.7 MB/sec) though writes also improve slightly (from 211.0 to 219.1 MB/sec). At 4K there’s a slight improvement, but with a queue depth of 32, both reads decline (from 215.3 to 177.0 for reads) and writes improve slightly (from 175.5 to 184.8). I am pretty much inclined to treat this as a wash, although the Windows experience rating for the drive declined from 7.9 (Marvell 9128) to 7.8 (ICH10R).
What’s the moral for this story? Steer clear of older Marvell SATA III controllers if you want to use Intel SSDs and the Intel SSD toolbox. I guess I could upgrade my motherboard to a newer model that includes Intel SATA III controllers, but I’m not sure that the performance boost is worth the time, expense, and trouble involved in a complete teardown and rebuild of my production desktop. Sigh.
Last week I wrote a blog post entitled “One small change to my PC, one giant PITA to implement,” wherein I recounted the issues and frustrations involved in what I thought would be a quick and simple SSD swap-out on my production desktop. Thanks to a recent memory upgrade from 4 to 24 GB that followed as a consequence of finally upgrading from 32-bit Windows 7 Professional to the 64-bit version instead, I had to kiss off 24 GB for my paging file and another 18 GB for the hibernation file. Alas, that left the original 128 GB OCZ Vertex 2 SSD a little short of workspace. With actual disk space available of 119 GB as reported in Windows Explorer, the remaining 77 GB didn’t leave me enough room to accommodate the OS, plus files and applications, with 30 GB of free space left over to keep 25% of the disk free for the OS to “do its stuff” at runtime.
So, I switched over to a brand-new 180 GB Intel 520 Series SSD, in part to switch from the older 3 Gbps SATA II interface on the OCZ Vertex 2 to the new 6 Gbps SATA III interface on this drive. And thereby hangs today’s tale, because the only SATA III ports on my Asus P6X58D-E motherboard come from a two-port Marvell 9128 SATA controller. The other ports on this motherboard emanate from an Intel South Bridge 82801JR chipset, aka ICH10R, but they support SATA II, not SATA III. Here’s some of what the Intel SSD Toolbox has to say about my current set-up right now:
To get this far with the Intel SSD Toolbox, I had to do some serious digging around on the Internet, which took me to an excellent (and free) French device driver Website called station-drivers.com, where their Marvell page turned up a 9128 driver dated July 9, 2012. Before I downloaded and installed this driver package — which also installed an Apache server on my PC that I later removed — the SSD toolbox couldn’t recognize the make or model of my Intel SSD at all. But as the preceding screen capture clearly shows, it can now recognize the drive and its firmware version. But alas, here’s what happens when I try to use the Intel SSD optimizer, which normally runs weekly to clean up and optimize its SSDs:
Further research on the Web shows that the issues with the 9128 and the Intel SSD toolbox are well-known and -documented. Newer drivers might someday offer more relief, but for now it looks like I’ll have to switch back to the ICH10R SATA ports to get the SSD Toolbox to work to fullest effect. And from what I read on the various Intel and Marvell (and PC enthusiast) forums, it may ironically turn out to be the case that I’ll get better performance from the ICH10R SATA II ports on that motherboard than I’m currently getting from its Marvell 9128 SATA III ports. One thing’s for sure, the CrystalDiskMark numbers from the current set up come nowhere close to Intel’s claimed 550 MB/sec for read, and 500 MB/sec for write for this particular SSD. I’m getting just a little more than half that, as these CrystalDiskMark benchmark results illustrate.
This weekend, I’ll unplug the box, pop open the case, and switch the motherboard end of the SSD’s SATA cable from a Marvell port to an open ICH10R port (I still have 3 left). If I observe anything startling or especially interesting, I’ll post again next week to report on what I learned. But man, was I disappointed to realize that just because my motherboard has SATA III ports doesn’t mean that they’re actually GOOD for the uses to which I’d like to put them. Who knew that not all SATA III ports are created alike, or that not all of them work equally well with various SSDs? I kind of thought that the whole point of a standard bus was not to have to worry about who’s building the parts on either end of a connection. Oh, well: Live and learn!
Last week, as is my usual wont, I fired up Secunia PSI (Personal Software Inspector) for all of my machines. In a discovery that caused no excitement whatsoever when I first ran the utility, I got a display that looked like this:
“Oh well,” I thought to myself, “time to update Flash.” This occurs pretty frequently, so I figured I’d download a new ActiveX component, install it, and be done with the situation in a minute or two. Man, was I wrong — and man, did the root cause for my error cause quite a flap. It turns out that Flash is now integrated into Internet Explorer 10 (the version that ships with Windows 8) and thus updates to Flash can come only from Windows Update.
When I tried to install and update and failed, I jumped up to the PSI discussion forums and realized that not only was it not possible to install an update, it’s also impossible to uninstall Flash in Windows 8 as a quick-n-dirty method for preventing inadvertent security exposures an unpatched version can occasion. Right now, the only method of self-protection is to dig into IE 10, and disable Flash altogether. Later on, Microsoft fanned the flames of ire and outrage by announcing that although it was aware that Flash needed updating it didn’t plan to push any more updates for Windows 8 until the October 26 General Availability (GA) date hits.
Yesterday, probably in response to countless rants, raves, and appeals for clemency or consideration, Microsoft changed its plans. As reported in PC Magazine yesterday, Microsoft’s Directory of Trustworthy Computing, Yunsun Wee, indicated that “In light of Adobe’s recently released security updates for its Flash Player, Microsoft is working closely with Adobe to release an update for Adobe Flash in IE10 to protect our mutual customers.” This will apparently be the first time Microsoft releases a patch for an RTM version of a new OS, instead of waiting for the GA date to push a first round of updates and patches. And it’s supposed to be available “shortly,” whatever that means (I’m guessing that means “as soon as we can push a solid, vetted patched version out the door”).
All I can say is “Good for Microsoft, but better still for those already using Windows 8, especially in production!” I know of numerous hardy and adventurous souls who are doing that very thing, but I am NOT one of them…
I’m not one to believe that my blog has any kind of market clout or impact, but I found myself scratching my head to explain why I got a comment on my “For Win8 Classic Shell Beats Start8, Hands-Down!” from one of the developers to point out to me that Start8 now also offers access to start menu features and functions the day after that posting. And indeed, it sure does. In fact, having now re-installed the new and improved version on my other Windows 8 full-time machine — my i7-2600K desktop machine — I find its behavior, customizability, and fidelity to the old Windows 2000, XP, and Vista/7 Start menus either as good or better than Classic Shell. Could my feedback have had anything to do with this change? Probably not, because there’s no way the developers could have written all the code necessary to make the substantial changes and additions to Start8 in one day. So, it has to be a colossal coincidence, but a tantalizing and amusing one, to be sure.
Here’s what I see — and like very much — when I use Start 8 now, as told in a series of screen caps:
The right-hand column menu entries work more like Windows 7 in Start 8, in fact, than they do in Classic Shell. The size and behavior of the Start menu area is nicely customizable, including a nice choice of Start button icons.
And if you don’t like the default icons that the developers supply, you can simply add your own to this folder to get the program to whichever way with icons you might like it to have. In the shot of the Task Bar that follows, I switched over to the Windows 8 logo sequence, as more consonant with a Windows 8 desktop.
For more information, including a complete features list and an animated demo of the new capabilities, or to download Start 8, head to http://www.stardock.com/products/start8/.
One of the interesting and easily overlooked consequences to using SSDs on PCs at a time when RAM is also incredibly cheap is that you have to take the Windows pagefile into account (and a hibernation file, if you use that feature on your systems) when sizing such drives. Though SSDs are getting cheaper all the same — Tiger Direct had a one-day special for a 128 GB OCZ Vertex-3 at $60.00 earlier this week, for example — you want a system/boot drive with at least 25% free space (and twice that is better) to give your OS room to breathe (and your SSD to move things around as it sometimes must when writing data). All this is by way of explaining the “one small change” to my production desktop PC, which I upgraded from 32- to 64-bit Windows Professional earlier this summer, when I also bumped the memory from 4 to 24 GB. Once I’d made all those changes, I quickly realized that the original drive wasn’t big enough to accommodate everything I needed it to because my pagefile jumped in size from 4 to 24 GB, and my hibernation file from 3 GB to 18 GB (a net gain of 35 GB). In short, I needed more space!
The previous drive was a 2-year-old OCZ Vertex 2 nominal 128 GB (119 GB reported in Explorer) which I replaced with an Intel 520 SSD nominal 180 GB (167 GB reported in Explorer). This took me from a situation where I had 20-25% free space on the drive most of the time, to a situation where I am looking at the properties window that shows almost 56% free space right now.
But getting from the old drive to the new drive proved to be more challenging than I had originally thought. It started well, as I put my $20 software program to work: Paragon’s excellent “Migrate OS to SSD” tool worked like a charm (and is a great buy, because as long as you uninstall it from one machine, you can then legally use it on another, and this is a program that doesn’t need to take up permanent residence on most PCs). Where things got dicey was when I opened the PC case (a very nice but now somewhat crowded Antec 902 tower case) and realized that I was going to have to remove both drive cages to make the swap work. This meant unhooking the Molex connectors for each cage’s fan, disconnecting all three SATA drives inside the case, removing the 2.5-3.5″ drive tray for the SSD to replace the OCZ with the Intel unit, and then putting everything back together again. Plus, there was a bunch of miscellaneous dust removal needed throughout the whole ordeal.
I’ve got two monitors hooked up to my case with DVI connectors, an audio cable, an RJ-45 for GbE, four USB cables (keyboard, mouse, and two USB hubs, plus two eSATA connectors for my primary data and backup drives (they’re easier to relocate to other machines that way when needs must). It took me about 10 minutes to get everything disassembled at which point I confronted the rat’s nest of cables in the area between where the PSU cables emerge, the on-board SATA II and III ports, and the power and SATA connectors on the backs of my SSD and the two internal drives in my case). Yesterday’s temps got up to 104° F and my office is on the end of the air conditioning chain from the condenser and main air moving unit upstairs in my house, so it was probably 85° F in my office in the late afternoon when I tackled this mess. I got everything taken apart, with the old drive old and the new drive into the drive cage, when I realized I was growing dangerously crabby about the work I had to do. Fortunately, family responsibilities intervened (but not before I found myself apologizing for barking at my wife, Dina, for grousing at her for no good reason at all) and we all went out for dinner to a nearby Chinese restaurant instead. Once there, a powerful combination of Japanese beer, wonton soup, triple delight, sauteed green beans, and fried rice soon restored my sense of humor and equanimity.
I returned to my office at about 7:30 this morning, and started the process of reassembly. I had to re-route the SATA cable from its former built-in ASUS SATA II (3 Gbps) port to one of two other Marvell 9128 SATA III (6 Gbps) ports on the motherboard, so as to take advantage of the Intel 520 SSD’s support for SATA III. I also had to blow the accumulated dust out of the case — it’s amazing how much can pile up, even though I cleaned the unit thoroughly in June when I did the 32- to 64-bit upgrade and added in the new RAM — which necessitated numerous trips outside with case or components and a can of compressed air in hand. By 8:30 AM, I had everything back together and started fiddling with the BIOS to get the system working again.
It took me four reboots to get everything working along with some consultation of the motherboard manual and some good, old-fashioned trial-and-error. I first had to re-establish the boot order for the PC, so the Intel 520 would act as the boot drive for the system. Then, I learned that the Marvell controller has a separate setting for AHCI access (it’s in the Integrated Devices panel, rather than consequent to the same setting on the Initial Setup panel). I actually had to reset the BIOS one extra time, because the first boot recognized the Intel as an IDE drive rather than an AHCI drive, and this caused the settings for the other SATA drives to be reset to IDE as well. By the third boot I had everybody on AHCI and things working properly, so I rebooted a fourth time to boost the CPU clock from its 2.8 GHz default to a modest 10 percent overclock of 3.15 GHz with a similar boost to memory clock rates as well.
So finally, everything’s working again, the system is running (and booting and shutting down) noticeably faster, and another adventure in PC upgrade and twiddling has come to a happy and fortunate close. I’d wondered if I was going to need to head to Fry’s to pick up some SATA III/6 Gbps drive-to-SATA-port cables, but so far everything seems to be working OK. I’ll do some benchmarking over the weekend with ATTO, HD Tune, and CrystalDiskMark and see if I’m in the ballpark I should be for that oh-so-speedy drive. I’m also trying to figure out why the Intel SSD Toolbox won’t recognize the 520 drive like an earlier incarnation did so well with my X-25M drive: although CrystalDisk and the BIOS say SMART is turned on for the drive, the toolbox says otherwise, and won’t provide drive details or allow me to check to see if my firmware needs an upgrade. Drat! It’s always something… In this case, I’m guessing it’s some issue with the Marvell 9128 SATA III/RAID controller that I switched over to so as to take advantage of the higher data transfer speeds it makes available.
I’ll admit it: I love to tinker with computers and to keep their device drivers up-to-date. This requires the occasional bit of creativity in figuring out how to bring the latest drivers together with the devices they support, especially when you find a driver from Vendor X for a device included in a computer build by Vendor Y, and need to extract .inf, .cat, and .dll files from an executable program designed only to run on a machine identifiable as coming from Vendor X for Vendor Y’s version of that same device. I will happily spend hours noodling my way through this kind of thing, trying out Intel drivers initially made available only for Intel motherboards on my systems that include MSI, Asus, or GigaByte motherboards instead, or extracting drivers from packages put together for Dell, Toshiba, or Fujitsu notebook PCs on my HP or Lenovo boxes.
Recently, I found myself updating a Windows 7 Ultimate 32-bit VM that I created just before I finally upgraded my production system from 32- to 64-bit Windows 7 in June. Out of curiosity I began to play with the drivers for the VM to learn what, if anything, I could do to make sure they were up to date. What I learned was that it does little good to seek out device drivers for specific bits of hardware in the underlying physical host when dealing with a VM. By design, there’s a layer of insulation between the VM and the underlying host system that makes any mappings that a driver update tool such as DriverAgent might find more or less irrelevant.
But what I did observe in systematically checking the various entries in Device Manager for that VM was that clicking “Update Driver” for devices in the interface — especially those that register as Unknown Devices, or that have the yellow exclamation point marker to indicate driver issues — will occasionally produce good results, in the form of a driver update or even conversion from Unknown Device to a workable driver of some kind. Using DriverAgent, I was able to see that some device drivers registered as out of date on its radar, and then to use that information to dive into Device Manager to use the “Update Driver” and “Search Automatically…” buttons to provoke some meaningful action. This helped me convert an Unknown Device entry to a working Human Interface Device (HID) entry, and enabled me to update drivers for ACPI and some USB devices as well.
One item remains stubbornly resistant to update or repair, however, and all my searching does not produce any fixes. While PC Integration features to access local hard disks on the host machine, and to use USB devices plugged into that machine work just fine, the Virtual PC Host Bus Driver comes up with a Code 31 error “This device is not working properly because Windows cannot load the drivers required for this device.” Even so, the Automatic Update facility reports “Windows has determined the driver software for your device is up to date.” That’s got me kinda stumped as to how to proceed from here, because I can’t find any fixes to solve this apparent disconnect despite all of my diligent Web searches and spelunking around on TechNet and in the Windows Seven Forums.
Nevertheless, it’s all very interesting and I’m learning more about the architecture and operations of VMs than I ever had a need to before. There’s nothing that makes me happier than figuring out why things aren’t working, and learning not just how to fix what’s (apparently) broke, but also where workarounds make sense, and where leaving well enough alone is the best strategy of all!
Ars Technica reported that the hurry-up fix delivered on 8/30 for Java to address a slew of vulnerabilities reported by Polish infosec firm Security Explorations– namely, Java version 7 update 7 — itself remains vulnerable to possible e-mail or Web-based attacks. As with the previous round of vulnerabilities, the latest discovery also confers complete control over PCs should a successful exploit be launched against this vulnerability. Needless to say, Security Explorations is NOT sharing the exploit details with the general public, for fear that malefactors could turn this vulnerability into a successful exploit in the meantime.
When I reported the initial circumstances that led to Oracle’s hurry-up release of Java version 7 update 7 in my blog entitled “Possible Java Exploits Can Expose PCs to Attack,” I got an e-mail from a very close but not terribly tech-savvy friend who informed me that it’s all well and good to tell readers to disable or uninstall Java, but it’s even better to provide some step-by-step instructions on how to do these things. I did advise readers only to enable Java on trustworthy sites, so I will explain here how to do the following:
(a) how to assess site trustworthiness
(b) how to disable (and re-enable) Java in IE, Chrome, Firefox, and Opera
How to Assess a Site’s Trustworthiness
This is actually pretty easy. You need only use a Web reputation site of some kind to check out any unfamiliar URLs before you go to visit any associated Web pages. For example, here’s McAfee’s rating of the site “Java.com” whence all Java updates come:
You can jump to any of these links to check Web reputation for sites you don’t already know and trust: TrustedSource (McAfee), Web of Trust (WOT), the Trend Micro Site Safety Center, BrightCloud Webroot Reputation Index (Webroot), and the Norton Safe Web (Symantec), among many others. Such checks are highly recommended if you’re jumping anywhere off the well-trodden Internet path to big-name company and information outlet sites.
The only sure-fire way to completely disable Java is to uninstall it. One way to do that is to click Control Panel, Programs and Features, then right-click Java 7 Update 7 (or whatever version you might be running) and select “Uninstall” from the resulting pop-up menu. If you don’t have Java on your PC, it can’t be used against you, either.
But alas, some sites require Java to work properly (including some of my favorites, such as DriverAgent.com) so it may be necessary to turn Java on and off depending on where you plan to take your browser at any given moment. Here are abbreviated instructions for various browsers with links to more detailed (and illustrated) tutorials for those who might need them:
1. Internet Explorer: Click Tools (you may have to turn on the Menu Bar to make this selection visible), Manage Add-ons. then select the Java Plug-in, and click the Disable button. Click Close and OK to accept this change. Reverse the process (Enable) to turn Java back on. Tutorial.
2. Chrome: Type chrome://plugins into the URL address box, then click the Disable link in the Java entry area. Tutorial.
3. Firefox: Click Tools, Add-ons, Plug-ins, then click the disable button to as many Java-related entries as appear (in my browser this was Java Deployment Toolkit and Java Platform; YMMV). Tutorial.
4. Opera: Type opera:plugins into the URL address box, then disable any and all Java plug-ins you may find there (as with Firefox, you’ll often find both the Java Deployment Toolkit and the Java Platform; disable both). Tutorial.
Hopefully, this will help people not only hear the word about Java and spread it further, but also to act on the best methods to turn it off or disable it as circumstances may dictate, or allow.
Earlier this week, I blogged about how Samsung is restoring a Start menu capability to its Windows 8 PCs. I also mentioned (and implicitly recommended) the Start8 startup replacement that returns the traditional Start button to the Win8 desktop and gives users the option to boot straight into the desktop if they so choose. Now that I’ve worked with Start8 for a while, I’ve decided I don’t like it very much. A quick set of visuals will explain why:
Good: Return of the Start Button
And there it is, back again: the old familiar start button as seen in earlier Windows versions. But when you click that button, here’s what you’ll see:
Bad: Back to the Windows 8 (Metro) Start Screen
When I click a Start button, I want to see the old familiar Start menu, not the Windows 8 Start screen which, despite its many visual charms, provides no easy and reliable way for me to launch programs (or Windows utilities) whose names don’t pop up readily when using obvious Search items.
Introducing Classic Shell
As I was reading the hilarious recitations of the encounter between Obi-Vaughn (Steven J Vaughn-Nichols) and Darth Perlow (Jason Perlow), both of whom debated Windows 8 versus Linux on desktops recently, I came across a reference to a SourceForge project named Classic Shell that Perlow off-handedly recommends. Here’s what it looks like from an icon perspective on the desktop:
Indisputably, the Start Icon looks different from its traditional namesake, what with a clamshell-shaped outline instead of simple circle. But what I like about this tool is that it lets you choose a traditional (pre-Windows XP), an XP, or a Vista-7 Start menu look and feel, and then proceeds to deliver what it promises. I chose the Windows Vista-7 variation and am very happy with what resulted, not just in terms or look and feel but also in terms of behavior. I’ll illustrate by showing its Program menu capabilities:
It’s not just what I can use to navigate through the hierarchy of installed items and programs that makes me recommend this program. It’s also the return of the Search box, and more-or-less expected access to typical Start menu items from previous Windows versions.
I’m neither afraid to access nor ignorant of the ways and wiles of Windows 8 “native navigation.” I’ve read rants from others like Peter Bright of Ars Technica, who assert that Start menu replacements are crutches and will retard learning and getting comfortable with Windows 8, and agree to a certain extent that users shouldn’t simply ignore the new-fangled features of Windows 8 altogether. But when I’m working on the desktop — which I do 90+ percent of the time — I don’t want to keep having to jump into the tiled modern/Metro interface just to launch new programs or move from one program to another. That’s what makes Classic Shell valuable to me, and will help me be more productive with Windows 8. If you try it, you may feel the same way, too.
Quick: visit http://www.isjavaexploitable.com/ on any PC close at hand. There are a number of Java exploits rampant in the wild at the moment, so you’ll want to see a resulting screen that looks like this if you do have Java installed:
On the other hand, if you don’t have Java installed, you’ll see something like this:
But if your installed version of Java is vulnerable to the latest zero-day exploits, you’ll see the following warning instead:
What to do if one or more machines shows up as vulnerable? Turn off Java is the safest and simplest response. Instructions for all major browsers are posted on the KrebsOnSecurity site associated with metasploit. This is a bona-fide zero day exploit folks, and may require immediate action!
Note: After a heckuva hullaballo, Oracle posted Version 7 Update 7 for Java today (8/30/2012) and it fixes all of the vulnerabilities that isjavaexploitable can detect. Visit www.java.com/getjava/ to update yours immediately! Now, the only open questions are: 1. Have all 19 vulnerabilities that Polish company Security Explorations reported to Oracle on April 2, 2012, been fixed? and 2. Have the remaining 10 vulnerabilities that they further found and reported after that date been fixed as well? I certainly hope so, but you’ll want to keep an eye on this situation, and read Lucian Constantin’s excellent Computerworld story from August 29 entitled “Oracle knew about zero-day Java vulnerabilities for months, researcher says” for more information, and an explanation as to why I remain to be fully convinced that all the exposures have been handled.