The Duo battery chargers for NiMH batteries are safe, but the software that enables the user to monitor the batteries is infected, PC World reported Monday.

The infected software includes a “backdoor” that allows some computer files to be to be remotely controlled, PC World said.

The trouble begins if the consumer downloads Windows software from the Energizer company website If this was not done or if the consumer uses a Macintosh computer, consumer files are safe.

Consumers were advised to uninstall the infected software, reboot the computers and then go to the System32 directory in Windows. There, consumers were advised to delete “arucer.dll,” the file that is the actual backdoor, PC World said.

Energizer has discontinued the software, but you can still buy the DUO at Amazon for about $20.

Most people probably just shrugged their shoulders at the news, but it’s yet another blemish against the company’s security record. This isn’t the first time Facebook has run into security issues, and I’ve grown increasingly concerned that the company might be playing fast and loose with its quality assurance policies because it doesn’t want to sacrifice the rapid iteration it’s famous for.  With this in mind, I reached out to Facebook late last week to ask about their protocol for deploying code and how the bug made it through in the first place. The company responded to some of my questions, and refused to answer others.

At least, Facebook eventually answered some of my questions. At first, the company sent me a vague statement reiterating that they were investigating the issue, and that they “maintain industry-leading quality assurance and security systems, and the reliability of Facebook is our top priority.”

In response, I reminded the Facebook spokesperson that it had just sent thousands of messages to people who weren’t meant to receive them, which would seem to indicate that it is not, in fact, on the bleeding edge of online security. I restated my questions and the company got back to me with this more detailed overview of its QA and code deployment policies, found below. Note that it begins with a general statement Facebook provided, along with more direct answers to my questions (which are in bold).

Facebook hires the most qualified and highly-skilled engineers we can find – most from industry or from top universities. Upon joining the company, every engineer and engineering manager participates in a six-week intensive ‘boot camp’ training. Our code review process is rigorous, and we phase out changes and test them before they go live for real users to detect any potential issues. During code pushes, our engineering, user support, and operations teams work cross-functionally to monitor the state of the push and to identify any problems early. We also have the capability to quickly push code updates to all of our datacenters worldwide, and to enable or disable critical features of the site if there is a problem.

All of these checks worked together on Wednesday, as designed, to limit the impact of the error and stopped it within minutes. We were able to swiftly disable access to the users who received messages and remove those messages from Facebook, although we were unable to prevent email notifications from being sent to affected users. It is important to recognize that no system is perfect and no company avoids mistakes all of the time. However, we would like to take this opportunity to sincerely apologize to all affected users and ensure them that we are committed to investigating Wednesday’s issue and to learning from it.

What are your protocols for pushing code?

We have staged rollout changes that go through multiple phases before going to end users, so we can proactively detect any problems. As the changes get rolled out to users, a set of support, engineering, and operation leaders are actively engaged to monitor the state of the push. As soon as any issue is identified, we have multiple tools to quickly disable critical features. The combination of these mechanisms dramatically limited the exposure related to Wednesday’s issue.

Are there multiple people reviewing all code that gets pushed?

Yes, we have a rigorous code review process and no code goes live on the site unless it has been reviewed and approved by a skilled engineer.

What changes are you making to ensure that this does not happen again?

We cannot discuss specific improvements, but we take privacy and security very seriously and are continually improving our code standards, processes, and systems to help us build high quality products quickly.

When do you expect to conclude your investigation, because I will certainly be following up for the details about it?

As a general practice, we do not comment on investigations like this.

While interesting, none of this is particularly surprising. And because Facebook isn’t commenting on the outcome of the investigation, we’ll probably never find out what caused the bug (or if company protocol was even followed in this case).  But hey, at least they saythey’re doing the right things.

It’s worth pointing out that Facebook is by no means the only company affected by such issues.  Last year, I wrote a post called the Sorry State of Online Privacy, where I detailed some of the security lapses that had hit Facebook, Twitter, and Google (and of course there’s the recent Google Buzz fiasco). All of these companies would likely claim to have state of the art testing and security measures, yet such problems seem to pop up every few months.  I’m aware that it’s impossible to have a fully secure system, but that doesn’t mean engineering teams should be treating these problems as inevitabilities.  To reiterate what I wrote last year, the word ‘private’ should not mean “this will remain hidden until we accidentally break something”.

