Betanews - Security

Betanews Podcast: Transportation security, Facebook sensitivity, and you

Scott M. Fulton, III — Thu, 10 Dec 2009 18:09:28 -0500

Click here to listen to What Are We Learning Today? Betanews podcast (MP3 format, approx. 20:00 min.)

On our second edition of the Betanews podcast, we take a look at the ongoing effort to keep stuff that we share on the Internet from not being shared so much. The Transportation Safety Administration and the American citizen are very much in the same bucket today, as both are being faced with a new and intriguing privacy and sensitivity debacle...essentially the same one, just in two different respects.

Here's links to the source information referenced in the podcast:

"TSA manual misstep leads to discipline" by Spencer S. Hsu, from the Washington Post, December 10, 2009.
"Redacting PDFs" - a December 16, 2005 blog post by Adobe product manager Rick Borstein showing users of current versions of Adobe Acrobat at that time how to make text look like it's redacted, when it's really not.
The PDF redaction problem: TSA may have been using old software, by Scott Fulton.
Not the first, not the last, technology predictions for 2010, by Carmi Levy.
"New Tools to Control Your Experience" by Ruchi Sanghvi, product manager for privacy at Facebook. Here Sanghvi introduces the new privacy controls unveiled today. The video excerpted in today's podcast also appears here.
"Facebook's New Privacy Changes: The Good, the Bad, and the Ugly" by Electronic Frontier Foundation senior staff attorney Kevin Bankston.

The PDF redaction problem: TSA may have been using old software

Scott M. Fulton, III — Thu, 10 Dec 2009 12:41:39 -0500

By Scott M. Fulton, III, Betanews

The problem with the release of a Transportation Security Administration security screening manual was not, as many news outlets reported yesterday, the fact that it appeared "out there on the Internet." As US Homeland Security Secretary Janet Napolitano told reporters this morning, according to the Washington Post, the TSA manual was supposed to have been posted on the Internet -- it was part of a cache of documents intentionally posted to a government procurement Web site.

The real problem is that the portions of the PDF document that were supposed to have been redacted -- or removed from the file and replaced with blackouts -- were not actually removed. Sec. Napolitano said this morning that disciplinary action may be taken against the TSA employees responsible, and at one point implied that only one person may inevitably be to blame.

But the fact that blackouts were applied yet the underlying text remained, indicates that the eventual cause may be deeper than just personal error. Betanews tests confirm that the supposedly redacted text from the TSA screening document were merely covered up by black rectangles, not deleted. A properly redacted document must clearly show where the original text was located, so as to boldly indicate its removal. The purpose of the blackout, generally, is to leave clear evidence of deletion, and thus not give readers the impression that the removed text could have been anywhere and of any length.

Our tests using Adobe Acrobat Professional, accompanied by our research of Adobe documents, indicate that the TSA may not have been using updated software. If it had, its employees' redaction process may have been more thorough, and that the underlying sensitive text may have been properly deleted.

Acrobat Professional 8 was the first version of Adobe's software to contain its own built-in tools for true redaction. Until then, Adobe directed customers to an add-on product that is still on the market, manufactured by Appligent, called Redax. That tool generates a securely redacted PDF document as the user marks segments of the original document for redaction. Applying the changes dynamically to a duplicate ensures that none of the original text is actually deleted from its file, while simultaneously ensuring that the redacted version of the document actually does get created.

In Acrobat Professional 8 (which is not even the most recent version), the text redaction process is not straightforward or intuitive, though it is meticulous enough that it can only be done deliberately and with full awareness of the results. There is a redaction toolbar, whose principal button is called Mark for Redaction. This button changes the cursor tool into a highlighter for indicating text intended to not only be marked with blackouts, but to be removed from a copy of the file as well.

Acrobat 8 gives the user clear warnings that the redacted file should be saved as a copy. It's therefore not as thorough as the Redax tool, which maintains the redacted file as a simultaneous copy. Nevertheless, Acrobat does guide the user through the process.

In Betanews tests using a different legal document unrelated to the TSA matter, we used the Redaction toolbar to mark a paragraph. We then clicked on Apply Redactions. As a result, using the default settings from Acrobat 8, the redacted text appeared in all black.

We then saved our redacted test document to a separate file. We then tried copying text around the redacted paragraph, and pasting it into a Notepad file to see whether the redacted text was still existent and legible, as it was in the TSA document. The redacted text was missing from the copied element, although the non-redacted text around it was properly pasted.

We also examined the saved, redacted file. PDF text isn't like HTML markup, so you can't read the main body of content just from its source material -- Adobe masks and compresses it. Still, the clearly changed portion of compressed code in the vicinity of the redacted text, coupled by the slightly smaller file size in proportion with the paragraph we redacted, indicates that the paragraph's contents did not appear in our test document -- it was gone, as it should be.

In short, had the TSA been using updated Adobe software, the security incident never would have happened.

In the TSA document, the supposedly redacted portions are masked with four-sided black rectangles with red borders, indicating that they were simply drawn as geometric objects. Prior to the release of Acrobat 8, Adobe was fully aware of customers' requests for true redaction tools.

In a December 2005 post to Adobe's own blog for legal professionals, the company's business development manager, Rick Borstein, acknowledged not only that the lack of built-in redaction was a missing feature, but also a security concern for the US government.

"A PDF distributed by the US government contained covered over text that was fully accessible," Borstein wrote. "In this case, the user authored a document in Microsoft Word and used Word's Tables and Borders toolbar to set the background color to black. Thus, black text on a black background which was not visually readable, but does not eliminate the data. When the user converted the document to PDF, a simple search of the document revealed the text."

He also related a separate incident where a user in a law office had used Acrobat to create false annotations -- notations intended for use as comments -- but positioned them over text that was not supposed to be read. "Un-redacting" the text, therefore, was as simple as turning Annotations view off.

Borstein went on to recommend that customers invest in Appligent's Redax tool. But then he offered readers an interim solution, something he felt would suffice for many users in the interim. He showed them how to draw black rectangles around text so that it appears redacted.

"There is another alternative which doesn't require any special software, but I do not recommend it unless you are *) really, really careful; *) seldom need to redact," he wrote, before demonstrating the rectangle effect. To ensure that the effect really does permanently cover up text from viewing, Borstein suggested that the resulting file be "flattened," or converted into a document with embedded TIFF images -- which is something many law offices, courts, and government agencies do today.

In a 2006 brochure on the subject of redaction (PDF available here) -- again, prior to the release of Acrobat 8 -- Adobe clearly warned its customers that customers tend to fail to properly redact sensitive material simply because they don't understand the nature of electronic documents.

"Editors may try to cover sensitive information with a colored rectangle or by highlighting text in black," reads Adobe's 2006 brochure. "While these methods work for hard copy documents, they are not appropriate for electronic documents because there are ways to extract the information from the resulting PDF document."

Acrobat is not, and never was, a word processor. The original text for documents is often created elsewhere -- in many cases, in Microsoft Word. There, users would often find their own ways to black out text in a document, making it appear to be redacted. They then operated under the mistaken assumption that Acrobat merely processed the text that users could see, when it actually absorbs all the text from the original, including that which appears obscured.

"The key to understanding how sensitive data can be embedded in a PDF document is that information hidden or covered in an electronic document, can easily be recovered," Adobe's brochure reads. "The solution is to ensure that sensitive information is not just visually hidden or made illegible, but is actually deleted from the source file."

Again, Adobe recommended Appligent's Redax tool for securely redacting text through Acrobat, especially when the source material is unavailable. Still, Adobe's warnings paint a much clearer picture of the operating conditions for any office that utilized, or continues to use, older versions of software including Adobe's. Since Acrobat is not a word processor, and since the source documents being prepared for public distribution may not necessarily be attached to those documents, a worker may not have had any actual tools for deleting the material he or she was directed to redact. Though a document can be created in Acrobat, a document whose source material comes from elsewhere, acts like a read-only copy. With modern versions of Acrobat, text from that copy may be redacted, and its underlying content deleted. But the result is not like hitting the Delete button on a word processor; truly redacted sections are clearly marked.

With older versions of Acrobat, a user may not have had many options. He could have drawn a rectangle around the blacked-out portion, but the next step would have been to flatten the file -- to make it look like something scanned from the copy machine. It may have also ballooned the byte count of the final output. What's more, the act of rendering the public portion of the text unusable, may have been a violation of policy.

All these factors should be taken into account during the government's investigation of the TSA's non-redacted document release, especially before considering the matter of who is eventually to blame.

Betanews Podcast: Rupert Murdoch and the buying stuff online problem

Scott M. Fulton, III — Tue, 08 Dec 2009 17:17:17 -0500

By Scott M. Fulton, III, Betanews

Click here to listen to the inaugural What Are We Learning Today? Betanews podcast (MP3 format)

