Betanews - Security

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

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

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.

Swedish ISP wins appeal in biggest test to date of EU anti-piracy law

Scott M. Fulton, III — Tue, 13 Oct 2009 15:54:11 -0400

By Scott M. Fulton, III, Betanews

Last March, the European Commission voted to enact a continent-wide law compelling member countries to take bolder steps to enforce their own copyright infringement laws. One of the more controversial provisions of the Intellectual Property Rights Enforcement Directive (IPRED) has been to allow rights holders to petition member states' governments to act on their behalf. That provision has emboldened some rights holders and associations to act as evidence gatherers; and in Sweden, their right to do so was put to the test.

A group representing five publishers of audiobooks in Sweden were judged to be entitled to the identity of a single file-sharer. In a June decision, a district court in Solna ordered ISP ePhone to turn over the name of the file-sharer. It refused, and was forced in September to pay a fine of 750,000 kronor (about $107,400), one-tenth of which was to go to the publishers.

While the publishers did not have the complete identity of the unauthorized file-sharer, they knew that he/she existed. Acting under what they had described as the authority granted them by IPRED, someone representing the association hacked into ePhone's records to obtain the single IP address to which the unauthorized downloads were associated, according to ePhone. The district court ruled that the association had "probable cause" to investigate ePhone's records in the manner it did, applying language that's usually reserved for federally sanctioned investigative bodies.

The 750,000 SEK fine was of some concern to ISPs throughout the country because of the precedent it might set: In keeping with a separate EC privacy directive, ISPs had been destroying their retained data on users and their online destinations after six months, if not sooner. The ruling of the Solna court appeared to threaten those same ISPs with sizable fines for...well, there's no other way of saying this...permanently destroying such data in such a way that it could not be un-destroyed.

But in a 2-2 decision yesterday whose split was decided by the presiding judge, the Svea Court of Appeal -- as reported by Sweden's English-language daily The Local -- overturned the Solna court's decision, saying no such probable cause existed. As it turned out, since the audiobooks in question were only accessible through a private login, the association had no basis for arguing that its products were widely available "to the public," the presiding judge ruled.

The Local quotes ePhone CEO Bo Wigstrand as saying after the trial's conclusion, "After all that's been written that we should have released the information, it actually feels really nice that the court has ended up agreeing with what we've said the whole time: that the evidence wasn't good enough." Meanwhile, a spokesperson for the association expressed shame for the appeals court's decision, saying it "really complicates" its ongoing investigations.

Typo blamed for country-wide Web site blackout in Sweden

Scott M. Fulton, III — Tue, 13 Oct 2009 15:06:46 -0400

By Scott M. Fulton, III, Betanews

If the script that updates your DNS records for a zone leaves off the trailing period for each record, the DNS server can't properly attach the top-level domain name. That little tip is probably permanently etched onto the head of an administrator somewhere at Sweden's Internet Infrastructure Foundation. Late yesterday evening, that single omitted period caused Web sites with Sweden's .se TLD to be inaccessible for at least one hour, with some perhaps remaining inaccessible until the following evening before downstream routers refresh their caches.

A security bulletin issued by the Foundation this morning advises administrators noticing difficulties with accessing .se sites to use BIND 9.2.0's rndc flush command to clear memory of cached data prior to a reload. The firm issued a new zone file shortly after the incident, although it admitted it refrained from going through the usual security steps to clear the zone file since .se sites remained inaccessible. A new, fully cleared zone file has since been issued.

Some ISPs, a spokesperson for the .SE foundation told Sweden's English-language daily The Local, may take two days or longer to fix the issue on their sides of the Internet. Larger ISPs such as TeliaSonera and Bredbandsbolaget report having already instituted the fix.

Evidently the problem did not impact copyright violation powerhouse The Pirate Bay, whose .se domain name defaults to its principal Web site with a .org TLD.

Why is John Hodgman smiling? Data loss isn't the only Snow Leopard problem

Scott M. Fulton, III — Tue, 13 Oct 2009 12:04:56 -0400

By Scott M. Fulton, III, Betanews

If Snow Leopard, the latest version of the Mac operating system released late last August, were seriously plagued with bugs, writes a volunteer contributor to Apple's discussion forum, the company would be besieged with complaints. But that may very well be the problem, as evidenced by this screenshot from a Snow Leopard user who attempted to formally report his problem to Apple through his operating system, and was met with this message: "An error has occurred. Please report the error to Apple Inc. by emailing the error detail to devbugs@apple.com."

As the user reported on Apple's forum, "I'd laugh if I wasn't in an apoplectic rage."

