Posts tagged ‘Adobe’

SCUP and Flash Part 2

System Center Updates Publisher (SCUP) is a Microsoft product that allows an administrator to check third-party updates into their internal WSUS server and then deploy those updates with Microsoft patches through System Center Configuration Manager (SCCM/ConfigMgr).    Third party products can provide configuration (CAB) files to make this process easier.   Otherwise the admin can do the integration fairly easily if they’ve every deployed something before.

In August I wrote a about my deployment of Flash using the CAB file provided by Adobe.   One of the primary gotchas was the presence of redundant command line switches.   SCCM administrators wondered why Adobe continued to leave those switches in their update after update.   Each newbie stumbled across that issue and had to manually remove the switches.

It turns out the command line causing issues for SCUP was required for customers still using the older ITMU technology in SMS 2003.   To resolve this issue, Adobe has released a separate CAB file for SCUP users.  

If you haven’t previously received a license to distribute Flash to your employees or if your approval is more than a year old, you need to request that at Adobe’s website.     Look at the email from Adobe to get the Flash distribution URL.   At that site there is a link for SCCM/SCUP updates version SMS/ITMU updates.    There is a new URL for SCUP admins.   I’m not sure why Adobe didn’t announce this a bit more publicly instead of silently adding it to the site.

Sadly Adobe still has not added support for any of their other products.   Adobe Flash for Firefox should be the same product team and take 5 minutes of testing.  

The new CAB for SCUP has a couple of differences.
1.   The Package ID is different.   If you’ve already imported the latest version CAB file you had been using, you will have a duplicate update when you import the new version.    So make sure you keep those straight.   If you’ve already deployed the latest Flash update using the old cab hold off on changing CABs until the next Flash release.   Might make things easier.

2.  The installation detections are different.  
The cab file now intended for ITMU checked that a specific version of Adobe Flash was installed.

This would have issues if you didn’t keep on top of your Flash releases.  If a new version of Flash was released and SCUP was still looking for that product code, it would keep trying to install over top of the newer version.   That could lead to a lot of calls.

The newer CAB for SCUP admins has four rules.

First it is looking for the ActiveX control for Flash.   Next it’s looking at the safe versions Flash registry key.   Flash uses that to prevent installing if it is an older version.    That seems like a good idea, but I’m thinking if only Flash 9 is installed the computer might never get upgraded to 10.   Lastly they check for the Operating System version.   I find this a bit odd because if it is necessary, I would normally put that in the perquisites.  

I found out about this new CAB for SCUP too late in the deployment process to switch to using it.   But I figured I’d mention it for other SCCM SCUP admins.

- hat tip to John Marcum who let me know about this CAB

Adobe Reader and Acrobat Security Updates

As previously announced by Adobe, today they released critical security updates for Adobe Reader and Acrobat.

The Adobe Reader 9.4 update is a full install.   That is both a blessing and a curse.   Its good because I wont have one patch to upgrade people from the previous version, yet still have to build a full install for new installs and people more than one version behind.    The MSP patch files are much easier to deal with since Adobe doesn’t supply true single MSI installs when they do full installs.    I used iexpress to build a single exe after using the Adobe Customization Wizard.

Shockwave Security Update

Adobe has released a security bulletin for Shockwave.  

Version 11.5.8.612 fixes multiple vulnerabilities that could be used for code execution.

Patching week in review

This week saw a large number of Microsoft patches

Additionally Adobe released updates for Flash and Adobe Air. Acrobat and Reader updates expected for this week will occur next week.

Apple patched the iPhone and released an update for QuickTime.  iTunes users were not given the QuickTime update as of this post.

To stay up on all these updates, home users should install something like te Secunia Personal Software Inspector. Sysadmins should wave the dead chicken and hope for the best make plans to deploy these updates if the software is present in the work environment.

PDF Virus spammed

We’re seeing emails with the subject “phone calls” and “setting for your mailbox are changed” getting detected as bloodhound.exploit.290.  That’s a generic detection for a Adobe Reader PDF exploit.

Patch Tuesday

Here’s a roundup of patch Tuesday.
Microsoft Patches
There are two patches this month from Microsoft. One in Outlook Express/Microsoft Mail. One in Microsoft Visual Basic for Applications
Adobe released an update for ColdFusion.
A security update for Shockwave.
This one is listed as critical.
Not a bang-your-head-on-the-desk as last month, but I could have gone a month without updating an Adobe product.

PDF Launch Vulnerability

If you’ve been sleeping on the Adobe Acrobat and Reader /Launch vulnerability, its time to consider taking mitigating steps.
The proof of concept presented by Didier Stevens uses the /launch functionality that is part of the specification for PDF in order to execute arbitrary code.
Because this was a problem with the PDF specification, the problem effects multiple vendors. I had recently read F-Secure call for Microsoft to natively support the PDF/A format. PDF/A is a cut down version of the PDF standard. It specifically doesn’t allow file launches so by default it would be safe from this sort of attack. The problem I see is it does not support PDF encryption. You need that critical mass of people able to read PDF encrypted documents in order to be able to use PDF encryption.
Until last week, the attacks using the /launch functionality were also using JavaScript in the PDF. So if you had disabled JavaScript in Adobe, the user would now have to ignore a LOT of warnings in order to be attacked. Now an attack is in circulation that uses the /launch functionality without using JavaScript.
Its time to step up and apply the mitigation listed by Adobe in the Adobe Reader Blog

For consumers, open up the Preferences panel and click on “Trust Manager” in the left pane. Clear the check box “Allow opening of non-PDF file attachments with external applications”.