We inaugurate our first Betanews podcast today with a look at two serious problems -- the quandary over how publishers can make the online news business sustainable long-term, and the problem with securing the Web's transaction layer. From the top of the cliff, to borrow an Arlo Guthrie analogy, they look like two little piles; but up close, they're one big one: We haven't really solved how to pay for things online, and the TLS problem is an illustration of that.

Here's links to some of the source material referenced in the podcast:

Rupert Murdoch's Wall Street Journal editorial on the business of online news.
Fee or free? Murdoch, Huffington square off over the cost of Internet news by Scott Fulton.
Marsh Ray and Steve Dispensa's blog entry on the TLS renegotiation problem.
"You can relax about the SSL break, mostly," from IBM Internet Security Systems engineer Tom Cross.
Indiscreet tweet trips awareness of Web SSL vulnerability by Scott Fulton.
Windows fix for TLS security bug still forthcoming, won't be Tuesday by Scott Fulton.

The Black Screen Syndrome, or, Tech news in search of the apocalypse

Scott M. Fulton, III — Thu, 03 Dec 2009 16:29:31 -0500

By Scott M. Fulton, III, Betanews

Was the "Black Screen of Death" issue (KSoD) covered by Betanews earlier this week a real story? This is a serious question, especially in the wake of security firm Prevx's admission that it was very premature in its conclusions that KSoD incidents had been triggered by last month's round of Patch Tuesday updates.

Let's discuss this rationally. Although it does not appear to be an exploitable security problem by malicious users, and we have reason to believe it cannot become one, the KSoD problem (differentiated from BSoD, the "Blue Screen of Death," something else entirely) is a strange symptom that has cropped up on some machines over the years -- in our experience, some Vista-based systems. Some. It is a significant enough problem that when Betanews encountered it first-hand last June, and I discovered a way for users to fish themselves out from being stuck with it (without installing any new software), I wrote about it and presented a solution that, at least, worked for me.

A very fair question to ask, then, is this: What exactly did Prevx do last Friday that was any different from what Betanews did last June? In essence, it was Prevx that encountered the problem on its own systems, and that discovered a solution that may, possibly, work for consumers. It produced an .EXE that automates what appeared to be Prevx's solution; by comparison, I had the user go through several steps. But in that respect, we were quite alike. You might expect a security company to encounter problems such as KSoD during its research and offer solutions, whereas one might not necessarily expect such a discovery from a Web site with a big list of beta downloads and a news feed alongside it.

What made Prevx's situation very different from ours, in the end, were the following events:

Prevx suggested the problem had become widespread, calling it a "crop" that "could affect millions," without any evidence to prove that it was ever that widespread or could become so. Betanews reported the KSoD as affecting "a small number of Vista users since the system's debut three years ago, though that number appears to be growing steadily" -- an assertion for which we had obtained evidence.

Prevx made a guess as to the cause, and presented that guess as its professional analysis of that cause.

Prevx's explanation of its guess made no sense. Submitted for your review: "By the way - the cause of this recent crop of Black Screen appears to be a change in the Windows Operating Systems lock down of registry keys. This change has the effect of invalidating several key registry entries if they are updated without consideration of the new ACL rules being applied."

PrevX blamed Microsoft for the extent to which its guess made no sense. Apparently there was some rule change, and the fact that no one knows about it meant, from PrevX's perspective, that Microsoft forgot to tell us about it: "For reference the rule change does not appear to have been publicized adequately, if at all, with the recent Windows updates." (Microsoft's remarkable ability to be cited as having said something by virtue of having not said it, crops up again later.)

PrevX denied responsibility for its own actions. In a blog follow-up post yesterday, Prevx's Mel Morris wrote, "Referring back to the original post where the issue was first highlighted, we stated that there 'appear' to be many causes to the black screen issue...At no time have we categorically stated that these patches are the cause of the Black Screen problem...The emergence of this issue coincided with the recent set of Windows updates, therefore our investigations were focused on identifying if any of these could have been the cause of the problem."

Referring back to that original post, as Morris suggests, I notice "the cause" (singular), "recent crop" (collective plural), and "appears" (singular). I also see a reference to something called "the new ACL rules," which is something that we now know to be mythical. And as we all know, any change to Windows operating systems (plural) that takes place all at once, happens on account of a patch.

This reminds me of how local TV news "covers" a local lawmaker for "possible allegations," for example, of "possibly criminal corruption" connected with some "bizarre confluence of events" that "may have occurred." Rather than wait for a final report, a newscast will state, "Our investigation is ongoing...and we'll let you know what we find out."

One of these things is not like the others. One of these things doesn't belong.

However...PrevX's responsibility for the scare stops there. PrevX could have presented the issue in a more realistic light: "We encountered the KSoD ourselves, we fiddled with it, we've automated the script for a solution that fished our machines out of the mess, try it yourself if you get in a jam." By anyone's measure, that would have been a security company doing a responsible job of protecting the interests of its current and future customers.

But let's face an unfortunate reality that makes me, to borrow a phrase from Paddy Chayefsky's character Howard Biehl, "mad as hell:" All PrevX really did to start the firestorm brewing was post a blog entry with the headline, "Black Screen woes could affect millions on Windows 7, Vista and XP." That was the bait. Very little, if any substance, was necessary; and Microsoft's acknowledgement that it was looking into the issue was taken by the press as a confirmation that the problem was as bad as PrevX characterized it.

Next: Taking the deflated ball and running with it anyway...

Taking the deflated ball and running with it anyway

It was the BBC which gave undeserved legitimacy to the whole KSoD affair by running with the headline, "Windows 7 faces 'screen of death.'" The evidence of that story's existence is now waning outside of Google's indexes, as apparently the BBC's idea of a "retraction" is simply to erase its history. Even though the source of the original story, Prevx, effectively killed the body of the story by apologizing for having started it, it still had legs, so other sources ran with it. And kept running. When there was nowhere left to run.

As the London Daily Mail published yesterday, a whole day after the story was completely debunked, "Frustrated Windows 7 users are facing 'black screens of death' after logging on to their computers, Microsoft have confirmed. The software giant said they were investigating a disabling glitch that seems to particularly affect its latest operating system."

This adjacent to a mosaic assembly of pictures of computer screens, that forms the face of Microsoft CEO Steve Ballmer sticking his tongue out. Particularly...Windows 7. Where exactly did that come from? PrevX said the problem affected systems going back to Windows NT (architecturally speaking, extremely unlikely). And Microsoft's responses to us, both formal and informal, indicated it had never indicated to anyone that Windows 7, particularly, was at fault.

The Mail's version of an "update" to this article, once it apparently came across the debunking evidence, was to add a paragraph toward the bottom basically stating, everything you just read next to the Ballmer tongue photo is false: "However, they [PrevX] have since retracted this claim and suggested malware could be the culprit."

The London Telegraph then followed up to this already ballooning myth with the headline "Windows 7 Black Screen of Death blamed on malware." That story suggested that, by Microsoft's having stated its investigations to have determined its Patch Tuesday updates did not trigger the condition, by process of elimination, Microsoft implied that malware was to blame. In other words, quite literally, what Microsoft did not say must therefore be what it meant to say, and thus, is what it did say.

The BBC -- which lent a lot of hot air to this balloon in the beginning -- ended up replacing its original headline with this substitute, headed "Malware suspected of 'black screen' issue," apparently following after the Telegraph. But having evidently been unable to confirm that it was Microsoft doing the suspicion, the BBC left the headline in passive voice -- not actually saying who, if anyone, suspected the existence of some malware out there. "Malware has been blamed for a problem with the Windows 7 operating system," the BBC's (replaced) story begins, now making the following assumptions: 1) Somebody found a piece of malware out there; 2) somebody investigated the malware and has concluded it caused the problem with Windows 7; 3) there's a problem with Windows 7.

Therefore, Microsoft's having stated it wasn't Patch Tuesday that caused the (non-existent) problem, must mean by implication it must be malware. So now there's a rampant virus targeting Windows 7.

How many folks out there have the (non-existent) virus? As of a few hours ago, we have a firm (non-existent) estimate: A major tech news service reports that some 50,000 PCs have encountered the KSoD problem. This having been gleaned from PrevX's recent statement on its blog that its maybe-it-will-maybe-it-won't fix for the problem was downloaded by 50,000 users.

A quick check of our own Fileforum shows that millions of Windows users have downloaded anti-virus utilities from us. By that same logic, millions of Windows PCs must be infected with viruses this very moment. My God! It's the Black Plague of Doom! (KPoD)

Although Betanews has seen reports from individual users of troubles with Windows 7, we have not uncovered even a single credibly verified incident of a Windows 7 user -- as opposed to a Vista user -- encountering the KSoD issue. Not one. And for those who would conclude that by "not one" we mean "one million," "not one" means "zero." Naught. Bupkus.

