Archive for March, 2007

MS, Novell, Black Helicopters…

March 31, 2007

Motley Fool’s Anders Bylund speculates that the Novell-Microsoft deal was some kind of divide and conquer strategy by Microsoft.

Perhaps Microsoft wanted to create a rift in the Linux community? If so, the plan is working perfectly at present. A long-awaited update to the General Public License (GPL) that governs the use of Linux kernel code, the vital support programs forming the rest of the operating system, and thousands of other open-source projects, just reached its third draft, with new language very specifically aimed at breaking up the Novell-Microsoft pact….

Microsoft might or might not have had defensive plans, but the whole affair turned into an offensive play regardless. It’s working out very well for the company, to the point where the legal indemnification entendre starts to sound far-fetched by comparison. Maybe this was the plan all along — a “divide and conquer” strategy based on a few huge egos clashing. Brilliant, if true.

I think Microsoft is in the deal for a bit more than tearing apart the Linux community. Bylund alludes that Novell holds rights to Unix System V. Microsoft probably wants the right to use to that code now that SCO most likely can’t provide it to them.

TJX and Encryption

March 31, 2007

Given the scope and magnitude of the theft of TJX’s customers’ credit card numbers, it’s no surprise there are many recent articles about encryption of customer data. Some of the best articles I’ve read about this issue have been at eWeek.

The TJX matter remains under investigation, but there’s some information we do know from an SEC filing. First, TJX transmitted unencrypted credit card data from point-of-sale to card issuers. Second, TJX’s protocols were loose enough that the intruder(s) apparently had TJX’s key(s). Third, this theft occurred over a long period of time.

Here’s what we still don’t know. We don’t yet know what method of encryption TJX used, but some forms like shared-key are much more vulnerable than others. We don’t know if this was a matter of sloppy protocols. How and where did TJX store keys? This is akin to keeping a house key under a door mat or flower pot: there are places burglars know to look for such things, so it’s a stupid idea to store stuff where people first look.

We also don’t know if it was even an intrusion yet. We don’t know if this was an inside job at TJX (someone was able to put what’s for all intents and purposes a worm on their servers to capture data transmitted between TJX and the card companies) or, if TJX used public-private keys, if someone with legitimate access to a certificate server was involved. And we don’t know if the two sources of theft (via unencrypted transmission, via having TJX’s key) are related.

I suspect, though, that it wasn’t an inside job — the scope of the theft is so extensive and it occurred so long that someone working on the inside would have to be pretty brazen to think it would go undetected. That would mean TJX has a significant liability issue because their policies and procedures exposed their customers to fraud.

The most troubling issue to me right now, based on what we do know, is how this was able to occur over what’s now believed to be an 18 month period. Companies should have audit and review measures in place consistent with and concomitant to the size of their businesses to protect their customers. It now appears TJX — a large multi-national retailer, not a mom and pop shop — had no audits of their processing systems or encryption protocols in that time.

TJX isn’t taking responsibility. From their SEC filing:

We rely on commercially available systems, software, tools and monitoring to provide security for processing, transmission and storage of confidential customer information, such as payment card and personal information. We believe that the intruder had access to the decryption algorithm for the encryption software we utilize,” the statement read. “The systems currently used for transmission and approval of payment card transactions, and the technology utilized in payment cards themselves, all of which can put payment-card data at risk, are determined and controlled by the payment-card industry, not by us.

It seems they want to pass the buck when it appears they had few if any safeguards — strict encryption protocols, routine auditing of changes to code on their servers (to detect things like code inserted to steal credit card information before it’s encrypted) — in place to protect their own customers. That’s inexcusable.

Apple TV Hacked

March 30, 2007

Engadget reports that someone’s already figured out how to enable the USB ports on an Apple TV box. Apple has disabled their device’s USB ports so they act only as service ports. I suspect this not only voids the warranty, but will invite Apple’s lawyers to harass the citizens who violate their super-strict EULAs and who have the audacity to show others how to get as much “use” as possible from their products. After all, they’ve successfully had sites shut down for showing how to install OSX on non-Apple computers.

DSL’s Future

March 30, 2007

I added a page with a list of my recommendations for the path I think DSL should take in response to Robert’s poll seeking input from users.

Projects Update 2007-03-30

March 30, 2007

I’ve added a couple entries to my projects page.

edited 20070406 to reflect deletion of page

Oracle Customers Stand Up

March 29, 2007

Infoworld’s Matt Asay wants it both ways. A couple months ago he took on Mark Shuttleworth for “not getting” enterprise Linux. He rightly wrote:

What Mark doesn’t recognize - either out of pretence (meaning, he knows better but pretends otherwise) or out of ignorance (because Ubuntu isn’t yet being used in the enterprise, so he doesn’t yet know better) - is that the so-called closed binary is an important requirement for making Linux work in the data center, and across the enterprise, generally. No one writes applications to the source RPMs because no one wants to do so. Enterprises buy Red Hat (or Novell’s SUSE) because they want certified stability and performance.

Those are very important criteria for enterprise users. Now Asay writes that Oracle should use Ubuntu instead of Red Hat.