Apple has reportedly acknowledged the existence of a critical data loss error affecting numerous Snow Leopard users, although the company actually has yet to release a complete statement on the issue. As a result, The Unofficial Apple Weblog has resorted to taking a reader poll, asking readers when they believe Apple can fully resolve this issue for release 10.6.2 (developer builds for which are now being distributed). About a quarter of TUAW's readers are confident Apple can roll things up by the week of October 26.

As this situation continues to develop, there is now one big issue and at least three subsidiary issues that branch from it. The main problem concerns the apparent fact that Snow Leopard is deleting the wrong data when exiting a Guest account.

In Mac OS X, the Guest account was devised as a convenient way for a non-authorized user to be able to use the computer with limited privileges, in such a way that no permanent changes or extra files remain when the user logs off. But since Snow Leopard's release, a growing number of users are discovering that the system is deleting the wrong account: Their main user accounts are missing, along with most of the data stored under those accounts.

Why this problem was not discovered during testing (assuming testing even occurred) is baffling. In the absence of raw data from Apple to help users resolve or avoid the issue, once again, Mac users are left with independent sources and volunteer contributors to Apple's forums to help them out.

Based on what those folks have been able to compile, here is what we've been able to assemble thus far: The problem seems to be concentrated among users who have upgraded to version 10.6.1 from earlier versions. The theory there is that the format of the existing Guest account may not have been upgraded to conform to the new version of the operating system.

Mac users who upgraded to version 10.5 Leopard once before noticed something unusual in the same category, but not as destructive: After upgrading, their main accounts' home directories appeared to be missing. It turns out that they were only moved to a temporary location, and that the upgrade process for some neglected to relocate contents from the /home-preserved directory that Leopard created and the new /home directory. It took a little prestidigitation for users to resolve that problem, but in that case, data was not lost.