Will somebody please inform me: At what time in the history of media did it become acceptable, or even preferable, for "the truth" to become defined as something validated through repetition and amplified by nervous anxiety? The way Internet-driven media has evolved, it appears that the definition of a viable story is anything that advances what someone else has already published, regardless or even in spite of the facts.

If the Black Screen problem was small to begin with, a fair question to ask is, why did we report on it in June? My personal belief, as Managing Editor of this publication, is that our job is to help information professionals make better sense and better use of their computers, their software, their environment, and their workplace. Our June story became a story the moment I found a prospective solution. In fact, that's what the story was really about: a possible fix to a problem that anyone could encounter, probably through no fault of his own. So no, we weren't sensationalizing the problem, although we did have "black" and "death" in our headline.

If there is no "crop" of KSoDs (regardless of what the alternate universe says), then the continued existence of the problem was not a newsworthy event in itself. But a potential solution to the problem, regardless of its relatively sparse dissemination, is a newsworthy event.

However...and here's the sad part...It has become the duty of anyone who would dare to continue to bear the moniker "journalist," to report the fact that a widely reported news story is largely false. And therefore it also becomes the sad responsibility of any journalistic publication to take the heat for giving further weight and volume to a story, in the act of trying to diffuse it and remove weight from it. The essence of the complaints we received boiled down to this: Betanews is guilty for perpetuating a story that's not worth perpetuating. We legitimized the issue by elevating it to a Betanews headline, for a story that ostensibly pointed out its illegitimacy. In short, it's all our fault.

I offer great thanks today to my friend and colleague, ZDNet blogger Ed Bott, for giving credit to Betanews for reporting the Prevx story as accurately as we could, in the face of the dust storm of falsehood. As Ed wrote this morning, "If someone had exercised even a basic set of journalistic skills, this story might never have taken off. But someone decided that this sensationalist report was worth a lot of page views and hit the Publish button when it was half-baked."

Thank you so much, Ed. It's good to know we're not alone in this fight. There may have been a lot of publications that did exercise a basic set of journalistic skills, right off the bat -- they may have read through the PrevX blog post and found it lacked merit. But we'll never know who they were, because the headline, "Blog Post From Little-Known Security Company Lacks Merit," isn't worthy of a story either...at least, not until after the news from the alternate universe makes its way here, and is all over Twitter.

The real nightmare here, the new and fundamental reality that looks more like Utopia to Arianna Huffington, is that Internet services are now building their news services into repetition farms intentionally designed to perpetuate and amplify stories that seem true enough. Silcon Valley Insider's Nicholas Carlson did the world a service Tuesday by publishing the new Aol's news guidelines for its prospective news amplification farm of what may very well be some 2,500 (not making up this number) prospective freelancers, each of whom will likely be paid very little.

Journalism is apparently no longer a requirement there. As the editor of Aol's new RendedSpaces.com blog advises writers, "All we want to know for a pitch is: what's the story, who broke it (AP, NYT, BW, Bloomberg, etc.), and how you will advance the story if you are following someone else's reporting."

We have enough repeater services; and as was found to be the case with the Black Screen story, repetition is the driving force behind the news problem. At the risk of sounding like Rupert Murdoch, the aggregation of non-news gave it the legitimacy of a story produced by actual journalists. But in the absence of a solution to the bigger problem of earning enough revenue to pay real journalists to produce actual news, online publishers are resorting to merely "advancing" whatever story generates the most excitement, embellishing it with implied non-realities along the way.

This is the malware whose viral impact is eating the news business alive. When the BBC cannot distinguish fact from fabrication, we are all truly endangered.

Security firm: Windows patches not responsible for 'Black Screen of Death'

Scott M. Fulton, III — Tue, 01 Dec 2009 21:49:55 -0500

By Scott M. Fulton, III, Betanews

When Betanews reported last June about occurrences of the infamous "Black Screen of Death" (KSoD) in Windows Vista, a reader wrote to suggest to us that we might have only considered the matter so important this late in the game because suddenly it happened to us. A similar opinion may be appropriate for British security firm Prevx, which now says it has "exonerated" last month's set of Patch Tuesday updates from Microsoft as the cause of what it called last night a "crop" of KSoD incidents.

Early Tuesday evening, Prevx director of malware research Jacques Erasmus reported on his company's blog that he and his team have made "significant progress in determining specific triggers of the black screen event." Specifically, it determined that a side-effect accidentally discovered over three years ago by none other than SysInternals' Mark Russinovich (now with Microsoft), led to instances where Windows' product activation inadvertently triggered the black screen. When a System Registry entry of String type is supposed to be terminated by a null character (0) but isn't, the result is that the entry itself may disappear from REGEDIT, Windows' well-known Registry Editor. Such an entry may also trigger KSoD conditions.

But that much has been public knowledge for as long as Russinovich has been distributing his "cool" registry key hider tool. Nevertheless, Prevx now has come around to believing that non-terminated Registry entries to be the cause of KSoD problems, not some strange and allegedly unpublicized change in the "rules" for Access Control Lists that a patch may not have followed.

Erasmus may have had some help in reaching this conclusion from Microsoft. In a statement to Betanews late this afternoon, security response communications lead Christopher Budd told us, "Our comprehensive investigation has shown that none of the recently released updates are related to the behavior described in the reports. While we were not contacted by the organization who originally made these reports, we have proactively contacted them with our findings."

So if Prevx wasn't really sure that ACLs were at the root of the KSoD problem, exactly what does its free fix tool, released yesterday, do? This evening, Erasmus suggested that at the very least, it does nothing bad. "We apologize to Microsoft for any inconvenience our blog may have caused," he wrote. "This has been a challenging issue to identify. Users who have the black screen issue referred to can still safely use our free fix tool to restore their desktop icons and task bar."

Prevx's earlier story led to the BBC reporting a rash of KSoD incidents afflicting specifically Windows 7. The evidence of such a rash may have just disappeared, which doesn't exactly mean the problem has gone away. It does mean we can reset the panic button now.

Microsoft denies latest 'Black Screen of Death' claims

Scott M. Fulton, III — Tue, 01 Dec 2009 12:34:09 -0500

By Scott M. Fulton, III, Betanews

A spokesperson for Microsoft told Betanews early this afternoon that it has officially investigated claims that its latest security updates are the cause of an alleged "crop" of "Black Screen of Death" incidents, for which British security firm Prevx hurriedly released something billed as a possible fix. The claims, the company says, are unfounded.

"Microsoft has investigated reports that its latest release of security updates is resulting in system issues for some customers due to changes made by the security updates to the registry," the spokesperson told us. "Our comprehensive investigation has shown that the November security updates, the Microsoft Malicious Software Removal Tool, and the non-security updates we released through Windows Update in November do not make any changes to the registry as claimed. We do not believe Microsoft Updates are related to the behavior described in these reports."

In the era of Google News, when the mere mention of certain high-intensity keywords can guarantee headline success, the phrases "black screen," "death," and "woes" are ripe pickings for blogs and news aggregators. The resulting swarm of Twitter links yesterday landed Prevx smack in the middle of BBC News this morning, after Prevx released what it called a "fix" (which may or may not work) for recent Black Screen of Death (KSoD) incidents. Although such incidents have continued to be reported for years, including by Betanews itself, the existence of a recent "crop" of such problems had not been apparent or even claimed until Prevx's release yesterday.

The KSoD problem is a real problem, and we've covered it before because it's happened to us. But in our case, it happened on Vista-based PCs, not Windows 7. There are multiple known potential causes; the one we discovered for Vista had to do with a faulty event log that the operating system could not read or write to during the startup sequence. That failure triggered a condition intentionally created for when a user runs a non-genuine copy of Windows for too long (ours was certainly genuine).

Our research on the subject suggests that any number of potential causes could still trigger the product activation feature to show a black screen on top of the active Windows desktop -- which is how the activation penalty is actually designed to work, even though triggered by the wrong causes. But we have yet to notice the problem ourselves, or see a "crop" or "swarm" or "blizzard" of such incidents, on Windows 7.

Prevx is claiming the existence of a new "crop" of KSoD issues affecting all versions of Windows going back to NT. In the past, the firm has released free tools which have appeared to counteract the effects of specific security incidents, such as straying onto a rogue anti-malware site and picking up real malware or even rootkits in the process. An initial observation of the 49K FixShell.exe file released by Prevx yesterday shows nothing obviously malicious. It contains a valid XML manifest, and a code certificate backed by VeriSign. And in fact, on our test system with Sophos anti-malware installed, not only did the file not appear to run any process of its own on startup, it did not appear to do what Prevx said it would do: make adjustments to the System Registry.

For a company that made its name pointing out the dangers of trusting any old site that claims it's found an infection on your system and it can fix that for you, it may be a little ironic for Prevx to be pushing a quick fix as an .EXE file, for a problem whose causes it can't adequately explain.

