Cloud based data management

Yahoo! bug crushers have plugged a serious hole in Yahoo! Messenger that made it possible for bad guys to remotely take control of a user's machine. The update became available less than 24 hours after an anonymous hacker posted proof-of-concept code that demonstrated how the vulnerability could be exploited.

The vulnerability stems from a buffer overflow flaw in the messenger's ActiveX control. Attackers could use it to remotely execute malicious code, or for other, less serious things, such forcing a user to log out of a chat or instant messaging session or crash Internet Explorer or another application. To carry out the attack, a miscreant must first prompt the victim to visit a booby-trapped website that contains specially crafted html code.

Ironically, Yahoo!'s own discussion of the flaw may have led to the exploit code, according to Marc Maiffret, a researcher at eEye Digital Security, the security firm that discovered the security hole. An advisory eEye posted on Wednesday warned only that "multiple flaws exist within Yahoo! Messenger which allow for remote execution of arbitrary code with minimal user interaction", eEye refused to say more publicly, out of concern the additional details would enable someone to target the holes.

That didn't stop a Yahoo! spokeswoman from disclosing in a story by Information Week that the security issue was connected to a buffer overflow in Yahoo! Messenger's ActiveX control. She revealed that it was part of the code the program uses to upload and view web cam images.

Shortly thereafter, a person going by the name of Danny posted exploit code here and in the same dispatch included a link to the Information Week article.

A Yahoo! spokeswoman didn't have an immediate comment on the company's vulnerability disclosure practices.

Maiffret, who holds up Microsoft as a model for responsible vulnerability handling, he has no doubt Yahoo! tipped its hands to hackers by giving so many details before a patch was available for download. He says companies responding to security problems should learn from the mistake.

"A lot of these non-Microsoft companies, if you will, are still behind in vulnerability response practices," he says. "This just goes to show it. There's no reason at all for a vendor to list the components." ®

Regcast training : Hyper-V 3.0, VM high availability and disaster recovery