May Updates and Patch Report: Part 2

It’s interesting how you can go through an entire week of work and think that nothing significant happened in the security world. Now that I am trying to write these updates on a weekly basis, I’m paying a bit closer attention. While we won’t have huge patch-focused updates unless it’s the same week as a patch release, it doesn’t mean nothing has been going on. So, without further ado here are this week’s updates and patch report. If you missed last week’s, read it here.



EMET 3.0 has been released. What is EMET you ask?

EMET stands for “Enhanced Mitigation Experience Toolkit” and is basically a tool that allows you to protect Windows applications from attack. We’re used to applying patches for things like this, but sometimes a problem is more complex than people think and patches are a long time coming. EMET allows you to shift from a reactive to a proactive stance. This is a different way of protecting your systems and will take some work to get started. However, if your operational guidelines have matured to the point you have identified allowed applications and are either using application control or imaging, this can provide a nice additional layer of protection. With this new version, you can also identify attempts to exploit vulnerabilities, which can give you preliminary warnings of attack.



Google has released a new version of Chrome. This new version adds a few features and patches several security bugs. If you are running Chrome, it should have automatically updated. If you want to verify the update has gone through, go to Tools->About and make sure you’re running version 19 or higher.



Apple has released a new version of QuickTime. This version patches seventeen problems and affects the application on both Windows and OSX. If you use it, patch it.  Details are here.



Trail of Bits published an interesting article on the relative security merits of Android versus iOS. The heart of their argument is Android phones aren’t updated as often as the iPhone and the Android marketplace is more flexible and this brings additional malware risk.

While this is true, it is also true the reduction of controls allows for faster development. Additionally, the deployment of Android updates is the job of the carrier, not of Google. Blaming Google for the carriers’ unwillingness to deploy updates to older phones is, I think, unfair. The real problem is carriers make more money when people buy new phones, so the longer they support the old phones, the less money they make. Apple has embraced this economic reality by convincing people to throw away their devices and buy new ones every year or so.

So here’s the truth.  If you are concerned about malware you have three options:

1) Use iOS and trust Apple to protect you. Do not jailbreak anything and live with what you get.

2) Use Android and run an anti-malware agent. I like Sophos Mobile Security (beta) and Lookout. On my phone, at least, they even seem to play well together. Don’t install apps willy-nilly.

3) Use Android, run an anti-malware agent (as above), root it and install firewall and adblockers. This makes you more vulnerable to malware, but gives you additional protection to (somewhat) make up for it. Optionally install your own ROM.

You do have to be more vigilant, but if that’s not a problem for you, you can actually get a more secure device than you can with IOS, as you are in charge of your updates and you don’t have to wait for it to fit within a company’s lifecycle.



A very interesting bug in sudo was discovered. There’s no point in my describing it here, as they did such a good job on Sophos Naked Security. Definitely go there and read about it.



RealPlayer has a brand new update. It patches three vulnerabilities in different levels of the product. However, the fourth vulnerability “why are people still using RealPlayer?” remains unpatched. :)

Apply the fix or remove the software.  The latter is generally a better choice.



A new denial of service tool is out. Known as the HTTP Unbearable Load King or “HULK,” it is different in that it takes greater care to make sure requests are unique. With a traditional DDoS tool, you can often find a traffic pattern to filter out and mitigate the attack. However, the more different each request is from one another, the harder this is to do. This tool raises the bar for DDoS protection.

If you are running a DDoS protection tool, take a look at the tool and check it against your protection system.  If it bypasses it, complain to your vendor so they fix the problem.

If you are not running a DDoS protection tool and are comfortable accepting the DDoS risk, just sit back and chuckle over the fact the most stealthy DDoS tool is known as The HULK.


That’s it for this week.  If you have any questions, please drop us a note.

Adventures in QA … Gotta love debug switches!

Debug switches … they’re useful for diagnosing and fixing stuff, but horrible for anything else.

RJS Software is first and foremost a writer of IBM iSeries and Microsoft-based software. We have a rich programming background and a wonderful crew of seasoned programmers … some of whom started back in the punch cards days of the 1960′s and 70′s.  But as good as our programmers are, we still have errors in our code from time-to-time that find their way into a customer’s hands.

Let’s be realistic, when you write hundreds of thousands of lines of code, it’s inevitable that something will slip through the cracks. Luckily, our QA team catches the obvious stuff, but occasionally a small bug will slip past their keen eyes. These bugs are the ones that only appear within a unique situation employed by a unique customer. And with those, 99.9% are completely innocuous, but it’s the 0.1% we’re always concerned about catching and fixing immediately before a real problem occurs.

Similarly, such is the case with Apple.  About three months ago, they released an update for OS X Lion version 10.7.3. Shortly after, a German IT administrator discovered a bug while reviewing the var/logs/secure.log file. He noticed that his password was being passed plain text in the secure.log file, which caused him to immediately post the error in Apple’s forum. Unfortunately, the thread was largely ignored until last week when a security researcher ran into the very same problem. He started digging and discovered the bug was the result of a debug flag that was left enabled and writes passwords plain text. It’s not actually a bug at all, it’s simply a debugging option that is performing exactly as it was designed to. But as we ourselves find, sometimes those tiny errors that aren’t supposed to be present in the production build, somehow make it past a QA team. It happens to us … it even happens to Apple.

For most Mac home users, this doesn’t really mean anything to you. This particular debug option is designed for the HomeDirMounter service and most home users are not using server-assigned home directories/server-mapped shares. The folks this is a show stopper for, however, are corporations and schools that deploy Macs in large scale where server-assigned home-share mapping is routine business.

The good news is if you haven’t migrated to OS X Lion 10.7.3 from 10.7.2, you’re in good shape. The debug flag isn’t enabled in 10.7.2. For those who have migrated, the soon-to-be released 10.7.4 version will have this debug flag disabled.