"The cause of this recent crop of Black Screen appears to be a change in the Windows Operating Systems lock down of registry keys," writes Prevx support technician David Kennerley. "This change has the effect of invalidating several key registry entries if they are updated without consideration of the new ACL [access control list] rules being applied. For reference the rule change does not appear to have been publicized adequately, if at all, with the recent Windows updates."

Kennerley goes on to say Prevx knows of ten different scenarios that could trigger KSoD conditions, and acknowledges that maybe this fix will work and maybe it won't.

Assuming that by "recent" Kennerley meant within the last few months, of the Patch Tuesday fixes Microsoft has released since October, only a few have been broad enough to cover multiple versions of Windows dating back to at least Windows 2000. Microsoft does not actively support Windows NT any longer, so it's conceivable that a reported issue that impacted W2K could affect NT as well. But none of the security bulletins and fixes issued for the broader problems appear to deal with what Kennerley is implying: the institution of some kind of lockdown mechanism for certain System Registry keys, that may conflict with the permissions that programs and system services may expect for their access control lists.

We're not aware of any rule change for access control lists; and Microsoft certainly had plenty of opportunity to discuss such a change, if there was one, with developers at PDC 2009 a few weeks ago. Perhaps a more likely scenario was that a recent patch may have changed permissions for a file or resource that some program, possibly a third-party driver, expected to be more open. If that's the case, even if the Prevx fix does cure the KSoD problem, it would be conceivable that adjusting the permissions the other way could re-introduce the vulnerability that the original Microsoft patch addressed. That's assuming the fix actually does anything at all -- something which we haven't yet been able to verify.

However, all of that is speculation until anyone, including Microsoft, can make sense of just what it was that Kennerley is claiming.

"The successful deployment of security updates is the ultimate goal of the Microsoft Security Response Center. Because of this, we continually work with our Customer Service and Support teams to keep a close eye for issues that may impact customers' deployment of security updates. Based on our investigation so far we can say that we're not seeing this as an issue from our support organization," the spokesperson told us. "The issues as described also do not match any known issues that have been documented in the security bulletins or KB articles."

E-mails to known Prevx addresses bounced back this morning, as though no one were actually present at the firm.

The fallacy of Facebook privacy

Carmi Levy — Thu, 26 Nov 2009 13:03:39 -0500

By Carmi Levy, Betanews

Natalie Blanchard is either the most naïve Facebook user in the history of the social networking service, or an incredibly unlucky woman who just can't seem to get back on her feet. Whatever title she ends up wearing, she's quickly becoming the poster child for caution in the social media age. Unless you belong to a mysterious sect that specifically bans any form of online activity, either learn her difficult lesson or risk suffering a similar fate.

The resident of Bromont, Quebec, Canada suffers from severe depression and has been on long-term disability leave from her job at IBM for over a year-and-a-half. She had been receiving benefits from her company's insurer, Manulife, until earlier this fall when the checks suddenly stopped coming. When she called her insurance agent to find out why, she was told the company had looked up her supposedly private Facebook account, and found pictures of her posing with Chippendale dancers at a bar, attending a birthday party, and enjoying a beach vacation.

For its part, Manulife won't comment specifically about the Blanchard case. While the company has said it "would not deny or terminate a valid claim solely based on information published on Web sites such as Facebook," it did confirm that it does check into the Facebook accounts of its clients. And given Facebook's architecture, even a private account will leak information like photos and status updates to anyone with even a basic ability to navigate the service. Despite Facebook's recent efforts to shore up its privacy policies and procedures, its online definition and application of the term still differs greatly from how we learned it as kids.

Privacy? What privacy?

This comes too late to help Blanchard, of course, who couldn't understand how her insurance overlords got a hold of her supposedly locked down postings. This was her first, last, and only mistake. Because nothing is ever private on the Internet. And at the risk of kicking an unfortunate soul when she's already down, if you really wanted to keep something to yourself, you wouldn't put it online -- in any form -- in the first place.

We participate in social media specifically because we want to share slices of our respective life stories with those around us. Some of us also want to grow that audience, hence the relentless pressure to amass more online "friends" and followers. These tools have turned many of us into prolific broadcasters. And like any broadcast, where what's sent out is often consumed by a different audience than the originally intended one, there's always a risk, however small, of the message landing wrong. In Blanchard's case, not only did the photographic message spread further than intended, but it also prompted her insurer to believe she was no longer suffering from depression and could head back to work.

Whether she returns to her office or stays home will now likely be decided in court. Blanchard has filed a $275,000 civil suit against the insurer, and the first hearing is scheduled for Quebec Superior Court on December 8. However this particular case plays out, Facebookers, Twitterers, MySpacers, and bloggers everywhere now have another high-profile example of someone who, for whatever reason, failed to appreciate the impact her online activities would have on her real life.

In many respects, it's easy to feel sorry for Ms. Blanchard in her rejection of the insurer's rejection of her. She feels wronged by the company. She feels the company mistakenly assumes the pictures its investigators saw were clear evidence of her recovery. She claims the clubhopping, the partying, and the prancing around on the beach were all recommended by her doctor -- tonics for a depressed soul. She claimed that "in the moment" she felt fine, but leading up to and following the moments when those pictures were taken, she remained her depressed self.

The futility of picking a winner

It's hard to tell who's right and who's wrong in a case like this. And in virtually all respects, it simply doesn't matter. Manulife drew its own conclusions based on the evidence available to it through social media. Whether it's justified or not is almost irrelevant. Merely the whiff of impropriety in a social media posting is often enough to prompt an employer, an insurer, or some other class of protagonist to pull the plug.

As we lead more of our lives online, the number of incidents like this will only skyrocket. Things like due process and presumption of innocence will all be tossed out the window as large organizations become more comfortable with their newfound power over employees and other small-potatoes stakeholders. HR departments now routinely Google job applicants and dig into their activities on popular social media sites to get a better picture of them than any resume or cover letter could ever provide. You can say what you want in your application package, the thinking goes, but what you do on your own time speaks volumes about the kind of person you really are...and whether you'll even get to that coveted first interview. The scrutiny doesn't end when you get the job, either, as our desire to hang it all out for all to see has tilted the playing field in favor of those who employ us.

I'd like to assume the rules for staying under the radar in this increasingly open, privacy-free environment are straightforward and easily understood. I'd also like to assume that there's an all-encompassing list of do's and don'ts out there that we can use as a guide for this Byzantine new order. But we all know where assumptions ultimately lead us, and in any event, the environment is changing too quickly for any one solution to ever stick long enough to be useful.

The sad truth is this: There's no way to ensure every person who reads every one of our online activities will absorb the tone of the message exactly as we originally intended. We could, of course, unplug completely. But that's an alternative that carries risks of its own, most of which are significantly worse than running afoul of some pencil-pushing insurance industry investigator.

Carmi Levy is a Canadian-based independent technology analyst and journalist still trying to live down his past life leading help desks and managing projects for large financial services organizations. He comments extensively in a wide range of media, and works closely with clients to help them leverage technology and social media tools and processes to drive their business.

Where there's smoke: Apple warranty stance raises troubling questions

Carmi Levy — Mon, 23 Nov 2009 20:18:04 -0500

By Carmi Levy, Betanews

I'm the last person who would ever come out in support of smoking. It's a noxious, nasty habit that according to the US Centers for Disease Control kills 443,000 Americans every year. The CDC says smoking is the root cause of over 30% of all cancer-related deaths, 80% of all lung cancer-related deaths, and 80% of deaths due to chronic obstructive pulmonary disease.

These are big, ugly numbers, for sure. But I'll be selfish and focus only on one: My father was a secret smoker for years -- a secret that ultimately landed him in hospital with a compromised heart, and a secret that ultimately killed him.

So far be it for me to defend smokers. And I won't. But after Apple's recent moves to tighten its warranty coverage and deny repair claims on machines that had been exposed to smoke, I find myself wondering whether the company has gone too far, and whether fair-minded consumers are being taken for a ride when they either buy an Apple-branded product or purchase an extended warranty.

The Non-Warranteed Warranty

First, the basics: The Consumerist reported last week on a couple of cases where Applecare Warranty claims were denied by Apple after technicians discovered the machines had been exposed to cigarette smoke. The company said it would not require its technicians to work on anything that could harm their health. And since nicotine is on the Occupational Safety and Health Administration's list of hazardous substances, Apple made it official by letting its techs refuse to provide service and, in the process, essentially void the warranties of smokers.

But here's the challenge: Not everyone whose machine is damaged by smoke is necessarily a smoker. While we can easily wag our fingers at folks who carelessly dangle a burning butt mere inches from their keyboard -- and laugh at them when the ragged remains muck up their keyboards and clog their fan intakes -- what about those poor saps who've never smoked in their lives, but happen to live or work in an area where their machines may suck up whatever's already in the air?

