Showing posts with label Michael Horowitz's Most Recent Posts. Show all posts
Showing posts with label Michael Horowitz's Most Recent Posts. Show all posts
Tuesday, 29 November 2011
Microsoft sloppy on Duqu workaround
The latest Windows malware, Duqu is getting a lot of attention.
Duqu exploits a previously unknown TrueType font parsing bug in the Windows kernel. The bug exists in all the supported versions of Windows: XP, Vista, 7, Server 2003 and Server 2008. It's a big-time bug too, as it lets bad guys do pretty much anything they want to do on the victims' computer.
While it works on a fix, Microsoft has offered a workaround that prevents access to the buggy component, file t2embed.dll. But Microsoft seems to have been particularly sloppy in explaining their workaround.
I am referring to Microsoft Security Advisory (2639658) Vulnerability in TrueType Font Parsing Could Allow Elevation of Privilege.
To begin with, the Suggested Actions section of the advisory offers commands that a Windows user can issue to deny access to T2EMBED.DLL.
Someone running a 64-bit version of Windows XP or Windows Server 2003, is instructed to "enter the following command" after which there are two commands. Likewise, anyone running a 32 bit version of Windows Vista, 7 or Server 2008 is also instructed to "enter the following command" and then given two commands to run.
Should you issue just the first one as instructed, or, assume the instructions are wrong and issue both commands?
And, someone running a 64 bit version of Vista, 7 or Server 2008 is given four commands to enter after the instructions to "enter the following command".
And, it goes without saying that before making sytem modifications, you should always make a restore point. I mean this literally, Microsoft omits this important Defensive Computing step from their instructions. All their "Fix it" solutions make a restore point before changing anything, so it should be in the manual instructions too.
Also missing are instructions for determining if a given copy of Windows is 32 or 64 bit. My favorite method is the free and portable SecurAble utility from Steve Gibson.
More importantly, the advisory appears to conflict with itself.
In the Mitigating Factors section it says "The vulnerability cannot be exploited automatically through e-mail. For an attack to be successful, a user must open an attachment that is sent in an e-mail message."
In the FAQ section it says "There are multiple means that could allow an attacker to exploit this vulnerability, including ... convincing users to visit a Web page that embeds TrueType."
Many, if not most, email messages are formatted with HTML, the underlying language of web pages. So, can viewing an HTML formatted email message result in an infection? I would think so.
Or, is the point about web pages wrong? I've read my share of articles on Duqu in the technical press and none of them mentioned that infection was possible by viewing a web page.
And, if web pages are a means of infection, Microsoft should say if this is true for all web browsers or only theirs.
I asked Microsoft for clarification, we'll see if I get an answer.
Microsoft has also failed to provide a tester, that is, something that a Windows user can do to verify that the workaround is, in fact, working.
If Word is the only means of infection, they should offer a test Word document. If you can get infected via a web page, Microsoft should create a page with an embedded TrueType font that does something trivial, like running the calculator, on a vulnerable machine.
They also don't say if running as limited/restricted/standard user offers any protection. My guess is that it does not, but considering this is a common defensive tactic against malware, it should be mentioned in the advisory.
Finally, Microsoft is virtually silent on the issue of what breaks when you install the workaround, be it manually with commands or with their dedicated Fix it tool.
A person commenting on a ZDNet story said the workaround "kills the ability to export to PDF in Office 2010". Another person, commenting on the same story, said that Windows Update on Windows XP gets confused by the workaround and tries to install a pair of old patches. I can't vouch for either observation.
EMAIL ATTACHMENT DEFENSE
Taking a step back, its worth noting that infected email attachments are a tried and true attack vector. And, it's a shame, because there is much that Windows users can do to protect against this, for free, that rarely gets discussed.
My first defensive computing tact for email attachments is to open them with unpopular software. For example, use Writer in LibreOffice rather than Word or SumatraPDF rather than the Adobe Reader.
An excellent second line of defense can be provided by running the unpopular software in a Sandboxie sandbox.
Finally, all email attachments need to be treated as dangerous. Just because they appear to come from someone you know means nothing.
Duqu exploits a previously unknown TrueType font parsing bug in the Windows kernel. The bug exists in all the supported versions of Windows: XP, Vista, 7, Server 2003 and Server 2008. It's a big-time bug too, as it lets bad guys do pretty much anything they want to do on the victims' computer.
While it works on a fix, Microsoft has offered a workaround that prevents access to the buggy component, file t2embed.dll. But Microsoft seems to have been particularly sloppy in explaining their workaround.
Michael Horowitz on Duqu
- Microsoft sloppy on Duqu workaround
- Why Duqu is more dangerous than most people think
- A simple test insures the Duqu workaround is working
To begin with, the Suggested Actions section of the advisory offers commands that a Windows user can issue to deny access to T2EMBED.DLL.
Someone running a 64-bit version of Windows XP or Windows Server 2003, is instructed to "enter the following command" after which there are two commands. Likewise, anyone running a 32 bit version of Windows Vista, 7 or Server 2008 is also instructed to "enter the following command" and then given two commands to run.
Should you issue just the first one as instructed, or, assume the instructions are wrong and issue both commands?
And, someone running a 64 bit version of Vista, 7 or Server 2008 is given four commands to enter after the instructions to "enter the following command".
And, it goes without saying that before making sytem modifications, you should always make a restore point. I mean this literally, Microsoft omits this important Defensive Computing step from their instructions. All their "Fix it" solutions make a restore point before changing anything, so it should be in the manual instructions too.
Also missing are instructions for determining if a given copy of Windows is 32 or 64 bit. My favorite method is the free and portable SecurAble utility from Steve Gibson.
More importantly, the advisory appears to conflict with itself.
In the Mitigating Factors section it says "The vulnerability cannot be exploited automatically through e-mail. For an attack to be successful, a user must open an attachment that is sent in an e-mail message."
In the FAQ section it says "There are multiple means that could allow an attacker to exploit this vulnerability, including ... convincing users to visit a Web page that embeds TrueType."
Many, if not most, email messages are formatted with HTML, the underlying language of web pages. So, can viewing an HTML formatted email message result in an infection? I would think so.
Or, is the point about web pages wrong? I've read my share of articles on Duqu in the technical press and none of them mentioned that infection was possible by viewing a web page.
And, if web pages are a means of infection, Microsoft should say if this is true for all web browsers or only theirs.
I asked Microsoft for clarification, we'll see if I get an answer.
Microsoft has also failed to provide a tester, that is, something that a Windows user can do to verify that the workaround is, in fact, working.
If Word is the only means of infection, they should offer a test Word document. If you can get infected via a web page, Microsoft should create a page with an embedded TrueType font that does something trivial, like running the calculator, on a vulnerable machine.
They also don't say if running as limited/restricted/standard user offers any protection. My guess is that it does not, but considering this is a common defensive tactic against malware, it should be mentioned in the advisory.
Finally, Microsoft is virtually silent on the issue of what breaks when you install the workaround, be it manually with commands or with their dedicated Fix it tool.
A person commenting on a ZDNet story said the workaround "kills the ability to export to PDF in Office 2010". Another person, commenting on the same story, said that Windows Update on Windows XP gets confused by the workaround and tries to install a pair of old patches. I can't vouch for either observation.
EMAIL ATTACHMENT DEFENSE
Taking a step back, its worth noting that infected email attachments are a tried and true attack vector. And, it's a shame, because there is much that Windows users can do to protect against this, for free, that rarely gets discussed.
My first defensive computing tact for email attachments is to open them with unpopular software. For example, use Writer in LibreOffice rather than Word or SumatraPDF rather than the Adobe Reader.
An excellent second line of defense can be provided by running the unpopular software in a Sandboxie sandbox.
Finally, all email attachments need to be treated as dangerous. Just because they appear to come from someone you know means nothing.
Why Duqu is more dangerous than most people think
I don't care who wrote the Duqu virus/trojan.
I don't care if it's related to Stuxnet or not.
I don't care who or what the target of Duqu was.
As a Windows user, what I care most about, is that Duqu exploited a previously unknown bug in Windows regarding TrueType font parsing.
Microsoft says the threat from Duqu is limited. To me, that's too narrow a scope. To me, the issue is not Duqu itself but the TrueType font parsing bug in Windows that it exploited.
The people behind Duqu could exploit this as-yet-unpatched bug again with different software. And the people who wrote Duqu may not be the only humans on the planet who found this new bug in Windows.
Although the bug is not yet fixed, there is a workaround from Microsoft that prevents access to the buggy
code. Although I griped about the workaround last time, it's very important that Windows users install it.
Very important.
All the articles I read about Duqu referred to a malicious Word document. But the bug is not in Word, it's in Windows. Version 1.2 of Microsoft's advisory (dated November 4th) clearly stated in the FAQ section that a malicious web page could also be used to exploit the bug.
One of my gripes was that the Mitigating Factors section of the advisory only referred to Word documents. This was an oversight by Microsoft. As of November 8th (version 1.3), the Mitigating Factors section has been revised to include the fact that Windows users are "vulnerable to exploitation of this vulnerability through the Web-based attack scenario."
In simpler words, all that's needed to get infected is viewing a malicious web page with an embedded TrueType font. No email. No Word. No attachments.
That's why installing the workaround from Microsoft, available in Fix It form, is a really good idea.
Web pages are formatted using HTML and, so too, are most email messages. This raises another question: can Windows users get infected viewing a malicious HTML formatted email message that contains an embedded TrueType font?
Regarding their own email software, Microsoft says in the advisory
Even in the best case, when using safe email software (that is, software that does not support embedded TrueType fonts), a Windows user can still be infected by clicking a link in an email message that opens a malicious web page.
That, in turn, raises the question of which browsers support embedded TrueType fonts.
I don't want to go there and you probably don't want to either. After all, it's likely that software other than Word, email and browsers support embedded TrueType fonts. Very likely PDFs do.
Install the workaround. It's the Defensive Computing thing to do.
Update November 12, 2011: My next blog posting describes a simple test that insures the Duqu workaround is, in fact, working.
I don't care if it's related to Stuxnet or not.
I don't care who or what the target of Duqu was.
As a Windows user, what I care most about, is that Duqu exploited a previously unknown bug in Windows regarding TrueType font parsing.
Microsoft says the threat from Duqu is limited. To me, that's too narrow a scope. To me, the issue is not Duqu itself but the TrueType font parsing bug in Windows that it exploited.
The people behind Duqu could exploit this as-yet-unpatched bug again with different software. And the people who wrote Duqu may not be the only humans on the planet who found this new bug in Windows.
Although the bug is not yet fixed, there is a workaround from Microsoft that prevents access to the buggy
code. Although I griped about the workaround last time, it's very important that Windows users install it.
Michael Horowitz on Duqu
- Microsoft sloppy on Duqu workaround
- Why Duqu is more dangerous than most people think
- A simple test insures the Duqu workaround is working
All the articles I read about Duqu referred to a malicious Word document. But the bug is not in Word, it's in Windows. Version 1.2 of Microsoft's advisory (dated November 4th) clearly stated in the FAQ section that a malicious web page could also be used to exploit the bug.
One of my gripes was that the Mitigating Factors section of the advisory only referred to Word documents. This was an oversight by Microsoft. As of November 8th (version 1.3), the Mitigating Factors section has been revised to include the fact that Windows users are "vulnerable to exploitation of this vulnerability through the Web-based attack scenario."
In simpler words, all that's needed to get infected is viewing a malicious web page with an embedded TrueType font. No email. No Word. No attachments.
That's why installing the workaround from Microsoft, available in Fix It form, is a really good idea.
Web pages are formatted using HTML and, so too, are most email messages. This raises another question: can Windows users get infected viewing a malicious HTML formatted email message that contains an embedded TrueType font?
Regarding their own email software, Microsoft says in the advisory
By default, all supported versions of Microsoft Outlook, Microsoft Outlook Express, and Windows Mail open HTML e-mail messages in the Restricted sites zone, which disables font download by default.I know people using Outlook 2003. Is that still considered supported? Does my email program, Thunderbird, support embedded TrueType fonts? Are web based email systems vulnerable?
Even in the best case, when using safe email software (that is, software that does not support embedded TrueType fonts), a Windows user can still be infected by clicking a link in an email message that opens a malicious web page.
That, in turn, raises the question of which browsers support embedded TrueType fonts.
I don't want to go there and you probably don't want to either. After all, it's likely that software other than Word, email and browsers support embedded TrueType fonts. Very likely PDFs do.
Install the workaround. It's the Defensive Computing thing to do.
Update November 12, 2011: My next blog posting describes a simple test that insures the Duqu workaround is, in fact, working.
A simple test ensures the Duqu workaround is working
As I've written about in my previous two postings, the Duqu malware/trojan exploits a bug in Windows TrueType font rendering to install itself. A very serious bug too, one that gives malicious software free rein to do anything it wants.
Microsoft is working on a fix, and in the meantime has offered a workaround that blocks access to the buggy software (the T2embed.dll file). All Windows users should install the workaround either by issuing commands from a DOS prompt or by downloading and running a Fix It program from Microsoft.
But how do you know that the workaround is doing its job?
I recently griped about some sloppiness in the Microsoft Security advisory (2639658). Since then, the advisory has been updated twice, the most change being yesterday, November 11th.
However, neither update to the advisory addressed the issue of insuring or testing that the workaround is working.
I'm glad to report that there is a simple test.
Jerry Bryant, group manager of Microsoft's Trustworthy Computing branch suggests viewing this font embedding demo web page using Internet Explorer.
The page starts off by displaying an envelope as shown below.
The important issue is the font used on the address.
Below is a closer image of the address displayed by Internet Explorer 8 on a vulnerable Windows XP SP3 system.
If you see a font like this, your Windows computer is rendering embedded TrueType fonts and thus is vulnerable to infection by any software knowledgeable and malicious enough to exploit the bug.
After installing the temporary workaround using Microsoft's Fix It tool, the font looks very different as shown below.
If this is how Internet Explorer displays the font on your computer, you are safe. That is, it shows that access to the font parsing routine, T2embed.dll, was blocked.
I verified this twice, on a 32 bit Windows XP system running as an admin user and on a 64 bit Windows 7 system running as a restricted user.
Bryant also pointed out* that "Any browser that relies on the kernel to parse embedded TrueType fonts may be affected by this issue."
Since kernel rendering of TrueType fonts is not something browser vendors frequently discuss, I also tested Firefox 8 and Chrome 15 on vunlerable instances of Windows 7 and XP.
Neither browser rendered the embedded True Type font.
To be clear, this simply means that the system can not be infected viewing a malicious web page in Firefox or Chrome. However, a Windows computer without the workaround, can still be infected by other software, such as a malicous Word document or Powerpoint presentation.
So, please install the workaround and nag your friends too also.
*I did not speak with Bryant directly. Microsoft's PR firm forwarded emails between us.
Microsoft is working on a fix, and in the meantime has offered a workaround that blocks access to the buggy software (the T2embed.dll file). All Windows users should install the workaround either by issuing commands from a DOS prompt or by downloading and running a Fix It program from Microsoft.
But how do you know that the workaround is doing its job?
I recently griped about some sloppiness in the Microsoft Security advisory (2639658). Since then, the advisory has been updated twice, the most change being yesterday, November 11th.
Michael Horowitz on Duqu
- Microsoft sloppy on Duqu workaround
- Why Duqu is more dangerous than most people think
- A simple test insures the Duqu workaround is working
I'm glad to report that there is a simple test.
Jerry Bryant, group manager of Microsoft's Trustworthy Computing branch suggests viewing this font embedding demo web page using Internet Explorer.
The page starts off by displaying an envelope as shown below.
The important issue is the font used on the address.
Below is a closer image of the address displayed by Internet Explorer 8 on a vulnerable Windows XP SP3 system.
If you see a font like this, your Windows computer is rendering embedded TrueType fonts and thus is vulnerable to infection by any software knowledgeable and malicious enough to exploit the bug.
After installing the temporary workaround using Microsoft's Fix It tool, the font looks very different as shown below.
If this is how Internet Explorer displays the font on your computer, you are safe. That is, it shows that access to the font parsing routine, T2embed.dll, was blocked.
I verified this twice, on a 32 bit Windows XP system running as an admin user and on a 64 bit Windows 7 system running as a restricted user.
Bryant also pointed out* that "Any browser that relies on the kernel to parse embedded TrueType fonts may be affected by this issue."
Since kernel rendering of TrueType fonts is not something browser vendors frequently discuss, I also tested Firefox 8 and Chrome 15 on vunlerable instances of Windows 7 and XP.
Neither browser rendered the embedded True Type font.
To be clear, this simply means that the system can not be infected viewing a malicious web page in Firefox or Chrome. However, a Windows computer without the workaround, can still be infected by other software, such as a malicous Word document or Powerpoint presentation.
So, please install the workaround and nag your friends too also.
*I did not speak with Bryant directly. Microsoft's PR firm forwarded emails between us.
Debugging a broken Internet connection
I was sitting in my living room, minding my own business, when all of a sudden I couldn't access a website. Then another and another. What to do?
Many years have taught me that the hardest part of debugging a computer problem is understanding it. With that in mind, the first thing to do is to narrow down the problem, to find the specific link in the chain that broke. The following steps should help you do just that.
1. Try a different web browser
Any computer that has only one web browser is, in my opinion, mis-configured, if for no other reason than all things break and having a second (or third) browser available is like a spare tire in the trunk.
2. Try websites by IP address
The name of a website is just a convenience for humans. In reality, computers pass data using numbers (IP addresses) rather than names. The problem might be in the system used to translate names to numbers (DNS and/or hosts file).
Testing the translation system is easy, if you prepare for it ahead of time by bookmarking the IP address of a few websites.
An excellent IP address to bookmark is the OpenDNS system status page at
http://208.69.38.170
Its a great test because OpenDNS has published their IP address and thus (sort of) promised not to change it.
It's rare for any organization to publish their IP address as it may change over time. For example, a website hosted in Florida that moves to Utah, will get a new IP address. But since the name won't change, no one should care.
Thus, it's a good idea to bookmark a handful of IP addresses because some are bound to change over time. The TCP/IP ping command, available in all desktop operating systems, can be used to find the current IP address of any website.
Here are a few randomly chosen examples:
yahoo.com http://98.137.149.56
boston.com http://66.151.183.41
microsoft.com http://207.46.197.32
reuters.com http://206.132.6.134
If websites are visible by IP address, but not by name, you have greatly narrowed down the problem.
3. Try to access your router
Routers are normally accessed by their IP address. On home networks, the address is most likely 192.168.x.x where the Xs are numbers between zero and 255.
Windows users can learn the IP address of their router with the ipconfig command, look for the default gateway. The concept of a default gateway applies to all computing devices using TCP/IP, which is pretty much all computing devices.
No matter what your operating system is, the default gateway is a basic networking concept and should be displayed in the properties of your network connection. When you learn the IP address of your router, bookmark it. It also can't hurt to tape it to the router.
If all goes well, accessing the router should produce a prompt to enter a userid and password. If, however, the page fails to load, that tells you the problem is inside the LAN, not outside.
4. Re-establish a WiFi connection
If the home page of the router fails to load and you are using a wireless network, try to disconnect from the network and then re-connect. In my case, this fixed my problem.
5. Look at your LAN
There are few parts to this. The most obvious is to reboot the problematic computer. Then, if possible, try another computing device (computer, tablet or smartphone). Also, if WiFi is not working, try Ethernet and vice versa.
6. Reboot modem and router
If you can access the router but nothing in the outside world, reboot the device(s) that give you access to the outside world. There are often two devices, a router and a modem, but some ISPs provide a single box that does both functions.
If you have two devices, reboot the modem first, then the router. By reboot, I mean unplug the device from electricity, wait a minute, plug it back in and then wait another minute for it to restart.
Afterwards, it's also a good idea to reboot the computers connected to the router. It may not be needed, but it can't hurt.
You should be prepared to do all these steps now; it's good Defensive Computing.
For extra credit, make a note of the normal state of all the lights on your modem and/or router. Which ones are on, what color they are, whether they blink or not, etc. Write it on a piece of paper and tape it to the device.
If the problem is outside your home/office, the state of these lights can be helpful to your ISP.
Many years have taught me that the hardest part of debugging a computer problem is understanding it. With that in mind, the first thing to do is to narrow down the problem, to find the specific link in the chain that broke. The following steps should help you do just that.
1. Try a different web browser
Any computer that has only one web browser is, in my opinion, mis-configured, if for no other reason than all things break and having a second (or third) browser available is like a spare tire in the trunk.
2. Try websites by IP address
The name of a website is just a convenience for humans. In reality, computers pass data using numbers (IP addresses) rather than names. The problem might be in the system used to translate names to numbers (DNS and/or hosts file).
Testing the translation system is easy, if you prepare for it ahead of time by bookmarking the IP address of a few websites.
An excellent IP address to bookmark is the OpenDNS system status page at
http://208.69.38.170
Its a great test because OpenDNS has published their IP address and thus (sort of) promised not to change it.
It's rare for any organization to publish their IP address as it may change over time. For example, a website hosted in Florida that moves to Utah, will get a new IP address. But since the name won't change, no one should care.
Thus, it's a good idea to bookmark a handful of IP addresses because some are bound to change over time. The TCP/IP ping command, available in all desktop operating systems, can be used to find the current IP address of any website.
Here are a few randomly chosen examples:
yahoo.com http://98.137.149.56
boston.com http://66.151.183.41
microsoft.com http://207.46.197.32
reuters.com http://206.132.6.134
If websites are visible by IP address, but not by name, you have greatly narrowed down the problem.
3. Try to access your router
Routers are normally accessed by their IP address. On home networks, the address is most likely 192.168.x.x where the Xs are numbers between zero and 255.
Windows users can learn the IP address of their router with the ipconfig command, look for the default gateway. The concept of a default gateway applies to all computing devices using TCP/IP, which is pretty much all computing devices.
No matter what your operating system is, the default gateway is a basic networking concept and should be displayed in the properties of your network connection. When you learn the IP address of your router, bookmark it. It also can't hurt to tape it to the router.
If all goes well, accessing the router should produce a prompt to enter a userid and password. If, however, the page fails to load, that tells you the problem is inside the LAN, not outside.
4. Re-establish a WiFi connection
If the home page of the router fails to load and you are using a wireless network, try to disconnect from the network and then re-connect. In my case, this fixed my problem.
5. Look at your LAN
There are few parts to this. The most obvious is to reboot the problematic computer. Then, if possible, try another computing device (computer, tablet or smartphone). Also, if WiFi is not working, try Ethernet and vice versa.
6. Reboot modem and router
If you can access the router but nothing in the outside world, reboot the device(s) that give you access to the outside world. There are often two devices, a router and a modem, but some ISPs provide a single box that does both functions.
If you have two devices, reboot the modem first, then the router. By reboot, I mean unplug the device from electricity, wait a minute, plug it back in and then wait another minute for it to restart.
Afterwards, it's also a good idea to reboot the computers connected to the router. It may not be needed, but it can't hurt.
You should be prepared to do all these steps now; it's good Defensive Computing.
For extra credit, make a note of the normal state of all the lights on your modem and/or router. Which ones are on, what color they are, whether they blink or not, etc. Write it on a piece of paper and tape it to the device.
If the problem is outside your home/office, the state of these lights can be helpful to your ISP.
Why Windows 7 SP1 may go missing
Back in March, I wrote that there was no rush to install Windows 7 Service Pack 1 (SP1). But that was eight months ago, and it's certainly advisable now. And even back then, I felt that installing it on a new computer was the right approach.
So, imagine my surprise when a new Windows 7 computer refused to acknowledge that Service Pack 1 existed. There were over 70 available Windows patches (the computer was a bit dated), but none were SP1.
Back when Service Pack 1 was released, I recall reading that there were some patches that were highly advisable to install before installing SP1*. Rather than re-research this, I installed about 20 patches and hoped SP1 would show up. Then another 20, then another. Eventually, I installed everything Windows Update offered, except for Internet Explorer 9. Still no Service Pack.
A trip to search engine land turned up Microsoft's KB2498452 (You do not have the option of downloading Windows 7 SP1 when you use Windows Update to check for updates), where the fourth suggestion, "Check whether you have Intel integrated graphics driver Igdkmd32.sys or Igdkmd64.sys", seemed on target. The computer was an Acer 3820T laptop with Intel integrated graphics running a 64 bit edition of Windows 7.
But the situation was not a perfect match.
The laptop had a video driver whose version number was in the suspect range, but the name of the driver was different. Microsoft said the incompatibility problem was with Igdkmd64.sys but the main video driver on the computer was identified as igdumb64.dll.
Figuring that it couldn't hurt to update the video driver, I tried the pre-installed Acer Updater application. Sadly, it returned no updates to any Acer software, something keep in mind if you're considering buying an Acer computer.
Fortunately, Intel has their own software updater application, which I wrote about back in September 2009.
The Intel utility reported that the installed video driver was old, but it didn't have an update because Acer had modified the driver. No wonder Macs sell so well.
The Intel utility did, however, offer a link to Acers website where I was able to download a zip file with the new video driver.
Despite the file name mis-match, with the updated video driver, Windows Update was now offering to install Service Pack 1. Problem solved.
But this brings up an interesting issue - how the Service Pack installer deals with new files. Many of the just-installed patches were issued well after Service Pack 1 was released and I wondered if installing the eight month old Service Pack might restore some known vulnerabilities.
It did not.
But, as is often the case with Microsoft, the Service Pack seems to have installed software with known vulnerabilities. Specifically, the previously fully-patched system now needed three new patches to the .NET Framework: KB2518869 from June 2011, KB2539635 from August 2011 and KB2572077 from October 2011.
I am so ready for a post-PC world.
So, imagine my surprise when a new Windows 7 computer refused to acknowledge that Service Pack 1 existed. There were over 70 available Windows patches (the computer was a bit dated), but none were SP1.
Back when Service Pack 1 was released, I recall reading that there were some patches that were highly advisable to install before installing SP1*. Rather than re-research this, I installed about 20 patches and hoped SP1 would show up. Then another 20, then another. Eventually, I installed everything Windows Update offered, except for Internet Explorer 9. Still no Service Pack.
A trip to search engine land turned up Microsoft's KB2498452 (You do not have the option of downloading Windows 7 SP1 when you use Windows Update to check for updates), where the fourth suggestion, "Check whether you have Intel integrated graphics driver Igdkmd32.sys or Igdkmd64.sys", seemed on target. The computer was an Acer 3820T laptop with Intel integrated graphics running a 64 bit edition of Windows 7.
But the situation was not a perfect match.
The laptop had a video driver whose version number was in the suspect range, but the name of the driver was different. Microsoft said the incompatibility problem was with Igdkmd64.sys but the main video driver on the computer was identified as igdumb64.dll.
Figuring that it couldn't hurt to update the video driver, I tried the pre-installed Acer Updater application. Sadly, it returned no updates to any Acer software, something keep in mind if you're considering buying an Acer computer.
Fortunately, Intel has their own software updater application, which I wrote about back in September 2009.
The Intel utility reported that the installed video driver was old, but it didn't have an update because Acer had modified the driver. No wonder Macs sell so well.
The Intel utility did, however, offer a link to Acers website where I was able to download a zip file with the new video driver.
Despite the file name mis-match, with the updated video driver, Windows Update was now offering to install Service Pack 1. Problem solved.
But this brings up an interesting issue - how the Service Pack installer deals with new files. Many of the just-installed patches were issued well after Service Pack 1 was released and I wondered if installing the eight month old Service Pack might restore some known vulnerabilities.
It did not.
But, as is often the case with Microsoft, the Service Pack seems to have installed software with known vulnerabilities. Specifically, the previously fully-patched system now needed three new patches to the .NET Framework: KB2518869 from June 2011, KB2539635 from August 2011 and KB2572077 from October 2011.
I am so ready for a post-PC world.
Subscribe to:
Posts
(
Atom
)
