Google Chrome Updated

September 24, 2010

Google has released a new version, 6.0.472.63, of its Chrome web browser for the stable and beta channels, for all platforms.  This version corrects a bug in  V8, the JavaScript engine; it does not appear to have any security implications.  Details are in the release announcement on the Chrome Releases Blog.

As usual, you can get the new version via the built-in update mechanism; Linux users should find the updated package via the normal package maintenance tools.

More on Stuxnet

September 23, 2010

Yesterday, I wrote about the sophistication of the Stuxnet worm, as revealed by analysis of its code.  Stuxnet is unusual, in part, because it contained exploits directed at a number of different vulnerabilities in Microsoft Windows.

An article on the ThreatPost blog at the security firm Kaspersky Labs reports an interesting wrinkle in this story.  It appears that one of the vulnerabilities targeted by Stuxnet, the print spooler flaw fixed by Microsoft this month in Security Bulletin MS10-061, was reported over a year earlier in a Polish security magazine.

it now appears that information about the flaw was in the public domain for more than a year before Stuxnet first appeared,buried in the pages of Hakin9, a respected bimonthly magazine published out of Warsaw, Poland. An article by security researcher Carsten Köhler describes how shared network printer functionality on Windows can be used to elevate the local user’s privileges or to gain command line access to network print servers.

According to the article, Microsoft has confirmed that the hole identified by Köhler is the same one patched in MS10-061 this month.

It’s interesting that, although the Stuxnet worm appeared a few months before Microsoft patched the vulnerability, it wasn’t launched for some time after the original article identifying the flaw appeared in 2009.  This seems consistent with the idea that the worm was not just a random act of malice, but was developed to serve a specific purpose.

Update Friday, September 24, 22:20 EDT

The “Threat Level” blog  at Wired has another interesting article on Stuxnet, with more speculation on who might have created the worm, and what its target might be (or have been).   The Internet Storm Center at the SANS Institute also has a diary entry on Stuxnet, by John Bambenek.

Sophisticated Stuxnet

September 22, 2010

Last summer, a new example of computer malware showed up, spread initially by infected USB drives.  It was initially noticed in June, and gained more notice in July when Microsoft issued a Security Advisory (2286198) about the exploited vulnerability, which  was caused by a flaw in the way .LNK files were processed.  The original advisory also indicated that the malware, called Stuxnet, appeared to target industrial control and SCADA systems.   Microsoft subsequently issued a Security Bulletin (MS10-046), with an out-of-schedule patch for the the flaw, on August 2.

Computer World now has a report on some further analysis of Stuxnet that has been carried out by Kaspersky Labs and by Symantec.  It turns out that the Stuxnet worm is considerably more sophisticated than was first thought.  In addition to the .LNK vulnerability that was initially recognized, the program has exploits built in for three other Windows vulnerabilities.  One of these, in the print spooler, was patched by Microsoft in its monthly security update on Tuesday, September 14.  The other two vulnerabilities, classed as “elevation of privilege” flaws, will be fixed in a future release.   The worm also incorporates an exploit for an older vulnerability in Windows, patched in 2008.  Both security firms said that Stuxnet showed a much higher level of sophistication than typical Internet malware.

The Stuxnet worm is a “groundbreaking” piece of malware so devious in its use of unpatched vulnerabilities, so sophisticated in its multipronged approach, that the security researchers who tore it apart believe it may be the work of state-backed professionals.

“It’s amazing, really, the resources that went into this worm,” said Liam O Murchu, manager of operations with Symantec’s security response team.

“I’d call it groundbreaking,” said Roel Schouwenberg, a senior antivirus researcher at Kaspersky Lab.

The worm managed to pass undetected for at least a few months, helped by the fact that it included two stolen digital certificates.  As Microsoft originally indicated, the worm specifically targeted SCADA systems, specifically the WinCC and PCS 7 SCADA management programs, associated with equipment manufactured by Siemens.

An article in the Christian Science Monitor suggests an even more disturbing possibility: that Stuxnet is not just an espionage device, or malware in the usual sense, but is intended to be a weapon.

The cyber worm, called Stuxnet, has been the object of intense study since its detection in June. As more has become known about it, alarm about its capabilities and purpose have grown. Some top cyber security experts now say Stuxnet’s arrival heralds something blindingly new: a cyber weapon created to cross from the digital realm to the physical world – to destroy something.

By August, researchers had found something more disturbing: Stuxnet appeared to be able to take control of the automated factory control systems it had infected – and do whatever it was programmed to do with them.

The first in-depth analysis of the worm was carried out by a German researcher, Ralph Langner, and is posted on his Web site.  According to the Monitor article, his findings have subsequently been confirmed by other security researchers.

Since reverse engineering chunks of Stuxnet’s massive code, senior US cyber security experts confirm what Mr. Langner, the German researcher, told the Monitor: Stuxnet is essentially a precision, military-grade cyber missile deployed early last year to seek out and destroy one real-world target of high importance – a target still unknown.

The article also suggests that Iran’s Bushehr nuclear reactor may have been the intended target, although the evidence for this is sketchy.

