Those of you Apple Macintosh users out there ready to jump onto the latest Mac OS X 10.6.5 update for Snow Leopard may want to first double-check that you’re not about to brick your shiny Mac.  If you use PGP Whole Disk Encryption on your Mac, you’ll want to first decrypt your disks before installing the update.

It would seem that due to a miscommunication between Symantec (the folks who bought out PGP) and Apple, the Mac OS X 10.6.5 update contains a new EFI booter that doesn’t work with PGP’s WDE, rendering the machine unable to boot up.  Possibly because Apple may have forgotten to put their latest EFI booter into the update’s beta test release.  Or if they did, then possibly PGP just somehow forgot to actually test Apple’s Snow Leopard update?

Anyway, the solution is simple, if you haven’t applied the update yet.  According to PGP, just decrypt your disks before installing the Snow Leopard upgrade and the new EFI booter has nothing to clash with.  Then you can re-encrypt once the update is installed and your Mac safely rebooted to get back to the security you need.  Of course that’s an unofficial solution.

If you wait long enough PGP/Symantec and Apple should officially sort this out.  Assuming you don’t mind the wait.

If, however, you’ve already bricked your Mac and need a solution to bring it back to working order because you expected that any sane and competent company would have actually tested their software, well that’s fixable as well.  And it’s not altogether too complicated either.  Follow the instructions provided by PGP here. It involves downloading a CD image to burn yourself a recovery CD though, so you’ll likely need a working computer to perform it.  But then, if you’re reading this, you probably have one of those handy.  Oh, and you’d be needing a blank CD too I’d imagine since it requires burning a recovery CD and all.

Theoretically, if for some reason you can’t dig up a blank CD, there’s also been rumor that an approach similar to PGP’s fix can be used in which you put your bricked Mac into Target Disk Mode and then boot up with that other Mac that you still need, running PGP on that second Mac instead of booting off of the recovery CD.  There are no explicit step-by-step instructions for this, but allegedly it’s really not all that different from PGP’s official fix so you should be able to sort it out.

Good luck and godspeed.

The problem with computers and smart devices is that they’re just too complex to ever be 100% secure.  You can try all you like, but ultimately, the code itself will let you down.

We start off with an attack reminiscent of the recent Firefox 0-day vuln exploited on the Nobel Peace Prize website. Only this time it’s, you guessed it, Microsoft Internet Explorer … and can be found on Amnesty International’s Hong Kong website.  Unlike Firefox’s security hole that was fixed in a day however, this IE zero-day vulnerability has actually already been discovered a week ago and has now moved on to a bigger target.  Making it, a what, one-week vuln?  Either way, Microsoft Internet Explorer 6 and 7 are vulnerable to the exploit.  The security hole however doesn’t work against IE 8 because of Data Execution Prevention (DEP).  For those of you still using IE6, what the heck are you even thinking? Bad dog!  Naughty!  Go sit in the corner!  But for IE 6 and 7 users who want the protection of DEP, which should protect you from this 0-day vuln, find out more about Microsoft’s Enhanced Mitigation Experience Toolkit (EMET) and get it here.

Don’t think that’s the only infection to the Amnesty International website however.  it’s also infected with attacks on Adobe’s Flash and Shockwave player and Apple’s QuickTime media player.  He hates these cans.  Stay away from the cans!

Next on the chopping block would be Apple’s Mac OS X Leopard, haunted by the ghost of jailbreaking past.  The security hole in iOS which allowed the JailbreakMe 2.0 software to work on your iPhone, at least until Apple patched it, was also in Mac OS X.  And while Apple also later plugged that security hole in the latest versions of Mac OS X, they still as of yet have not patched Leopard and older versions of the Mac OS, leaving those older users still vulnerable to this exploit.  According to Core Security Technologies and their CoreLabs Research advisory, Apple is basically just sitting on the fix, not releasing it.  “According to information provided to us by Apple, a patch for this fix has already been developed. Apple provided us a release date for this patch in two opportunities but then failed to meet their our deadlines without giving us any notice or explanation.”

And since we’ve jumped over to smartphones now, let’s visit our last security hole over on good old Google Android.  Phones based on Android have a new threat, a bug which allows attackers to sneak any installs they want into a legitimate install.  A proof-of-concept app on the Android Market (until Google yanked it at least) was disguised as an expansion to the Angry Birds game.  The hack piggybacked on the legitimate sanctioned install to further add apps that could transmit data to a remote server, view the phones contacts and location information, and even gain full control of the phone’s SMS functionality which could be used to spam people at will.  All without the phone’s user having any clue that these were installed by abusing flaws in Android’s token system.  And that was just to prove that it could be done.  Imagine the terror that this security hole could cause by someone truly malicious.  Google is, of course, working on a fix.  And Google’s sage advice for avoiding being hacked?  “As always, we advise users to only install applications they trust.“  Brilliant!  Why didn’t I think of that?