We don't often control where we both take and use our mobile devices. Some of us are occasionally forced to take our laptops into smoke-choked public places (they may be disappearing, but they still exist) or have the dumb luck to work in offices where the chain-smoking bosses still don't care about workplace health standards. Any machine that spends a few hours, days, or weeks in places like these will likely emerge with its insides coated with nicotine. Whether it's first-hand or second-hand smoke will hardly matter.

But wait, there's more

All of this means that Apple's newly tightened rules could potentially void coverage for perfectly well-meaning non-smokers who had the misfortune of using their machines in less-than-optimal environments. More ominously, Apple's move opens the door for other vendors to not only follow its lead, but to also pick and choose the kind of environmental conditions they'd like to void next. And even if they bother to update their fine print after you bring your spanking new piece of hardware home, chances are the first you'll hear of it is when something breaks and you bring it in for service, only to be told you're rather out of luck.

Apple has already managed to tick off some iPhone users by refusing to replace units whose moisture sensors had gone off. Immersion is another no-no for electronic devices, and Apple's been just as diligent ensuring it isn't on the hook for sweaty exercisers, rain-soaked commuters or folks who like to keep the humidifier on high. When I first wrote about this for Betanews last August, I got panicked phone calls from friends suddenly afraid to bring their iPhones into the kitchen while cooking or into the car on a damp, foggy morning. One father of a toddler freaked when the little munchkin appeared in his home office with a water pistol. It was empty, but he's now so worried about Apple's anti-moisture stance that the iPhone usually stays at home.

Say goodbye to mobility

Now that the smokey Pandora's Box has been opened, it's only a matter of time before we can't take our devices outside (UV, windborne pollen, excessive carbon dioxide due to global warming) or inside (fireplace emissions, paint fumes, foot odor) and are instead relegated to sticking them in protective bubbles that allow absolutely no interaction with the environment around them.

Yes, I'm being ridiculous. But so is Apple. Can the company's technicians truly tell the difference between smoke deposits left by a smoker, those obtained from second-hand smoke and those received during a business trip to smog-choked Shanghai, China? If Apple is so intent on shielding its techs from hazards, can it reasonably assure us that every piece of hardware it has ever made is completely devoid of noxious substances that can cause permanent damage to someone unlucky enough to pry open the case? In fairness to Apple, its latest generation of hardware leads the industry in eco-friendliness, but still, it's more than a little arbitrary to single out smoke deposits and nothing else.

Legally inclined folks refer to it as "reasonable use," which means, simply, that they'll cover claims arising from regular usage scenarios, and will deny those resulting from anomalous use. So accidentally bumping your machine against the door jamb as you rush out of the house is considered reasonable use. Pile-driving it into that same door jamb to test its structural integrity or otherwise entertain the small-minded? Not so much.

I get that vendors have to establish basic ground rules to prevent those small-minded folks from taking advantage of the system, and driving higher costs for the rest of us. I also get that the corporate ethics of a company led by a man who's been to the medical equivalent of hell and back twice, may be somewhat predisposed toward encouraging healthier, greener life choices. If that's what it takes to reduce the CDC's figures and save families needless heartache, then so be it. Vendors still shouldn't use it as an easy way to wiggle out of warranty obligations.

Sophos study suggests Windows 7 UAC's default setting is self-defeating

Scott M. Fulton, III — Thu, 05 Nov 2009 16:08:26 -0500

By Scott M. Fulton, III, Betanews

A blog post Tuesday by Sophos senior security engineer Chester Wisniewski stated that recent Sophos tests revealed that User Account Control -- the part of Windows that prompts the user for permission before granting elevated privileges -- was ineffective in stopping common samples of malware from running, in a Windows 7-based system without virus protection.

Whereas two of the ten chosen malware samples for the test would not run in Win7 without UAC turned on at all, only one more sample (a low-prevalence worm code-named W32/Autorun-ATK) was thwarted by UAC. The other seven ran as though they were being blocked only by a stack of dominoes.

Those items that ran unimpeded were: Troj/FakeAV-AFY and Troj/FakeAV-AFX, two low-prevalence Trojans that pretend to be a free anti-virus test; Mal/EncPk-KY and Mal/EncPk-KP, two garden-variety spam viruses; Troj/Agent-LIW, a low-prevalence Trojan that adjusts the behavior of Internet Explorer; Troj/Zbot-JN, a variation of the Trojan that attempts to steal online banking login information by first masquerading as an anonymous e-mail request for a date; and W32/Autorun-ATC, a garden-variety worm that changes the startup script.

"User Account Control did block one sample; however, its failure to block anything else just reinforces my warning prior to the Windows 7 launch that UAC's default configuration is not effective at protecting a PC from modern malware," Wisniewski wrote.

That default configuration is a new setting for Windows 7, that's one level down (and one level less annoying for some users) than Vista's default. During the testing process earlier this year, Windows 7 generated considerable controversy for effectively enabling some applications to generate a kind of "privilege self-elevation privilege" for themselves, which some saw as a vulnerability gift-wrapped for anyone wanting to go exploiting it. Others complained about a more sweeping potential problem: that the whole point of generating the message in the first place (stopping privilege elevation) is forfeited if developers leave a back door wide open.

As Wisniewski told Betanews this afternoon, his intention was not to prove UAC pointless in and of itself, but to suggest that Windows 7 may be vulnerable right out of the box unless and until users do something above and beyond the default.

"This was a quick test to determine if the efficacy of restricting administrative rights through the use of UAC alone will protect against malware infecting a computer running Windows 7," Wisniewski told us. "I did not test how it would have behaved if UAC was dialed up, or perhaps run in what people are calling 'Vista mode.'"

But if anti-virus is the solution to the problem (of course, Sophos is an anti-virus software maker), then what good is UAC at all, even if it's dialed up? Is Chet suggesting the whole thing is pointless anyway?

"I am performing some follow-up testing, although as is the case with malicious software, it does take a bit of time to safely perform these tests. With the data I have at the moment, I am not making recommendations as to what you do with UAC," he responded, "merely warning people that it does not protect a machine effectively against malware. I think Microsoft acknowledges this with their efforts on Microsoft Security Essentials and Forefront." But isn't UAC generally effective against malicious applications that seek elevated privilege levels, even if they're not among the most dangerous viruses cited by Sophos?

"We did not select specific malicious or difficult samples, merely the most recent ten at the time. Most were 'Fake AV' even if the sample names did not indicate that. We have generic detection for malicious packers and other nastiness that proactively finds many samples...With proper anti-malware protection, Windows 7 is far safer," acknowledged Sophos' security engineer.

"One benefit that UAC could have provided," he continued, "is an additional layer of protection that would help in the event that your anti-virus has failed to detect a new sample. It does not appear from my results that this is the case."

Indiscreet tweet trips awareness of Web SSL vulnerability

Scott M. Fulton, III — Thu, 05 Nov 2009 15:20:50 -0500

By Scott M. Fulton, III, Betanews

Internet security engineers who had been meeting secretly to discuss a possible extension to Transport Layer Security (TLS) to thwart a possible low-level exploit, were compelled yesterday to reveal the existence of their meetings after another security engineer unconnected to their project went public with a conceptual framework of the very type of exploit they were working to pre-emptively patch.

The problem is essentially a repeat of what developers of TLS and its parent protocol, Secure Sockets Layer (SSL), have dealt with a handful of times in the past: the potential of man-in-the-middle attacks by malicious servers that can pass themselves off as security authenticators. As the team from wireless security service provider PhoneFactor discovered last August, it was possible using both Microsoft IIS 7.0 and Apache httpd Web servers to demonstrate a situation where a false TLS server authenticates itself to a genuine Web client, then authenticates itself to a genuine TLS server, effectively setting itself up as a go-between that's privy to the complete contents of what appears to the innocent client to be a fully encrypted SSL session.

With online bank transactions worldwide currently covered just with SSL, the potential for global exploit now that the technique behind the attack is widely known, has just become enormous.

As PhoneFactor engineer Marsh Ray blogged this morning, he first suspected the possibility of a vulnerability while doing code testing of a product that a PhoneFactor partner was developing to support its software. "We realized this situation needed to be handled with a good measure of care," Ray wrote. "Over the first part of September 2009, we began disclosing the initial group of independent security consultants for independent verification and advice on how to proceed."

With the cooperation of groups such as the Internet Engineering Task Force, a working group was formed with the objective of developing an extension to TLS. Security vendors with representatives to the IETF, Ray implied, are aware of his and supervisor Steve Dispensa's work, so it's likely that remedial code for the problem has already been developed, and is being tested now.