I still don’t understand why, other than out of spite, Oracle doesn’t simply adopt Ubuntu and run with that, but perhaps it’s the same reason that we used to start with Red Hat Linux back in my Lineo days (as did every other embedded Linux vendor of which I’m aware) - it was just easier to start with what was perceived to be the best.

First, Larry Ellison and his company are both serious enough and smart enough to do things the right way rather than out of spite. Second, the reason why Oracle won’t use Ubuntu over RHEL for their trusted Linux is the same two reasons Asay addressed Shuttleworth’s “not getting it” back in January: certified stability and performance. Ubuntu LTS has been available about eight months. RHEL has a much longer track record and a well-earned reputation for critical and and enterprise use. Third, Oracle knows that last point very well, and they also already know RH inside out. If their customers demand Ubuntu over RHEL, that’s exactly what Oracle will give them.

80% of Malicious Code from Ads

March 28, 2007

The Internet security firm Finjan has completed a survey of over 10 million unique URIs recorded in UK traffic and found that online advertising accounts for 80% of all instances of malicious code.

Finjan’s press release says that hackers have enough of an upperhand that they no longer need use backwater servers:

As commercial interests continue to drive e-crime, malicious code is more likely to be hosted on local servers in the US and UK than in countries with less developed e-crime law enforcement policies.

A continuing evolution in the complexity of attacks, specifically the increasing use of code obfuscation using diverse randomization techniques. Over 80% of the malicious code detected by Finjan was obfuscated, making it virtually invisible to pattern-matching/signature-based methods in use by anti-virus products.

Increasing sophistication at embedding malicious code within legitimate content (e.g., ad delivery and translation services) and less dependence on outlaw servers in unregulated countries.

The problem isn’t limited to the usual culprits like porn and warez sites. Respected companies like Yahoo allow third-parties to serve ads within their pages. The click fraud scandal pales in comparison to what can — and will — happen when really bad people insert really bad code on trusted sites.

SeaMonkey, Flash, Flashblock

March 28, 2007

SeaMonkey 1.1.1 has a lengthy list of known issues, some of which are Linux-specific. I mentioned a week or two ago in the DSL Forums that I was experiencing one of them regarding Flash.

Every time I’d hit a site with Flash, I’d get the prompt that I needed the Flash plug-in. I would cancel it and then I would either crash immediately or soon thereafter (such as when switching tabs). After reading the list of known issues, I’m not sure that installing the Flash plug-in would’ve done much to reduce the crashes which were occurring several times per day — it’s amazingly stupid and inconsiderate the number of major websites that run stuff like Flash by default. This is a serious issue — SeaMonkey 1.1.1 has been very unstable because of it.

The Linux binaries we distribute are now compiled with GCC 3.3 or GCC 3.4… Users of older Linux versions should wait for a SeaMonkey version compiled specifically for their Linux distro, or compile it themselves. Other than potential plugin issues, however, SeaMonkey continues to support very old distros.

Okay, so what are the recommendations? The site suggests installing the latest versions of Java and Flash, which appear to be the biggest culprits. The former is acceptable. The latter isn’t — nevermind the fact that Flash is proprietary, it’s not exactly the most secure thing someone can add to a computer:

Personalized Results 1 - 10 of about 23,400,000 for flash security issues. (0.20 seconds)

And now that piece of excrement is causing SeaMonkey to crash several times a day! Per the “known issues” page:

Some SeaMonkey crashes are actually caused by Flash.

No kidding! And installing a newer and larger version of it so Flash will load by default will stop that? I don’t want it anyway, so why do I even have to be prompted incessantly?

I decided to find a way to block Flash content altogether. Flashblock sets placeholders for Flash content and allows the user to decide if he or she wants to view that content. This has totally eliminated the prompt of a “need” to install the plug-in. More importantly, I haven’t crashed since installing it.

It would be nice if SeaMonkey’s development team would integrate such “blocking” utilities in the default build just like they do for pop-ups and other annoyances. Users — not the application’s developers or webmasters of visited sites — should get to determine exactly what content types load or don’t when clicking on a website. Plug-ins shouldn’t load by default, and users shouldn’t be prompted more than once to install a plug-in, unless a user turns on such features to allow those things.

And while I’m on the subject, people should avoid supporting or using any Linux distribution that installs closed or proprietary code like Flash or Opera or certain drivers by default. That includes Mint, the developers of which are totally willing to compromise when it comes to things that “produce an elegant desktop.” That’s something users should get to decide for themselves. Not developers.

Added Net Tool Page

March 27, 2007

I’ve added a page showing my network tool.

Latest in WiFi Protection: Paint?

March 24, 2007

Just read this article about EM-SEC Coating. EM-SEC Technologies reports their paint creates an electromagnetic barrier that can turn a room or office building into an EM fortress. It was initially developed for military use, but EM-SEC will now try to sell it to private companies.

From their press release:

The tests demonstrated that intellectual property can no longer be stolen through the airwaves while inside an EM-SEC-coated facility. The results showed that a one-time application of the EM-SEC Coating creates an “electromagnetic fortress” by preventing airborne hackers from intercepting signals.

Send Debbie Travis over with a few cans any day.