So there you have it.  From new to old, computer to cell phone, Microsoft to Apple to Google, no one is safe.  Because while we all might like to think of computers as infallible, to err is human, and so apparently is it in anything human-created.  We make mistakes, even in, especially in, writing code.

To celebrate the 4th of July, hackers found a cross-site scripting (XSS) flaw to exploit on YouTube that allowed them to insert JavaScript code into the comments section of videos.  In theory this XSS vulnerability could have allowed them to do things like steal passwords.  Fortunately however the hackers on a somewhat less than mature roll used the YouTube security hole to do nothing more nefarious than redirect folks looking for Justin Bieber videos to false news reports that he had perished recently in a automobile accident.  Funny perhaps, but not the danger one would expect from such a vuln.

The bug was fixed in mere hours after it first appeared.  First comments were temporarily hidden by default to protect video viewers, and then once that was in place the actual security hole was patched and things returned to normal.

That’s how security is supposed to be done.

Though it pretty much goes without saying that a company like Google with a motto of “don’t be evil” will inevitably be caught being just that, it’s still entertaining when it happens, as irony is a dish best served whenever possible.  So it should come as no surprise that the Google Toolbar (versions 6.3.911.1819 through 6.4.1311.42 for Internet Explorer confirmed) has been caught with its pants down by the notable critic of Google, Ben Edelmen.

Specifically, the Google Toolbar was found to continue merrily tracking URLs even after users select the “Disable Google Toolbar only for this window” option.  Which is, of course, quite evil.  It’s a clear invasion of privacy.

Google, of course, claims that it was just a bug that somehow managed to slip past testing all this time.  A likely story.

Either way, whether alleged evil feature or improbably advantageous bug, now that Google can’t claim ignorance with its implied plausible deniability, Google has fixed it.  Updates are available as per normal Google Toolbar means that should correct this issue so that disabling the Google Toolbar actually and honestly keeps it from tracking your web browsing habits instead of secretly continuing to collect and transmit information even when it shouldn’t.

You might have thought that with Microsoft’s “Patch Tuesday” fix of the seven year bug, things would be over.  And in a more perfect world, they would be.  Unfortunately we don’t seem to live in that more perfect world.

The problem is, according to sources like Metasploit, it ain’t over yet.

“The MS08-068 patch addresses this attack only in the case where the attacker connects back to the victim,” says Metasploit.  In fact, Metasploit goes on to say, “The patch does NOT address the case where the attacker relays the connection to a third-party host that the victim has access to.”

And since this is quite possible to do, it basically means that Microsoft’s “fix” ammounts to nothing for any dedicated attacks.

So what does Microsoft have to say about it?  Well, let’s take a gander over here, where Christopher Budd speaks.

Let’s see. “At a high level, the behavior that was discussed in the original SMBRelay attack is related to some of the basic behavior of the legacy NTLM protocol.“  Okay, congratulations on being able to throw acronyms around.  “When this issue was first raised back in 2001, we said that we could not make changes to address this issue without negatively impacting network-based applications.“  Well … yeah.  Obviously fixing the problem would mean changes to every application that uses the faulty code.  It’s a lot of work.  Something that should have gotten on right away, instead of being put off.  But why do that when you can procrastinate?

“We did say that customers who were concerned about this issue could use SMB signing as an effective mitigation, but, the reality was that there were similar constraints that made it infeasible for customers to implement SMB signing.“  So the workaround wasn’t actually feasible.  Microsoft’s own words here.  “As Mark notes in his post, implementing SMB signing is still an option and one that we ultimately recommend.“  Wait, so it’s not feasible, but it’s still the option that Microsoft recommends?  Even after releasing their “fix”?

“However, if you’re like me and remember the SMBRelay attack, you now have a protection option in case you can’t implement SMB signing: apply MS08-068.“  Oh, great.  The MS08-068 that according to Metasploit isn’t actually a fix at all because a hacker can work around it to still execute code remotely.

So let me get this straight.  Microsoft delays a fix to Windows for seven years because it would mean also fixing all of the affected networking clients.  Instead of just fixing it and fixing the clients too.  Their suggestion to people who are afraid of an attack by this route are to use an admittedly “infeasable” workaround.   And when, so much later, Microsoft finally patches the actual security hole, they don’t fully patch it, but just one approach to it.  So that hackers can still get around the patch.  So your options are use a patch that doesn’t work, or use an “infeasable” workaround? And that’s after seven years!

Yep.  That’s security, Microsoft style.