For administrators who wish to accomplish this with a registry setting on Windows, add the following DWORD value to:
HKEY_CURRENT_USER\Software\Adobe\Acrobat Reader\9.0\Originals
Name: bAllowOpenFile
Type: REG_DWORD
Data: 0
Furthermore, an administrator can grey out the preference to keep end-users from turning this capability on, by adding the following DWORD value to: HKEY_CURRENT_USER\Software\Adobe\Acrobat Reader\9.0\Originals
Name: bSecureOpenFile
Type: REG_DWORD
Data: 1
Note: These samples assumed you were adding registry settings to Adobe Reader 9. For Adobe Acrobat, you would replace “Acrobat Reader” with “Adobe Acrobat”, and for a different version, you would substitute its value for “9.0″.

.
The Adobe blog entry also lists a registry change to gray out the setting so the user can’t change it back if you’d like to do that.
Here’s a link to the ADM file I’m using to disable the /launch and javascript functionality in Adobe Reader and Adobe Acrobat. Make sure you test before using in a production environment.
adobe.adm

Secunia PSI and Adobe Reader.

Since Adobe Reader 9.3.1 came out, Secunia Personal Software Inspector has been reporting that I’m running a vulnerable version of Adobe Reader whenever a full scan is performed. When I select rescan, the detection goes away.
The detected file is C:\Program Files\Adobe\Reader 9.0\Reader\AcroRd32.exe . But 9.3.1 didn’t update that file. Adobe unfortunately only updates a file version when they change a file, so you can only look at add/remove programs or find the specific file that changed.
I searched on the Secunia Community forum and found a relevant thread. A “Secunia Official” says”

“This is a know (sic) bug, and is in the hands of our developers. The problem is caused by old versions of Acrobat/Reader on other drives, and the PSI using version info from files in their subdirs instead of the version that belongs to the detected instance. Thank you for reporting it, and sorry for the trouble. In the mean time, using the local rescan should produce accurate results.”


I dont see any old versions of Adobe Reader on other drives, but I did find that under windows.old I had a duplicate program files directory with an old Adobe Reader. I have an ignore rule for the windows.old directory so that shouldn’t be the problem. But at least I know they have acknowledged this behavior as a bug.
Normally when they find a vulnerable file version in some odd place they list that as the vulnerable file. In this case there is nothing wrong with the file they are reporting on.

CVE-2010-0188 Adobe Exploit

The Microsoft Malware Protection Center reported earlier this week a sighting of a malicious PDF file exploiting CVE-2010-0188. Adobe released 9.2.1 and 8.2.1 in February.
Users can pull down the ‘help’ menu and click on ‘check for updates’ to ensure that they’re running the latest version.
One lesson learned here is don’t skip deploying a patch just because no exploits are out for it. it will leave you scrambling later.
Adobe’s next scheduled Reader and Acrobat update is due April 13.

Patching Adobe Acrobat and Reader

Adobe Reader 9.3.1 is a msp file that can only be applied to Adobe Reader 9.3. So what to do about the users that hadn’t installed 9.3 yet. I really didn’t want them to install 9.3 then have 9.3.1 install immediately after that. That sort of thing sets user revolt in motion.

So I searched and found an Adobe TechNote on deploying Adobe Acrobat and quarterly updates in one install..
If you’ve used MSPs before you’re probably already familiar with how to do this.

msiexec.exe /i ”[UNC PATH]\AcroPro.msi” PATCH=”[UNCPATH]\AcroProStdUpd910_T1T2_incr.msp;[UNCPATH]AcrobatUpd912_all_incr.msp TRANSFORMS=”1036.mst”

So I went to town, stringing together the path to all the MSP updates. Good Lord! There are a lot of them.

So after I did that for Reader and Acrobat 9, and tested it all out, I found another Adobe TechNote. “Install Acrobat 9 and all patches in one step with Adobe Bootstrapper (Setup.exe) and patch sequencing”. This method is much easier. No mistakes with quotes in the command-line. Users installing from the file server can just run the same setup.EXE they always have rather than running a bat file. The same problem exists in that if they run the MSI instead not only do they not get the custom config (MST), now they miss the patches.

This article has you list the patches in setup.ini. You just add the list of patches to the product section.

[Product]PATCH=AcroProStdUpd910_T1T2_incr.msp;AcrobatUpd912_all_incr.msp;AcrobatUpd913_all_incr.msp

This is really awesome. Now my helpdesk when they install Adobe Acrobat 9 wont accidentally leave the user with the 9.0.0. That is the version of the original install files. And when we upgrade Adobe Reader, it will be a lot easier for the users.

Unfortunately my day didn’t end there. I looked at our deployed systems. While there was very little Adobe Reader 8 (so I can skip that), we actually have more Adobe Acrobat 8 installed than Acrobat 9. So I sat down to recreate what I did for Acrobat 9. Guess what, it didn’t work! After trying many different things, I stumbled across another technote. “Install all Acrobat 8 patches in one step with Adobe Bootstrapper and patch sequencing”. Apparently the Adobe Bootstraper (setup.exe) in my 8.1 CD was customized. Once I downloaded the setup.exe linked in that TechNote, it worked. I was able to run the Adobe Acrobat 8 setup.exe and install the current 8.2.1 version.

Up next is writing a script to install Acrobat patches for the users. Currently because it’s not standard software, we ask the users to do the updates.

Up next after that is the next Adobe security updates. I’m sure there are some just around the corner like the Adobe Download Manager bug.