Regardless of its target, Stuxnet represents another step in the evolution of computer malware.  As I have noted before, we have for some time been seeing malware that is not the work of bored adolescents, but is directed toward specific criminal activity.  Stuxnet, whether created by an agency of a national government or someone else, represents another escalation in the arms race between the malware writers and system defenders.  It is not a reassuring development.

Added Security: Cheap and Cheerful

September 21, 2010

There’s been a fair amount of discussion about Google’s move to improve security for Google Apps (which I wrote about yesterday) by introducing a form of two-factor authentication.   The general consensus seems to be that, although there are various potential problems, as with any security scheme, on the whole this is a positive step.

One of the more interesting responses is a diary entry by Johannes Ulrich of the SANS Institute, at the Internet Storm Center.  He talks a bit about Google’s offering, and compares it some other methods of two-factor authentication.  One “traditional” approach, which I have used, gives each user a small electronic “token” that generates a one-time authentication code, either via a challenge-response protocol, or a clock-based generator.  (RSA Data Security, now a part of EMC, makes a SecurID token that is an example of this technology.)  The primary disadvantage of this method is cost; as Ullrich says, it works out to something like $50 per user, or perhaps more.

Ullrich describes some alternative methods of getting two-factor authentication “on the cheap”.  One of these, which is used in the Google offering, is sending the user a one-time access code by means of an SMS message to the user’s cell phone.  Another, also part of Google’s system, uses a software application on a mobile device as a token.  There are potential drawbacks to both of these: for example, SMS messages are not necessarily reliable, and will not work if there is no cellular service available at a particular location.

Ullrich also describes a decidedly low-tech solution: providing each user with a pre-printed list of one-time passwords, which are crossed off as they are used.  (I’ve used this technique in the past for very sensitive accounts.)  This method has its problems, too, of course.   For one thing, it puts one in the key distribution business, with the same problems as one-time pad cryptography.  The user must be very careful not to lose the list, or leave it lying around, since it can be “hacked” with a copying machine.  Nonetheless, it illustrates an important point: careful thought about the environment and the threat landscape means much more, in security terms, than whiz-bang technology.

Google Apps Get Added Security

September 20, 2010

One of the practical manifestations of the recent flurry of interest in “cloud computing” is the adoption, by at least some organizations, of the Google Apps platform for E-mail, calendar and document sharing, and other “cloud” services.  One of the frequently expressed concerns about cloud services in general has been security: some managements are made very nervous (not without some justification) by the idea of their confidential data not being under their control.  One set of worries has to do with the data being physically in someone else’s data center; another centers on how well the access controls on the data — which, after all, is in principle accessible from anywhere on the Internet — will work.

As reported in an article at Ars Technica, Google today announced the availability of additional security measures for its Google Apps customers (which, according to a post on the official Google blog, now number more than 3 million) to address the second class of concerns.  Customers may now choose to enable an additional layer of security verification: in addition to a user ID and password, the new system will require the user to enter a six-digit code sent to the user’s mobile phone.  This covers two items of the security trinity: something you know (the password), and something you have (the mobile device).   The system, which is described in more detail in a post on the Google Enterprise Blog, also will enable certain devices to be designated as trusted, meaning that the two-factor authentication will not be required.  (One might use this, for example, for devices on a local wired network.)

Google says that the new security measures are available now for customers of its Premier, Education, and Government Editions of Google Apps, and that it plans to eventually make the system available to all users.

This seems to me to be a useful step forward in the attempt to provide better security for Internet applications.  There is no perfect system, of course, but this makes life a bit more difficult for the potential shoulder surfer or password sniffer.  But it is also predictable that some users will manage to mess it up.  If you’re planning to enable this feature, have you sent out the “Don’t keep your cellphone in your laptop bag!” memo yet?

Adobe Releases Updated Flash Player

September 20, 2010

As expected, Adobe today released an updated version of its Flash Player, which incorporates a fix for the recently discovered security vulnerability.   The new version,, is available for Mac OS X, Windows, Linux, and Solaris.  There is also a new version,, for the Android platform.  Further details are in the Adobe Security Bulletin [APSB 10-22].

If you are using a browser other than Internet Explorer on Windows, you may need to get two updates: one for your “other” browser (e.g., Firefox, Safari), and one for IE.

If you are using Google’s Chrome browser, the most recent version, 6.0.472.62, has this update included.

You can get the new version via the built-in updating mechanism, or from the download page.  I recommend installing this update as soon as you can.  The Flash Player is very widely installed across all platforms, which makes it a tempting target for the Bad Guys.

Adobe to Patch Flash Monday

September 19, 2010

Adobe has updated their Security Advisory [APSA 10-03] on the recently-discovered Flash Player vulnerability, indicating that they expect to release an update that fixes the flaw on Monday, September 20.  The patched version will be available for all platforms: Windows, Linux, Solaris, Mac OS X, and Android.

Google’s Chrome browser incorporates a bundled version of Flash Player; if you have updated to the latest version, Chrome 6.0.472.62, the patch for Flash is already included.

%d bloggers like this: