Skip to main content
MSRC

Month Archives: January 2010

January Security Bulletin Webcast

Friday, January 15, 2010

Hello again. To close out our January security bulletin release, we have posted the questions and answers from Wednesday’s webcast and embedded the video below. Since we only had one bulletin, the presentation was pretty short and most of the questions were concerning the Adobe Flash Player advisory we released.

Monthly Security Bulletin Webcast Q&A - January, 2010

Friday, January 15, 2010

Hosts: Dustin Childs, Security Program Manager Jerry Bryant, Senior Security Program Manager Lead Website: TechNet/security Chat Topic: January 2010 Security Bulletins Date: Wednesday, January 13, 2010 Q: Will installing the latest version of Adobe Flash Player uninstall Adobe Flash Player 6, or am I required to use the removal tool first before installing?

Security Advisory 979352 Released

Thursday, January 14, 2010

Based upon our investigations, we have determined that Internet Explorer was one of the vectors used in targeted and sophisticated attacks against Google and possibly other corporate networks. Today, Microsoft issued guidance to help customers mitigate a Remote Code Execution (RCE) vulnerability in Internet Explorer. Additionally, we are cooperating with Google and other companies, as well as authorities and other industry partners.

January 2010 Security Bulletin Release

Tuesday, January 12, 2010

Summary of Microsoft’s Security Bulletin Release for January 2010 Hi Everyone, We hope that 2010 is off to a good start for you. For our first bulletin release of the New Year, we have one Critical bulletin affecting all versions of Windows. The bulletin, MS10-001, addresses one vulnerability in the Embedded OpenType Font Engine and is Critical on Windows 2000.

MS10-001: Font file decompression vulnerability

Tuesday, January 12, 2010

MS10-001 addresses a vulnerability (CVE-2010-0018 ) in the LZCOMP de-compressor for Microtype Express Fonts. This blog aims to answer some questions regarding the updates we’ve made in this area. What is the issue? t2embed.dll improperly performs bounds-checking on lengths which are decoded from the LZCOMP bit-stream. This made it possible for a copy loop to violate the intended working buffer.