Without divulging the technical details, here is the basic theory of Ray's and Dispensa's discovery: During a typical TLS (SSL) session, a handshaking process initiated by a client results in the legitimate server validating the client's certificate, and the client validating the one passed by the server. From there, an exchange takes place whose result is the production of an exclusive session key. Methods exist for one or the other party to request a change in the parameters of their transactions, perhaps to switch to a different, stronger cipher suite. However, because of the "post-only" nature of HTTP -- the transaction protocol around which the TLS session is based -- moving the session over to the stronger suite cannot mean suspending transactions in progress and picking them back up again later after the move. Instead, the old session is effectively ended and a new one begins.

At least, that's what's supposed to be enabled to happen, and there's where the trouble starts. The old session is ended, but in order to renegotiate the session, the client and server have to start all over again. In a situation similar to someone's e-mail application replying to your e-mail with a message whose subject line begins, RE:, the conversation between client and server over what to change to, contains a reference to the request for renegotiation -- the request that had, when sent earlier, been encrypted.

Now it's not, and that's the problem. The certificate chain that had been encrypted is now revealed in clear text; and it becomes possible for a malicious middleman to inject code into that chain. Ray was able to demonstrate the methods to security vendors, and that's where we'll stop before we get too detailed.

On a different IETF mailing list yesterday afternoon, a security researcher with SAP, who was running tests on Microsoft IIS, effectively discovered the same concept, and disclosed his discovery in a responsible manner as well. The problem: Someone reading that mailing list effectively broadcast the news "TLS is cracked," or something to that effect, to all his friends on Twitter.

Apparently last night -- maybe in the middle of the night -- is when Ray and Dispensa began getting phone calls from partners. The news was out, and now the need to keep "Project Mogul" secret had evaporated. Though a solution has already been in the works since at least early September, the race to secure the principal protocol governing the Web's monetary transactions has just kicked into overdrive.

Is AES encryption crackable?

Thu, 05 Nov 2009 11:06:00 -0500

By Jack M. Germain, TechNewsWorld

In the field of computer technology, some topics are so frequently and fiercely disputed that they almost resemble religious feuds -- Mac vs. PC, for instance, or open source vs. proprietary software.

Other topics, though, don't see nearly the same level of high-profile debate. Take the invulnerability of the Advanced Encryption Standard (AES) encryption, for example. Governments and businesses place a great deal of faith in the belief that AES is so secure that its security key can never be broken. However, a team of researchers from Germany, France and Israel has recently demonstrated what may be an inherent flaw in AES -- theoretically, at least.

So how secure is AES really? Is AES now vulnerable to a new attack, as the researchers claim?

Maybe yes, and maybe no. The research is mainly theoretical. Still, as technology evolves, successful attacks against AES may turn up, and they may be difficult to ignore.

"Can somebody repurpose and weaken the strength of the AES algorithm? Yes. That's what cryptographers do. But we don't have to worry about AES being weakened anytime soon. Still, AES in theory has flaws. The bottom line is that AES isn't broken," Ozzie Diaz, president and CEO of wireless security firm AirPatrol, told TeckNewsWorld.

What is it?

The AES protocol is a set of three block ciphers selected by the National Institute of Standards and Technology (NIST) in 2000 after a three-year competition. NIST is a federal technology agency that develops and promotes measurement standards. Its selection ousted Data Encryption Standard (DES) as the national and international security encryption standard. DES was the most widely deployed block cipher in both software and hardware applications.

Why should you care? AES encryption is the vault that secures online information and financial transactions by financial institutions, banks and e-commerce sites. So a tear in the AES fabric means an opening for hackers to get at valuable personal and business information.

AES is used in three versions: AES-128, AES-192 and AES-256. These numbers represent the encryption key sizes (128 bits, 192 bits and 256 bits) and in their number of rounds (10, 12, and 14, respectively) required to open the vault that is wrapped around the data.

The detractors

In their published report, entitled "Key Recovery Attacks of Practical Complexity on AES Variants With Up to 10 Rounds" (PDF available here), three researchers challenged the structural integrity of the AES protocol.

Although the research suggests AES might no longer be considered theoretically secure, the crucial question facing all of us now is how far it is from becoming practically insecure, concluded Alex Biryukov and Dmitry Khovratovich (University of Luxembourg, Luxembourg), Orr Dunkelman (of Paris, France), Nathan Keller (Einstein Institute of Mathematics, Hebrew University) and Adi Shamir (Computer Science department of the the Weizmann Institute at Rehovot, Israel).

"The findings discussed in 'Key Recovery Attacks of Practical Complexity on AES Variants With Up to 10 Rounds' are academic in nature and do not threaten the security of systems today. But because most people depend on the encryption standard to keep sensitive information secure, the findings are nonetheless significant," Fred Touchette, AppRiver senior security analyst, told TechNewsWorld.

A new worry?

If AES is now theoretically compromised, the real-world impact could be considerable, according to Diaz.

"My speculation is that the greatest vulnerabilities will be for wireless systems for two reasons. Most investments in network media are in wireless systems, and there is no physical barrier to entry for accessing the network," he said.

However, some good may come from even an academic demonstration of a flaw in AES, he conceded. Inflection points always occur in an industry in the form of disruptions. A disruption to the viability of a system today will lead to innovation in filling those gaps or completely changing the rules of the game, he said.

"AES is the standard in wireless and IT encryption. It keeps the mouse trap evolving faster than the mouse can move," said Diaz.

Cracked or broken?

The AES crypto is not broken, asserted Touchette. As in previous techniques, the latest attack techniques on AES-192 and AES-256 algorithms are impractical outside of a theoretical setting.

"But they do nonetheless provide theoretical proof that versions of AES could be susceptible to attack," he warned.

When these cryptos became a new standard, they were declared completely unbreakable. Many other algorithms out there still remain unbreakable, but as long as our systems get stronger and faster, the need for longer and tougher encryption will also grow. Just because the puzzles get harder doesn't mean that people will stop trying to solve them, he added.

An early warning

"AES is not compromised. It is safe to use. There are no problems with it," Paul Kocher, president and chief scientist at Cryptography Research, told TechNewsWorld.

Still, researchers are finding that it would not take as much to crack AES as previously thought, suggested Kocher, and that makes the report a significant finding.

Users are already paranoid over attacks that they don't understand, he noted, nd while attackers do improve over time, nobody actually breaks anything, he said.

"There is plenty of software bugs for attackers to use to bypass breaking the keys. That's what keeps me awake at night, not the algorithms," said Kocher.

Originally published on TechNewsWorld

Faster or more secure? Microsoft publishes IE patch to Automatic Updates

Scott M. Fulton, III — Thu, 05 Nov 2009 10:40:34 -0500

By Scott M. Fulton, III, Betanews

Given the choice between speed and security, Betanews readers this week have been siding with security, in a show of support that suggests that Windows Vista had the right idea after all. This morning, Windows XP, Vista, and Windows 7 users who have their Automatic Update notifications turned on manual will be making that choice, as Microsoft has published update 976749 -- released as a manual update on Monday -- to its Windows Update service, not as a "security update" or anything "critical" or even "important."

It's an "Update for Internet Explorer" whose purpose is to "resolve issues that may occur after installing the Internet Explorer cumulative security update issued as MS09-054" -- one of the major updates from the last Patch Tuesday round. The issue that update addressed is a very serious one, and Windows users who are concerned about their operating system possibly being vulnerable to a new class of attack, should apply that update and also apply the patch to that update, released this morning. Many users with Automatic Updates turned on full may wake up this morning with the update already having been applied.

Those folks may notice a difference, or they may not. There will be a performance cost, at least with respect to all versions of Internet Explorer since 5.01, but also to other features of Windows that rely on Internet Explorer. Betanews readers have suggested that this performance cost will be negligible, especially for those who do not time their browser with a stopwatch.

However, Betanews tests reveal the performance hit completely wipes out at least one category of speed increase that is the subject of recent Microsoft television advertising: a faster Web experience for those who prefer IE. Our tests show that, after update 976749 is applied, IE8 on Windows 7 is no faster than IE8 on Vista SP2 on the same machine.

Right now, the vulnerability exists more in concept than in practice. Although no known exploit appears to have been discovered yet, it's the architecture behind that vulnerability that makes it very serious at the outset. Conceivably, if and when an exploit appears and a patch is published to thwart it, malicious users could craft a variation of the exploit quite easily. The problem has to do with a fundamental programming technique that could be discontinued in the future, but which is pervasive throughout applications of all classes, from Microsoft and everyone else, and not just for Windows. Microsoft is treating the issue quite seriously, judging from the company's recent communications with us.

But the defense against this problem comes at an inopportune time for Microsoft, which is working to promote Windows 7 to consumers as better than its predecessor for being both more secure and faster. Of course, there are other Web browsers, perhaps all of which perform much faster and are arguably more secure. But Microsoft had been hoping to market IE8 as a solid contender, with some features like Web Slices and Accelerators that third-party alternatives have not yet matched. Microsoft may have to take a hit for publicly securing IE -- arguably the more responsible course of action -- at a time when Windows 7 is just coming out of the gate.

