Posts tagged ‘Patching’
If you haven’t logged into your WordPress today, this is news to you. Version 3.3.1 has been released to fix a XSS vulnerability.
According to ThreatPost, this is only a vulnerability if you installed WordPress by browsing to the IP. Most installs are hosted and you would browse to the site FQDN to install. These systems aren’t vulnerable.
The update also fixed 15 bugs. So review the release notes and determine if you need to update. Or just do it.
F-Secure generated a lot of traffic in the blogosphere with their post declaring Java harmful and better to not be installed on computers. To me the only surprising part is the discussions this generated. Isn’t this old news? Principle of least privilege says to remove it if you don’t need it. So when you’re regularly updating an application for security fixes it may be time to consider alternatives.
F-Secure links Larry Seltzer’s month without Java from 2010. Brian Krebs posted a blog article around the same time recommending Java be removed. I couldn’t find an earlier article, but I thought Krebs had been banging this drum for much longer.
Removing software you don’t need certainly lowers the attack surface area. At work, I’d caution that you’re likely to find groups of users using Java for internal applications. If you don’t put Java on your system image, they are going to install the ancient version of Java supplied by their application developer. I found a couple users with Java 1.6.0 update zero. When I removed that and installed the latest Java 1.6, the application still worked fine. If you’re actively patching your environment having Java installed may not be that bad.
The articles liked mention alternatives such as only allowing Java to run on specific sites. Sometimes I install Java only for use on my non-day-to-day browser. I’m not sure either solution scales into the enterprise where you have to account for all sorts of computer literacy.
I’m kind of confused by the headlines that Microsoft is streamlining the security update process in Windows 8 resulting in less reboots.
One could easily conclude from the headline that Microsoft has gone to work to make it less necessary to reboot when updates are applied. Instead they are saving up reboots until patch Tuesday.
It is always good to challenge assumptions, but I’ve always been told that when you don’t reboot after patching, the system is in a unsteady state and the you aren’t patched until the reboot occurs. Perhaps they’ve corrected the first problem by making sure the system doesn’t partially patch and then wait for a reboot to replace the files in use. But you can’t solve the problem of the system not being patched until reboot. I haven’t seen anything indicating much of anything is new other than a reboot policy.
That’s just Microsoft patches. I see nothing here that will slow the rate of patches for end users. Microsoft talks about a single restart patching policy. They already only roll security patches once a month.
Microsoft achieved what they wanted. They received positive press for Windows 8. I’m still not sure what is changing.
Adobe released a security update for Shockwave last night brining the current version to 11.6.3.633.
Unfortunately, the link to the MSI on the enterprise distribution page still has an older version of the update. I thought we were past this nonsense with Adobe. A couple years ago this sort of thing was frequent.
As part of deployment of JAVA 1.6 update 29, I decided it was time to take a closer look at removing older versions of JAVA.
At one point in time, new JAVA installs left all previous versions installed on the system. In 1.6 update 10, JAVA began installing JAVA into %programfile%\java\jre6. Each subsequent update would replace the version there before it in that directory. I became a bit slack in removing older versions. Even in June (the previous quarterly update), I only removed versions of JAVA older than update 10. In my post about that, I say “Later versions should be removed automatically.” This is incorrect.
Versions installed normally will behave this way. But it is still possible for an application to install in “static” mode so that its version remains. There are also automatic rules that JAVA uses to determine if an install is static or not. This document for JAVA 7 describes the behavior that I believe also occurs in JAVA 6 (aka 1.6)
By default a new version of JAVA is installed patch-in-place. In other words it replaces the version already there. If you attempt to install a older version of JAVA it will automatically become a static version. And of course a (bad) programmer can bundle an old version of JAVA and make it static. So older versions of JAVA can still crop up. And these older versions are vulnerable, and often unnecessary.
At first I was going to update my existing script to remove all 1.6 versions of JAVA. It quickly became apparent that this was going to take forever and also have issues with 64 bit computers.
This is where the community helped out. On the MyITForum SCCM email list there were several suggestions for better ways to remove old JAVA. I’m going with a uninstall script posted over at AppDeploy. I’m using the one marked version 3. It is a well commented VBScript with a help section and logging. Two gotchas. One is don’t forget you might need to whitelist the JAVA 7 clients. I also needed to check SCCM to see if there were any false positives. In other words would it remove any items that just happened to have JAVA in the Add/Remove Programs Display name. The script already handled 5 things like that. I added around another 5 based on what software is in my environment.
Back in June I wrote about my methodology of deploying SCUP and how I wished I had the time to work out deploying JAVA with SCUP. The quarterly update for JAVA was released last week, so it was time to go another round.
When deploying JAVA in an interactive manner, the install will prompt the user if the browser is running or anything else is running that prevents access to files. That in itself is annoying, because I’d often see computers at a screen prompting the user days later. Further installs are blocked. Not good. So I in a /qb type of install, I would prompt the user to close the browser and when they don’t, I close it for them.
That doesn’t really work in a silent install. SCUP is a method of adding third party updates to the corporate update server. The Windows Update Agent doesn’t appear to want to do things interactive with the user.
There isn’t a lot out there about SCUPing JAVA. Kent Agerlund’s guide for installing SCUP 2011 has a example deploying JAVA, but it is the most vanilla example you could think of. It doesn’t take into account any of the things I would do to deploy JAVA. I’m shocked it works for anyone. (no offense intended Kent, I do love the SCUP 2011 instructions are great.)
I found a Oracle Forum thread and a Request for Enhancement that describe the problem perfectly. When the browser is open and installing silently you’ll get an error “Error 25099. Unzipping core files failed.”
“Inside the %PROGRAMFILES%\Java\JRE6\bin folder is the Microsoft Runtime Library file MSVCR71.DLL that gets locked if a browser is open. During installation, the older JRE6 version is removed (unless it was installed with the STATIC switch) except for MSVCR71.DLL. Then the silent installation begins, with the core.zip expanding in alphabetical order until it comes to the letter m where it finds MSVCR71.DLL and just stops (in a non-silent mode, the user would be thrown a dialog to quit the browser / jqs, etc.). No roll back, no repair, etc. So now your left with some residual files, some reg entries but no control panel, no entry in the ADD/Remove Programs list (ARP), no regsvr32 registration has occurred.”
Most installations that find a file in use would mark the file for replacement during reboot and then ask for reboot at the end of the installation. Wouldn’t that be a better way to go?
The workaround provided in the discussion thread is to use the STATIC=1 flag. That will install the new version of JAVA into its own directory. This scenario was rejected by my management because this essentially reverts JAVA to its behavior prior to update 10. The version installed with a static flag would remain forever until removed manually.
After all that, I went back to deploying through SCCM Software Distribution rather than SCUPing a software update.
SANS posted a one-liner today reporting that Flash 10.3.181.34 was available for download from Adobe. This wasn’t entirely unexpected because Google released a new version of Chrome on June 30th which contained a new version of Flash. Adobe seems to be releasing new Flash versions to the rest of us a couple days after Chrome.
Adobe has not released a security bulletin. This seems to be more a bug fix release. The release notes describe this release as “addressing compatibility issues with some content using cross-domain policy files.”
Patch deployers can back off the ledge for now. No huge reason to deploy this one if you aren’t having this issue.
Mozilla released updates for Firefox and Thunderbird.
This is the end of the line for Firefox 3.5. Also it appears that the 4.x train was not very long. It looks like 4.0.1 must update to 5 to have the security updates.
Thunderbird is now running 3.1.11.
Enjoy your updating.
Oracle released JAVA 1.6 update 26 as part of the scheduled quarterly update. It fixes 17 vulnerabilities.
I would have liked to deploy this with System Center Update Publisher but I find JAVA to be kind of an odd duck. To get it SCUPed would take a lot of testing. I needed to get the patch out the door. That required enough testing. Starting with a new deployment technique would require even more.
1. net stop javaquickstarterservice
The JAVA Quickstart service has caused issues in the past when it is running during an upgrade.
2. Force users to close browsers
I’ve had issues when doing a /qb install where the install would wait until the browser is closed by the user. If the user isn’t there, then the install never finishes. I dont know if a silent install would have the same issues or not.
3. Next, I uninstall JAVA 1.6 update 0 through 7. Later versions should be removed automatically.
4. Run the install
5. Disable the autoupdater
6. “%PROGRAMFILES%\Java\jre6\bin\jqs.exe” -unregister
to disable jqs completely.
Basically I would need to package my current install files into an EXE, and verify that it still does what I want.
Kind of a duct tape and twine way of doing it. I’d prefer to fully translate that to SCUP.
If I ever get some time, it would be nice to do some work on this when it isn’t on a deadline.
There is yet another security update for Adobe Flash.
I don’t know about you, but I think its is getting old.
June 5th APSB11-13
May 12th APSB11-12
April 15 APSB11-07
March 21 APSB11-05
Feb 8 APSB11-02
Not to mention the security updates for Flash in other products like Adobe Reader.
Back before I improved the patching process, by the time a patch was ready to be deployed, the next one was ready to go out. Improving our process does lessen the exposure to threats, but it sure feels like we’re only keeping up with the Adobe patching treadmill.