But the existence of the problem itself suggests that Apple is changing the structure of user accounts with new releases (which is a likely reason why Leopard would have been relocating user's files in the first place). Theoretically, code that was designed from the ground up to handle a new account structure may be disrupting the old one, in situations where the upgrade process to Snow Leopard failed to make the appropriate change -- as appears to be the case with the Guest account.

The three subsidiary issues arising in the wake of the Guest account problem are, in and of themselves, quite serious, though in terms of possible damage they pale by comparison. First, users who are genuinely trying to restore their data using Time Machine, Apple's built-in backup utility, are discovering it didn't back up their complete contents. According to one Web developer's report, Web pages associated with users' accounts do not appear to have been restored, and were probably not backed up to begin with.

A second issue that's probably unrelated technically is being given extra weight with regard to Snow Leopard's other problems: Users of the Mac's Airport wireless devices are reporting continually dropped connections only since having upgraded to Snow Leopard. Several volunteers have suggested any number of solutions including upgrading router firmware and changing the format of security keys to something stronger, but no solution seems permanent.

What may relate this issue to the bigger issue of account deletion, if anything, is this one common thread: Folks who believe their solution is fixed (their Airport stops dropping connections) only come to discover the problem un-fixes itself after their machine is powered down or hibernated. As one afflicted Mac user writes, "Something tells me that Airport just isn't meant to be cycled off and on numerous times a day to reestablish a connection."

Another potentially common thread has to do with external hard drives, many of which are connected using Airport. Many Snow Leopard upgraders are reporting they cannot launch their Finder application for these drives -- specifically, they're receiving a message that reads, "The application Finder.app can't be opened - 10810."

Some users report being able to reconnect to their external drives and launch Finder, but only after uninstalling whatever drive they're using for their continual Time Machine backup. And once again, in cases where users appear to have found solutions, their fixes mysteriously disappear after having powered down or hibernated their systems. "Now have the choice of no Finder or no backup," writes one user. "We need an answer from Apple."

As with other cases in the past, we're seeing some independent contributors to Apple's forums who respond to complaints by coming to Apple's rescue. For example, some contributors have now taken to responding to demands that Apple issue a solution to the Guest account debacle by citing Apple's EULA, specifically the section headed, "9. Limitation of Liability."

That's the section that states that by using the Mac in the first place, you agree that Apple cannot possibly harm you with serious intent. The section reads, in part, "In no event shall Apple's total liability to you for all damages (other than as may be required by applicable law in cases involving personal injury) exceed the amount of fifty dollars ($50.00). The foregoing limitations will apply even if the above stated remedy fails of its essential purpose."

One can imagine Justin Long seated behind a desk in front of a queue full of complaining users, and passing out fifties.

But throughout the Apple forums, perhaps for the first time, there appears to be a split in the ranks, where not everyone is rushing to the company's defense as if it's the one being damaged. One user bit by both the Guest account and Time Machine problem reported she had grown so comfortable with the idea of just having a Mac that she never really thought she'd have to learn about using it to the extent she has in the past few weeks.

And another user, in exasperation after being bitten by "Error 10810" for the last time, simply shouted, "This is Mac for God's sake!"

Danger signs: Now how secure does the cloud look?

Carmi Levy — Mon, 12 Oct 2009 17:57:06 -0400

By Carmi Levy, Betanews

There are service outages, and then there are service outages. T-Mobile customers who carry the Sidekick smartphone are learning the hard way that there's a major difference between having no access to a service for a little while and losing every contact, calendar entry, and related shred of personal data they've got.

In the not too distant past, Google, Twitter, and Facebook have all experienced basic, quaintly simple service outages. Despite the headlines and general chaos associated with each incident, the bottom line impact was never all that onerous: When service returned, so did their users' data. For the most part, users were given an easy excuse to take a few hours off. And with the exception of Google's subscription services, most were free, so folks couldn't argue that they weren't getting their money's worth.

More than a free service

Microsoft's experience isn't turning out as charmed, and it wouldn't surprise me if some of the folks behind its 2008 purchase of Sidekick maker Danger might be rethinking the $500 million deal in the wake of last week's worse-than-usual outage. When service was restored and countless users (Microsoft and T-Mobile still aren't fessing up to actual numbers) realized their devices had been wiped clean, Microsoft was forced to release an unprecedented mea culpa admitting data had been lost and would in all likelihood not be recovered. More embarrassing for the companies involved, Microsoft implored users to keep their batteries in place and avoid resetting their devices or allowing them to lose power.

However you slice it, this is not a happy place for anyone. While it's easy to assume Microsoft's and T-Mobile's customers are the real victims here, the sad truth is these very clients shoulder at least part of the blame for losing their stuff. It may sound harsh, but users who rely so heavily on a vendor that they neglect to implement their own disaster recovery plan shouldn't complain too loudly when said vendor drops the ball. Although in this case Microsoft and T-Mobile were accountable for the service itself, data ownership always resides with the customer. While the peculiarities of the Sidekick dictate that much of the data resides in the cloud, end users remain ultimately accountable for their information.

Sadly, many of them are learning a hard lesson about the value of local syncing. Whatever mobile device or OS you're using, this should be a wakeup call if you're not doing the same.

A cloudy question

This debacle doesn't just force this particular service into question. More ominously, it challenges the very notion of cloud-based services at a time when their takeup rate is accelerating. The fundamental trust that we have in such services -- that a provider that specializes in large-scale deployments like this could absolutely never lose our precious data -- has been thrown into question. Suddenly, keeping things stored on our rickety old hard drives, or at least backing them up there, may not seem like such a bad idea. Any way you slice it, it's a backward step in the march toward the cloud.

To its credit, Microsoft is doing everything it can to make the best of an unfortunate situation. It's apologized for losing customer information, it's scrambling to recover what it can, and it's offering up a free month of data service. While customers who have lost it all may disagree, this is a textbook response to this kind of situation. And as the vendors involved strive to save whatever face they can, it's fair for current and prospective customers to feel burned by a service whose monthly subscription fees implied a certain trust relationship. More than a free service like Twitter, which when it inevitably goes dark users can simply shrug their shoulders in response because they're simply getting what they've paid for (namely, nothing), a service like T-Mobile's that comes with a monthly bill can't simply rely on shoulder-shrugging users when the worst happens.

[Original photograph by Carmi Levy]

A case of bad timing

All this must weight heavily on Microsoft as it prepares to release its core cloud-based environment, Windows Azure Platform. While Microsoft was hardly involved in the architecture decisions made years before it acquired the Danger unit, the brand association is anything but positive as Microsoft takes its biggest step yet toward a Web-enabled services model. Convincing customers still comfortable with the notion of physical servers in tangible data centers that they should toss their data into infrastructure owned and managed by some unseen entity just got a lot harder.

Google, Salesforce.com, and other cloud-based vendors -- free or not -- are doubtless also feeling Microsoft's pain, because they all know full well that this kind of thing can happen to them, too. The industry clearly has a long road ahead of it as it seeks to balance the compelling capital and operational advantages of Web services with the never-ending need for customers to take an active role in securing their data.

That road will be difficult indeed if vendors ignore the need for this form of partnership. Despite their passion for making their new generation of Web-based services as worry-free as they possibly can, no amount of technology can ever remove the need for personal and corporate accountability from the equation. Vendors that market themselves as the answer for customers who can't be bothered to pay attention to their own data need a not-so-slight attitude adjustment.

For their part, customers also need to begin challenging cloud-based services vendors with specific questions revolving around how data is secured, backed up, and restored. Before signing on the dotted line, they should ask about what tools and processes the vendor makes available for customers to self-serve their own backups. Even if it's as simple as a basic export to a .CSV file, with the right support from their vendors, customers can set up automated processes that ensure they can keep going even if the service itself does not.

Vendors that don't help customers help themselves will be quickly eclipsed by those that do. And when the worst happens and a vendor-caused meltdown takes data with it, customers that don't step up to the plate will have no one to blame but themselves. Welcome to the new reality of the cloud.

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.

Yet another case for backing up your data: Snow Leopard

Tim Conneally — Mon, 12 Oct 2009 17:50:51 -0400

By Tim Conneally, Betanews

Apparently not only are Sidekick users losing their personal data. Now, in a separate incident, Snow Leopard (OS X 10.6) users are also finding their data fully wiped.

The bug was actually discovered within a week of Snow Leopard's launch back in August, when users found that logging out of their account, into a "guest" account, and then back into their personal account would completely erase the content from their home drive (Documents, Movies, Pictures, Music, Sites).

Though the bug is now more than a month old, it's still claiming victims, as Apple's support forums show. However, Apple has yet to acknowledge the issue and the aforesaid conditions do not faithfully reproduce the bug.

The issue is thought to only affect users who had active guest accounts in Leopard (Mac OS X 10.5), and the only workaround currently is to disable guest login altogether.

Users who have succumbed to the bug are likely to permanently lose their data unless they have performed a backup, so users who have guest accounts and upgraded to Snow Leopard from Leopard are advised to back up their data immediately. Users with Time Machine running simply need to hold down the "C" key when booting their Mac, and then selecting Utilities > Restore from Backup in the event that this bug eliminates their data.

Fake entries in new e-mail/password lists point to unsophisticated phishing

Scott M. Fulton, III — Wed, 07 Oct 2009 11:47:07 -0400

By Scott M. Fulton, III, Betanews

If last weekend's unsolicited posting of about 10,000 supposed Hotmail addresses and passwords to a legitimate developers' Web site did not contain some addresses that were fake, the theory that a hacker may have obtained those addresses through an attack on Microsoft's servers might continue to hold water. That theory lost ground today, after more addresses from major services other than Hotmail -- including Gmail, Yahoo, AOL, Earthlink, and Comcast -- appeared without warrant on Pastebin.com, a site for developers to share debugging information.

In what could be the first publicly shared forensic report on the original Hotmail list, security researcher Bogdan Calin with server security software maker Acunetix reported that of the 10,028 entries that appeared in that list (which was apparently partial, including usernames that only began with A and B), 185 of the entries actually had blank passwords. That in and of itself could not have come from a server's own list of valid passwords, thus lending much credence to the theory that the responses came from a phishing scam.

But not a very sophisticated one, Calin goes on. Without revealing information that would have compromised anyone in particular, he reported that the most commonly repeated passwords he saw in the list, coupled with the nature of the remaining passwords, leads him to conclude that they were obtained from members of the Hispanic community. The password alejandra, for example, appeared 11 times in the list -- once more than 111111 -- and alejandro appeared 9 times.

From time to time, many sequences of password characters appear almost repeated, except with varying capitalization. "What most probably happened, is that the users didn't understand what was happening, and they tried to enter the same password again and again, thinking the password was wrong," Calin wrote. An unsophisticated phisher might have accepted every attempt at repeating a password in sequence; meanwhile, the unsuspecting victim is trying to log in, thinking, "Didn't I capitalize the O?"

Paul Dixon, who maintains Pastebin.com, told the press yesterday he's had to take his site down to address the problem more directly, saying, "Pastebin.com is just a fun side project for me, and today it's not fun." This morning, the site was operational.

Though Dixon's site bears a strong resemblance to Pastebin.org, which has the exact same purpose, users of the latter site -- which was not involved in the list-posting incident -- began complaining to Dixon last month about problems they were having with that site, not knowing the two were not connected. In a blog post at the time, Dixon wrote that Pastebin.org "seems to have been compromised in other ways, with extra advertising banners and popups...I'm not responsible for that site."

Possible confusion over the two sites' identities could play into the motive for the unknown party posting these apparent phishing entries onto a site that otherwise has perfectly legitimate purposes.

As of yet, there is no evidence that anyone -- the original poster or any downloaders -- has attempted to use any of the partial lists posted to Pastebin.com in a security compromise operation directed at password holders. However, the possibility exists that these lists were posted as evidence of the existence of more complete lists, for inspection by underground sources willing to bid for them. After Bogdan Calin's analysis, the bidding may not be all that high.

Microsoft acknowledges Live ID accounts breach

Scott M. Fulton, III — Tue, 06 Oct 2009 10:29:25 -0400

By Scott M. Fulton, III, Betanews

Yesterday, Neowin's Tom Warren discovered a list of what appeared to be Windows Live Hotmail account credentials, posted last weekend to a location where you wouldn't expect such a list to appear: a collaborative debugging code sharing site for low-level software developers called pastebin.com. Warren reported the news to the world at the same time he reported it to Microsoft.

Still, Microsoft acknowledged the problem late yesterday, but attributed the source of the problem to "a likely phishing scheme." If such a scheme does exist, then its first victim today was poor pastebin.com, whose proprietor Paul Dixon (LordElph) was forced to take the site offline due to the sudden surge of activity.

"Pastebin was created as a tool to aid software development, not to distribute this sort of material," Dixon wrote today, on a blog which itself has seen so much activity that its page refreshes were agonizingly slow. "As a result of the interest this story is generating, pastebin.com is experiencing huge levels of activity -- as a result I've taken it offline while I ensure all the offending material has been removed, and that the abuse filters prevent re-occurrence."

Members of the site offered support; one member offered to mirror pastebin's legitimate content to help ease the load. As of this morning, the site was only occasionally visible.

Individuals who saw the list reported that it appeared to contain the first 10,028 username/password combinations in a much longer list, sorted alphabetically. Only usernames beginning with A and parts of B were shown.

Microsoft's take on the incident is that it was probably a demonstration by someone who had acquired the credentials by way of a phishing scheme -- for example, a fake message that appears to be from Microsoft or a partner that asks users to "sign in using your Windows Live ID" to gain access to an e-mail solicitation. The other possibility -- one which Microsoft did not raise -- is that the list was obtained by a hacker who was able to snag servers into spilling the list through some administrator-level command or script.

In either event, Microsoft is taking the easier approach for mitigation: advising Live ID users to change their passwords, and to continue to do so every 90 days.

Single point of failure blamed for Verizon FiOS, DSL outage

Scott M. Fulton, III — Mon, 05 Oct 2009 11:15:39 -0400

By Scott M. Fulton, III, Betanews

A single stalled router is being blamed by Verizon officials for a service outage that impacted customers of its high-speed Internet service, including fiberoptic FiOS, in New York and Massachusetts.

The outage occurred at approximately 3:15 pm EDT, according to a message Friday afternoon from the company's chief PR executive, Eric Rabe. He acknowledged that routers typically fail over to adjacent ones, but in this instance, this one didn't.

"The router went into a hung state and did not appear to the rest of the network as though it was having problems," Rabe wrote, being careful not to name the manufacturer.

According to reporting from Telephony Online's Ed Gubbins, Verizon's principal hardware provider for FiOS is Juniper Networks. In fact, Gubbins reports, Verizon contributes 13% of Juniper's total revenue, and may be the sole reason why that company found black ink again last year.

Juniper's E-series routers service Verizon's broadband network. Last October, Juniper announced a major upgrade to its routers' operating system, adding features that included the capability for service providers to deploy deep packet inspection -- the ability to analyze Internet traffic based on its contents. The company marketed this feature as part of its "Intelligent Services Edge" portfolio, which it described as "leverag[-ing] a single, consistent operating system and high-performance hardware to flexibly deliver many service types -- including broadband routing, voice, multimedia and integrated security, as well as application-level awareness."

The rollout schedule for these changes targeted the third quarter of 2009. The latest version of Juniper's router software for E-series routers, called JUNOSe, began rollout on August 13. While the evidence that Juniper's router software may have been involved is circumstantial, these facts do tell a curious tale.

As some customers confirmed to Verizon's support forum, Rabe's statement that the outage lasted about 40 minutes on Friday afternoon appears accurate. However, other customers, including in Massachusetts, reported poor or no service even after the problem was resolved by 4:00 pm. What's more, support representatives who diligently worked with customers in an attempt to resolve issues as if their own on-premise equipment were to blame, were apparently not informed of the service outage themselves until after the problem was resolved. One heavy-use customer complained to Verizon, "I have 30 years in networking designing service provider networks and I don't have a single design that has a single point of failure. It appears Verizon does."

That provoked another customer to come to Verizon's defense: "Even with redundancy, there is no way to guarantee 100% availability. That is an impossibility, I don't care who you are. And that percentage is including regularly scheduled failover testing."