[via TechCrunch]

The vulnerability affects Windows 2000, XP and Server 2003-based systems, Microsoft said in a security advisory dated March 1.

Microsoft said that the vulnerability in VBScript could allow remote code execution of computers. “If a malicious Web site displayed a specially crafted dialog box and a user pressed the F1 key, arbitrary code could be executed in the security context of the currently logged-on user,” Microsoft said on its Web site, “On systems running Windows Server 2003, Internet Explorer Enhanced Security Configuration is enabled by default, which helps to mitigate against this issue.” Windows Vista, Windows 7, and Windows Server 2008 are not affected.

The advisory includes several workarounds, including advice to avoid pressing the F1 key when prompted by a Web site.

It also suggests restricting access to the Windows Help System, setting Internet and Local intranet security zone settings to “high” to block ActiveX Controls and Active Scripting, and configuring Internet Explorer to prompt before running Active Scripting or disable Active Scripting in the Internet and Local intranet security zone.

Microsoft complained in its advisory and a statement that the vulnerability was not responsibly disclosed.

Two days was all it took to Sony engineers to solve the problem of time that affected some models of the PS3. A concern due to the passage of the month from February to March and that has prevented some users from connecting to the PlayStation Network on Sunday and Monday. This bug has been identified as the older model PS3 (called Fat) and does not cover PS3 Slim sold since September 2009.

On its blog, Sony states that if, on consoles impacted by this bug, the date does not always gets updated automatically, you can now force it manually or via the Internet. The Japanese company also said that if it has new elements to correct any other recurring concerns, it will update the console via the web to solve them. Evidence that the connection problems are only the past now.

I’ve worked at places and with developers that see the QA Team as a nuisance. Constantly interrupting with bug issues when you’re just trying to move on to the next step. I mean, you tested it yourself right? What could some QA person have found that you didn’t account for? That’s the point. As the old phrase goes:

“It takes more intelligence to debug code than to write it. Therefore, if you write the most difficult code you can create, you are not smart enough to debug it.”

The other thing to remember is that when you as a developer test code you have the bias of knowing exactly how it works and will test with that in mind, there’s no escaping it. The QA Team is there to not only test it to see if it works, but to try the most asinine tests that end-users will do and see if it breaks. No matter how well you design your software the end-user will use it in ways you never thought possible, the QA Team is there to help you in these cases by testing obscure scenarios and reporting what they’ve found.

There’s more to it than understanding QA’s role and respecting them and relying on them. We as Developers need to be engaging them. When I turn over my software to QA, if I don’t hear anything within a few days I go bug them. My ultimate goal as should be the goal of all developers is customer satisfaction, if the customer isn’t happy you’re not going to be doing much development for them. We should be asking QA what we can provide so they can better test the code. Maybe creating a tool that will allow them to automate certain interactions or giving them DB access to see what’s getting stored. In any case we also need to be sitting down with them and making sure they understand exactly how the software works. Sit down and explain the DB table structure with them, make sure they understand the process flow. The more they understand of it the more they will know how to test it. Also keep in mind that a good rule of thumb to follow is however long it took you to develop it, it may take twice as long for QA to debug it. Your QA Team is your friend, not your enemy. QA is the body armor to failure. The more you help QA the better your chances of success.

So, Bottom Line : LOVE YOUR QA TEAM !

the Selenium blogs have been updated recently, QTP will be next followed by more Selenium updates and then Loadrunner.

So Keep Reading and stay Agile !!!

Three of the notices relate to critical vulnerabilities, with the two just classed as “moderate”, while all of which could potentially allow a hacker to executive arbitrary code.

It is understood the US-CERT department is advising Firefox users to upgrade to version 3.0.18, 3.5.8 or 3.6. Thunderbird users have been told to upgrade to 3.0.2, with SeaMonkey users also advised to upgrade to 2.0.3.

The notices come after Mozilla employee Jess Ruderman wrote in a security blog post last week the company has begun to deliver updates and notices about security problems more quickly.

It has been suggested that the Download Manager is an ActiveX script that is widely used to install a variety of software and patches across Adobe’s network.