Performance drain: The first public perception test of the Windows 7 era

Scott M. Fulton, III — Wed, 04 Nov 2009 11:41:34 -0500

By Scott M. Fulton, III, Betanews

The key selling point for Windows 7, as emphasized in a concerted advertising campaign that stretches across both TV and the Web, is that it's leaner, simpler, and faster. It doesn't have to complete the phrase "faster than..." because we all know how to complete that phrase. Microsoft's bet for Windows 7 is that users smart enough to complete that phrase, care.

So if some of the comments Betanews has been receiving about Internet Explorer's recent problems being a non-event, or a "YAWN," really did reflect reality, then Microsoft has already lost the bet.

The security problem revealed last July at the Black Hat conference could be considered old but also latent -- it has not been exploited yet, and only recently have smarter folks looking for ways to improve security architecture shed light on it. It's a problem with how software components trade off objects of data in memory when their types are indeterminate, using a structure called variant. The receiving component learns about the variant's type through a structure that's passed along with the data, but as the Hustle Labs team demonstrated, components don't clean up after themselves in a safe way.

Microsoft has very obviously taken this revelation quite seriously, especially noting that the security team's demonstration in Las Vegas could give more malicious folks ideas they would never have conjured on their own. Last month's Patch Tuesday round reflected the degree of seriousness with which Microsoft is treating the matter.

The company's patches in recent weeks, including the patches to the patches, have resulted in noticeable and easily measurable performance degradation in Internet Explorer, both versions 7 and 8. This means that for a great many users of XP, Windows 7, and the "V-word," who use the platform they're given to run Web applications, they will notice a slowdown of one-third or more.

What's more, as it stands now, Betanews estimates that the performance differences between Internet Explorer 8 on Windows 7 and on Vista are negligible or even negative. That's right -- IE8 on Win7 is slightly slower than IE8 on Vista, at least according to yesterday's tests.

Now, what we could have done here is beat our competition to the obvious Hyperbolic Headline waiting to be harvested. You know the one I'm talking about: Windows 7 Slower Than Vista. Wouldn't that just be the Holy Grail? We'd be on Google News for a whole day, higher-ranking than Hamid Karzai's brother on the CIA payroll, more attention-grabbing than what Pamela Anderson paid to redecorate her bathroom, fresher than yet another "YAWN" about whether Nancy Pelosi would entertain removing the public option from health care!

Or not. Because apparently it doesn't matter, as the education I'm receiving from a few of my readers is attempting to enlighten me about. People use what they use, they like what they like, and they'll consume whatever's in front of them. Nancy Pelosi, Pamela Anderson, Lady Gaga, Internet Explorer...it all passes in front of consumers on a treadmill, and they don't pay any real attention to details or facts or arguments or qualitative differences.

Put another way, the argument goes like this: If security truly mattered to folks, then they wouldn't be using Windows in the first place. And if functionality and performance truly mattered, then two-thirds of the world's HTTP GET requests wouldn't come from IE. (And if quality mattered, Lady Gaga...etc.) A few microseconds given away here or there isn't really going to matter to folks whose only interaction with the net consists of waiting for Pamela's picture to download.

If that were true for everyone besides a few folks for whom the notion that stuff doesn't matter really, really matters, then Windows 7 really would be "Vista Service Pack 3" (it is, after all, internally numbered "Windows 6.1").

The "Windows 7 was my idea" campaign, which places an obvious bet that the consumer cares about things like speed and performance.

The reason Windows 7 exists as a brand name at all is because of a Microsoft change of course, a necessary one if the brand is to thrive rather than just subsist: When Microsoft bet the farm on the notion that users will be more comfortable with security than performance, it lost. Vista is a tarnished brand despite its enormous security improvements, partly because it was a slower performer to begin with, and partly because the fight to keep Vista secure was so public and so transparent to the regular user that every Patch Tuesday became a step down the ladder for Microsoft.

Wouldn't you rather be more secure than ~~more vulnerable~~ faster, a reader asked me yesterday? [Sorry, Paul, I messed up your question.] Yes, I would. But I'm an oddball. And if the pool of consumers out there were like me, there wouldn't be a Windows 7.