An Israeli security researcher Aviv Raff has identified the flaw which allows a third party application to be installed on the remote machine if users click on a link.

In his blog Raff says that despite informing Adobe the company downplayed the risk.

“While it is true that the Adobe Download Manager is removed upon computer restart, the user, who has just updated their Adobe product (usually without the requirement to restart the computer after the update), is still exposed to forced automatic installation until they restart their computer.

“This specific design flaw does indeed force installation of the latest version of Adobe products. But, what if there is a zero-day flaw in an Adobe product, and you have decided to remove it from your system because of that zero-day?

“An attacker can force you to automatically download and install the vulnerable Adobe product, and then exploit the zero-day vulnerability in that product.”

A recent report from Scansafe found that based on more than a trillion web requests processed in 2009, the use of malicious PDF files exploiting flaws in Adobe Reader/Adobe Acrobat not only outpaced the use of Flash exploits, but also, grew to 80pc of all exploits the company encountered throughout the year.

“This is the kind of scenario that’s common when skilled, motivated attackers are going after select targets.

And yes, you do get a big dialog box when you are forced to download the software. Like this will really matter to the attacker, when all he wants is to get his malicious software on your machine,” Raff said.

The vulnerability was first discussed at this week’s Black Hat DC conference by Jorge Luis Alvarez Medina, a security consultant with Core Security Technologies.   Microsoft says the risk is highest for IE users running Windows XP or who have disabled the browser’s Protected Mode feature.

Medina’s  presentation demonstrated how an attacker can read every file of an IE user’s filesystem.  The attack scenario leveraged different design features of Internet Explorer that can be combined to do serious damage.

Here’s more on Medina’s talk from DarkReading’s Kelly Jackson-Higgins:

[Medina] says popular features in IE, such as URL Security Zones and the browser’s file-sharing protocol, can together be abused to execute an attack that results in the attacker being able to read all files on the victim’s machine. Medina plans to release proof-of-concept code for the attack next month after Black Hat DC, and after Microsoft issues a security update for the attack, which affects IE versions 6 and above, he says.

“These vulnerabilities are just features … the implementation of the features allow you to obtain certain information, which by itself is harmless. But when combined together with other features, it renders an attack vector,” Medina says. The attack requires the user to click on a malicious link.

According to Microsoft’s advisory,  IE’s Protected Mode prevents exploitation of this vulnerability and is running by default for versions of Internet Explorer on Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008.

The problem does affect every version of the browser but is considered most serious on Windows XP.

The vulnerability exists due to content being forced to render incorrectly from local files in such a way that information can be exposed to malicious websites.

For pre-patch mitigations, see the “workarounds” section of Microsoft’s advisory.

——————————–

Dear Google Apps admin,​

In order to continue to improve our products and deliver more sophisticated features and performance, we are harnessing some of the latest improvements in web browser technology.  This includes faster JavaScript processing and new standards like HTML5.  As a result, over the course of 2010, we will be phasing out support for Microsoft Internet Explorer 6.0 as well as other older browsers that are not supported by their own manufacturers.
We plan to begin phasing out support of these older browsers on the Google Docs suite and the Google Sites editor on March 1, 2010.  After that point, certain functionality within these applications may have higher latency and may not work correctly in these older browsers. Later in 2010, we will start to phase out support for these browsers for Google Mail and Google Calendar.

Google Apps will continue to support Internet Explorer 7.0 and above, Firefox 3.0 and above, Google Chrome 4.0 and above, and Safari 3.0 and above.

Starting this week, users on these older browsers will see a message in Google Docs and the Google Sites editor explaining this change and asking them to upgrade their browser.  We will also alert you again closer to March 1 to remind you of this change.

In 2009, the Google Apps team delivered more than 100 improvements to enhance your product experience.  We are aiming to beat that in 2010 and continue to deliver the best and most innovative collaboration products for businesses.

Thank you for your continued support!

Sincerely,

The Google Apps team

Email preferences: You have received this mandatory email service announcement to update you about important changes to your Google Apps product or account.

Google Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043

——————————————————-

All the companies should follow Google’s lead ! NewsFlash: We as QA hate testing on IE6 ! People there is IE9 in the talks ! GET OVER IE 6 !