While technically this issue impacts all of Windows, not just Windows 7, this is a Windows 7 issue now, just as the multitudes of patches released for XP since 2007 were a Vista issue. It's Windows 7's turn on the watch tower; it's the system in the hot seat. If users after today come to believe that their systems are slower and slower and slower, even if it's Vista they're using, it will be Windows 7 that's blamed. Yes, people do care, but they also blame the most convenient target available to them. (Just ask any Democratic pollster today about the meaning of yesterday's elections.)

The fact that Microsoft has not issued its latest patch-to-the-patch as an automatic update but a manual one instead, is an indication that this time around, it's leaving the question of security-vs.-performance to the users and system admins. Granted, nobody on the malicious side of development has acquired the collective neurons yet to exploit the variant problem the way it could theoretically be exploited -- a fact for which I continually thank my local deity. But Vista proved that, for the same reason travelers feel less safe walking through airports where the security is tighter, calling attention to the "Hobson's Choice" -- to borrow a Carmi Levy phrase -- between performance and security leaves users with the impression that their systems are neither fast nor secure. If Windows were to apply this latest patch automatically, and advertise transparently that it had done so, and the result were slower systems, can't you just imagine the headlines then? Microsoft Reaches Into PCs and Makes Them Slower. Apple's marketing team would have a field day.

Transparency in computing (or government) is like honesty in dating: Everyone says it's the most important factor to them, until they get it: "I'm 44, short, and balding...and I have a latent but exploitable security deficiency."

On a scale comparable to the health care debate in Congress, the variant problem is actually just as big not only for Microsoft, but for Mozilla and Apple and Adobe and everyone else in this business. The real solution will require major changes to the way all software functions -- changes that mean we need to start talking about Internet Explorer 9 and Windows 8 and Firefox 5 and Chrome 94, now.

And people will notice the change. They'll notice because people care more than some folks think they do.

Microsoft and Mozilla leave Web users tangled over 'variant' vulnerability

Scott M. Fulton, III — Mon, 19 Oct 2009 12:02:39 -0400

By Scott M. Fulton, III, Betanews

In what is now indisputably the most important vulnerability addressed during last Tuesday's record round of Windows patches, the two companies most affected by the problem -- Microsoft and, to a lesser extent, Mozilla -- could not help but be caught in a tangle of miscommunication exacerbated to a large extent by overhype from a sea of blogs. As a result, it's everyday users who are left confused and bewildered, even though no known exploit for the vulnerability exists.

The problem involves both the ".NET Framework Assistant" add-on and "Windows Presentation Manager" plug-in made by Microsoft for Mozilla Firefox, both of which are installed automatically -- and without warning -- by Microsoft's .NET Framework 3.5 Service Pack 1. One of Microsoft's patches last week, as explained in a Microsoft bulletin, addresses the functionality of 3.5 SP1 that's made available through these Firefox extensions.

Meanwhile, on its end, Mozilla opted to disable these extensions at the browser level, for reasons explained by its vice president of engineering, Mike Shaver, as, "because of the difficulties some users have had entirely removing the add-on, and because of the severity of the risk it represents if not disabled." The move was made only after having contacted Microsoft first; and Microsoft agreed with the decision, Shaver said.

This contradicts a multitude of reports over the weekend saying that Mozilla had taken action in defiance of Microsoft's extensions.

But this morning, Microsoft issued a clarification to Mozilla, apparently correcting its own misunderstanding of the matter (or rather, when the weekday crew came in to relieve the weekend crew): The extensions themselves actually have nothing whatsoever to do with the Patch Tuesday vulnerability. This despite having been referenced in Microsoft's own security bulletin last Tuesday: "Firefox users who are running the Windows Presentation Foundation (WPF) plug-in and do not have it disabled should also apply this security update."

Upon realizing this news, Shaver announced this morning that Mozilla is un-blocking ~~the two extensions~~ [CORRECTION] the .NET Framework Assistant add-on, leaving the WPF plug-in blocked.

Yet that creates an entirely new problem, as Betanews discovered this morning: For the same reasons folks had trouble trying to uninstall these extensions before, they'll have trouble now re-installing them -- though .NET Framework Assistant appears in Firefox's Extensions list, the "Enable" button is greyed out, and the same goes for "Windows Presentation Foundation" in Firefox's Plug-ins list.

In an effort to shed some light on this wild subject, here now are some clarifying facts:

.NET Framework 3.5 SP1 was not one of the patches presented by Microsoft last Tuesday. When users noticed the two Firefox extensions for the first time this week, it was probably because they ended up installing SP1 at the same time they installed the critical and important Patch Tuesday updates. One of those updates was the Microsoft patch that temporarily disables the extensions' functionality.
ClickOnce functionality was not the subject of the vulnerability in question. ClickOnce is Microsoft's now extremely ironic brand name for a technology designed to enable .NET applications to update themselves over the Web, a process which requires elevated privilege since installed code is being replaced. While the possibility that .NET code could find itself running with elevated privileges as a result of the ClickOnce problem, the attack vector in question here involves something quite different -- a broad level of possible attack vector that's thus far unexploited (it takes some intelligence), for which .NET Framework was only a case-in-point.
It's not the extensions that are vulnerable in this instance, but rather the .NET Framework functionality which they enable through the browser.
Microsoft was not silent about having released its Firefox extensions. In fact, its engineers were quite proud of them, although few independent sources bothered to cover their existence until they became an annoyance (and we're guilty as charged here too). Granted, the world doesn't flock to Scott Hanselman's blog, though engineers can only do so much to tout their efforts. What Microsoft had neglected to do, in hindsight, was provide users with a way to opt out of changing their Firefox settings, or to uninstall these extensions once they appeared there. This has now morphed into a new problem: the lack of any direct ability to re-enable the plug-ins once they've been turned off. Betanews is still experimenting with finding a way to do this (it does not involve editing about:config, unfortunately), and we'll report it to you once we find it.

During a July presentation at the Black Hat conference by security engineers at Hustle Labs, a Microsoft mechanism called XBAP was used as a case-in-point for a demonstration of a much larger problem: the likelihood of vulnerabilities whenever interoperable code components use so-called variant data types to exchange information. Soon afterward, Microsoft began addressing the possibility of an exploit using an attack vector they feared could be inspired by the Hustle Labs demo.

XBAP is a facilitator for XAML, the XML-based layout language that substitutes for HTML for building Web apps. Microsoft began rolling out XBAP in August 2008, with Service Pack 1 to .NET Framework 3.5. Responding at the time to criticism that the company tends to release Web-based functionality for Internet Explorer only, it produced a ".NET Framework Assistant" add-on to Firefox as well, along with a plug-in that enabled XBAP in Firefox.

But neither extension gave Firefox users an option not for uninstallation. So when it was revealed that .NET's "ClickOnce" technology was potentially vulnerable, Firefox users were compelled to uninstall it manually. When users learned last weekend that Mozilla was blocking these add-ons, some bloggers assumed it was because of the ClickOnce matter, and reported it as such; ClickOnce is actually unrelated here.

Now, the problem going forward could be a number of Firefox users whose browsers are in need of some repair.

5:35 pm EDT October 19, 2009 · Responding to our story from earlier this morning, Mozilla Vice President for Engineering Mike Shaver told Betanews that this morning's unblocking action freed just the .NET Framework Assistant add-on for Firefox, not the Windows Presentation Foundation plug-in. It is Mozilla's belief, Shaver said, that this plug-in may still expose Firefox users to the principal vulnerability addressed in last Tuesday's Microsoft patch, as long as that plug-in remains enabled.

"We were told by Microsoft that the [.NET Assistant] add-on was vulnerable (and in fact at one point that the WPF plug-in was not, but we corrected that in conversation), and waited for confirmation from them that it wasn't before unblocking it," Shaver told Betanews. "We were not correcting ourselves; we were updating based on a Microsoft correction."

Not that Windows is any enclave of safety: Microsoft's biggest Patch Tuesday

Scott M. Fulton, III — Wed, 14 Oct 2009 15:03:32 -0400

By Scott M. Fulton, III, Betanews

A lot of the presentations at security (or perhaps more appropriately, "insecurity") conferences such as Black Hat are devoted to experiments or "dares" for hackers to break through some new version of digital security. After awhile, it gets to be like watching pre-schoolers daring one another to punch through ever-taller Lego walls. But in the midst of last July's briefings came at least one scientifically researched, carefully considered, and thoughtfully presented presentation: the result of a full-scale investigation by three engineers at a consultancy called Hustle Labs, demonstrating how the presumption of trust between browsers, their add-ons, and other code components can trigger the types of software failures that can become exploitable by malicious code.

Engineers Mark Dowd, Ryan Smith, and David Dewey are being credited today with shedding light on a coding practice by developers that leaves the door open for browser crashes. The discovery of specific instances where such a practice could easily become exploitable is the focus of the most critical of Microsoft's regular second-Tuesday-of-the-month patches -- arguably the biggest of 13 bulletins addressing a record 34 fixes.

Among today's fixes is one that specifically addresses a relatively new class of Web apps that use XAML, Microsoft's XML-based front-end layout language, instead of HTML for presenting the user with controls. The class of apps is currently being called XAML Browser Application, or XBAP (perhaps Microsoft should have it shut off just for the lousy acronym). Simply browsing to a maliciously crafted XBAP application could create an attack vector, says one of Microsoft's bulletins published this morning.

But that isn't actually the problem, but the symptom of a very serious problem uncovered by the Hustle Labs trio -- one that may generate several more security fixes in coming months. At the root of the problem is the fact that browser plug-ins and components external to browsers -- for instance, the components that tie browsers to the .NET Framework in order to run XBAP apps -- are given higher levels of trust than the browser itself. These days, trust levels are turned down on the browser to disable most any chance of a simple JavaScript deleting elements of the user's file system without authorization; but plug-ins are often given a medium level of trust simply because they must be interoperable with a component (the Web browser) that is outside of its own context.

So when a plug-in creates references to new components, a principle called transitive trust mandates that this medium-level trust be transferred to the new component. And when that new component is an instance of an ActiveX object, that new level of trust may mean that if the object causes an exception, the mess it leaves behind could have just enough privilege attributed to it to execute malicious code.

The mess itself, the Hustle Labs researchers illustrated last July at Black Hat (PDF available here), can be caused by a tricky data type that has raised my eyebrows since the early '90s when I witnessed its first demonstrations: It's the variant type, created to represent data that may be passed as a parameter between procedures or components, whose type may be unspecific or even unknown. The way Microsoft represents variants in memory is by pairing their type with their value as a single unit, and that type is actually a pointer to a structure. That structure may be a primary type, but most often in the case of COM components (known to Web users as ActiveX components), it's a complex object comprised of multiple data elements, assembled together like records in a database, often whose types may include other variants.

The problem with using variants, as Microsoft learned the hard way (more than once), is that when you're trying to secure the interfaces between components, the absence of explicit types makes it difficult to ensure that they're behaving within the rules. But as the researchers discovered, it's the security code itself -- what they call marshaling code, resurrecting language from COM's heyday -- that can actually cause a serious problem, a mess that leaves behind opportunities for exploitation.

"The most obvious mistake a control can make with regard to object retention is to neglect to add to the reference count of a COM object that it intends to retain," the trio writes. A reference count helps a control to maintain a handle to the object it's instantiated. But marshaling code, in an effort to provide security to the system, will also amend the reference count; and when it thinks the control is done with the object, it will decrement that count in turn. So if the control had any other plans for the object, it has to add its own reference count to the same object.

To make a (very) long story short, there often ends up being more pointers to the object than there are objects. And with medium-level privilege, those pointers can theoretically be exploited.

The case-in-point involves those nasty variants. Adding references to objects in memory often involves copying the objects themselves; and in the case of variants, there's a special function for that. But to know to use that special function, marshaling code would have to be aware that the objects being copied and re-referenced are variants; so instead, they resort to the tried-and-true memcpy() library function. That function is capable of copying the complex object, but in such a "shallow" way that it doesn't give a whit about whether the contents of the complex object are complex objects in themselves -- and since memcpy() predates COM by a few decades, it doesn't increment the reference count for new instances of included objects that are created in the process. A pointer to the new object exists, of course, but not the reference that COM requires.

So an ordinary memory cleanup routine could clean up the contents of the duplicated contained object, even though a component has designs on using that object later. As the group writes, "If the variant contains any sort of complex object, such as an IDispatch [a common COM object], a pointer to the object will be duplicated and utilized without adding an additional reference to the object. If the result of this duplicated variant is retained, the object being pointed to could be deleted, if every other instance of that object is released."

There are a multitude of similar examples in this research paper of essentially the same principle in action: a principle that points to a fundamental flaw in the way COM objects have been secured up to now. The Hustle Labs team takes Microsoft to task only at one point in the paper, and quite gently, for implementing Patch Tuesday fixes that tend to resort to using "killbits" in the Registry for turning off COM components and ActiveX controls impacted by this kind of vulnerability, instead of reworking the marshaling code to address the problem at a fundamental level.

So today's round of Patch Tuesday releases may go into more detail than just resorting to killbits -- in a few situations this week, new patches actually go into further depth at patching problems that were said to have been patched already, including with the GDI+ library. But it's an indication that independent researchers with conscientious goals are truly getting through.