Archive for the ‘Microsoft’ Category.

KB 2264107 rants

I was looking at the DLL hijacking hotfix (KB 2264107).   I deployed the update for 32 bit XP a couple of months back.   Tonight I was taking a look at deploying the update for other operating systems.

The first bit of weirdness I found is the Windows 7 updates now have “v2″ in the file name indicating a new version.   The release date is 12/13.   What I find odd is no mention of what was changed.   I’m guessing ntdl.dll needed to be updated due to a December security update.

What is more of a problem, the updates for Windows 7, Vista and 2008 are MSU files.   I can’t deploy MSU files through System Center Update Publisher.  The EXE update for Windows XP deployed with no issues.   I would have to use the older Software Distribution method of SCCM to deploy MSU updates.   I’m trying to avoid that. 

The DLL search order was a stop-gap patch against one of the biggest (yet often forgotten) security storylines of this year.   Countless Windows applications were found to be vulnerable because their authors failed to follow basic security practice.   This patch takes a step away from backwards compatibility and toward security.   It should be available in the Windows Update catalog.   The update by default does nothing.   You have to add a registry value anyway for it to be active.   The only reason I see not to have this in the Windows Update catalog is it provides a false assurance of security until the registry key is also set.   Its then that you have to worry about application compatibility.

Hibernate and FDE

Earlier this week, I read this article reporting on Passware’s presentation at Password^20.   It reported that if you are using BitLocker or TrueCrypt and you’ve ever used hibernate, then Passware Kit Forensic is able to recover the encryption key from the Hibernate file.   The recommendation was “NEVER EVER EVER EVER allow hibernation for any computer.”

I found this hard to believe.    So I watched the presentation.  The Q and A made it clear that if the disk is truly fully encrypted, that is including the hibernate files, and the system is off.

I’m not as familiar with BitLocker or TrueCrypt as I am with the product I use with at work.   Apparently people using TrueCrypt or BitLocker often only encrypt data volumes.   Certainly that leaves you more vulnerable.   The product I use actually encrypts the full drive,and provides pre-boot authentication at all times.   So I think the advice to never use hibernate isn’t correct if you truly have full disk encryption.

Quicktime and SCUP

When Quicktime 7.6.7 came out, I wanted to deploy it with Microsoft System Center Update Publisher (SCUP).   I’d recently used SCUP to deploy Flash (for IE) and the Dell Inventory Agent.   It made sense to look at using SCUP and SCCM Software Updates to deploy patches rather than continuing to use the old Software Distribution method.   The funny thing was, when I Googled/Binged Quicktime and SCUP, I didn’t find a lot of answers.   I found a link or two to my blog.   Well, I better actually write something since the search engine expects me to have it.

SCUP can deploy MSP, MSI or EXE.   In the past I had used a BAT file to set registry keys, copy configuration files and run the install.   So that isn’t going to happen unless I compile that into a EXE.    Quicktime also requires the update of Apple Application Support.  

I decided to use my old friend SMS Installer to package the install files into one EXE and perform the installation actions.    I decided to make it as simple as possible.   The SMS install script is something like this:

Get Environment Variable %WinDir% into variable windir
Install File \\server\sourceDIR\quicktime to %empt\quicktime\
Execute %temp%\quicktime\appleapplicationsupport.msi /qn reboot=reallysuppress (wait)
Execute %temp%\quicktime\quicktime.msi
ALLUSERS=1 DESKTOP_SHORTCUTS=0 QTTASKRUNFLAGS=0 REGSRCH_INSTALL_ASU=0 /qn reboot=reallysuppress (wait)

The command-line options seem to kept the “Q” systtray icon or desktop shortcuts from occurring.   But I didn’t manage to disable checking for updates when Quicktime is opened.   It also has the really annoying new interface.   In the past I solved those problems by dropping configuration files.   That could still be done with a bit more testing.

Compile your EXE in SMS Installer (or your favorite tool to create an install file).  

Once you’re install file is ready to go you’re ready to add it to SCUP.   Select Create Update and run through the wizard.

Update Information

Update Title: Quicktime 7.6.7   (this could be anything)
Description:  Quicktime 7.6.7 improves security and is recommended for all Quicktime 7 users on Windows.   (generally I take the description from the security advisory)
Classification: Security Advisory
Bulletin ID: HT4290
Vendor: Apple
Product: Quicktime

Extended Properties

Artcle ID: HT4290
CVE ID: CVE-2010-1799
Severity: Critical
Support URL:  could be an internal url or http://www.apple.com/quicktime/download
More Info URL: http://support.apple.com/kb/HT4290
Impact: Normal
Reboot Behavior: I left this on ‘can request reboot’ although SMS Installer is returning a 0 by default

Define prerequisite Rules

 Processor Architecture = x86
and
Windows Version Greater than or Equal to
major Version 5, SP Major Version 2, Minor Version 1
Product Type = workstation

Apple supports Quicktime on XPsp2 or greater.   Apple uses a separate install file for x64.   I chose keep things simple for now and not try to package that in here.

Select Package
Installer Type = EXE
Update Package Source = Browse to your install file (I used UNC path)   doesn’t need to be accessible to anything but your installer.
Download URL or UNC = Paste the same path as above.
Command Line = /S   (this tells the SMS installer file to run silently.   If you used a different packager you’re on your own)

Define Applicability Rules
File Version:
Common Paths – select program_files
Path – quicktime\quicktimeplayer.exe
Comparison – Less than
Version – 7.67.75.0

AND
Registry key exists
HKLM\Software\Apple Computer, Inc.\Quicktime

Define Installed Rules
File Version
Common Paths – Program_Files
Path – quicktime\quicktimeplayer.exe
Comparison – Greater Than or Equal To
Version 7.67.75.0

Now you’ve got an update that is ready to go.   Publish it to WSUS and then sync to SCCM as you would with any other SCUP update.    I always see people complaining that very few venders supply CAB files for SCUP.   The fact is before this year, very few SCCM admins were using SCUP.   Vender supplied CABs might not be configured they way you want anyway.   For example the Adobe CAB for Flash assumes you want all your computers to have Flash.   If you only want to upgrade existing Flash you need to either collection limit the update or write your own detection rules.

I hope reading thought this you understand now how to roll your own update for even a complicated update like Quicktime.   Make sure you thoroughly test your deployment.

SCUP Rule Testing

Microsoft System Center Update Publisher is a method to get third-party updates deployed through SCCM and an internal update server.   As I started working with it this summer, I had issues creating applicability rules.   When you create a collection in SCCM you get immediate feedback about the accuracy of your rules.   You either have the number of computers were expecting or you weren’t. 

With SCUP, I wasn’t getting any feedback until I published the rule to the internal update server, imported that to SCCM and waited for computers to check in.   This is not a good way to work.    Fortunately Greg Ramsey of Dell helped me out on the myitforum.com SMS/SCCM mailing list.

We’re using SCUP 4.5, but SCUP 4.0 has the ability to test the rules much more easily.  I installed SCUP 4 to a test computer, imported the update I had created in 4.5, then exported it.  The export command in 4.0 has an option to export the update to a XML with a script. 

Run the script on each computer to determine if the patch is considered applicable or not.   This is a much quicker way to verify that your update’s applicability rules are written correctly.   If you make any changes to your rules, export and bring that change back to your production SCUP 4.5.

UPDATE – As it turns out, this wasn’t as great of a tool as I hoped.   It clearly reported not applicable on machines with no Adobe Reader as I desired.   SCCM unfortunately saw the patch as applicable.   Fortunately I fixed the applicability rules before any damage was d0ne.

Authentium Command Antivirus False Positive

Authentium Command Antivirus on Friday detected a handful of Office documents  as MSWord/Dropper.B!camelot.   I ran a couple of the files through VirusTotal and found Authentium was the only company detecting the file as a virus.   In some cases that would be a sign of being on the cutting edge of detection, but in this case its a sign of a false positive. 

Friday, I tried to submit the false positives to Authentium using the instruction on their site but received to reply.   Today I followed up and was told since I wasn’t a customer, they had no interest in fixing their false positive.   I could however report the false positive to Microsoft who would then report it to them.    Going to argue with Authentium support a bit more.

[update:]
This will be fixed in an update later today.   Frustration relieved.   Probably partially self-inflicted.

SCUP and Flash

I deployed Adobe Flash 10.1 through System Center UpdatesPublisher (SCUP).  Its kind of sad how excited this makes me.

SCUP is a framework that allows you to integrate third-party update deployment into your SCCM/WSUS server.   Companies can provide a CAB file that you import into SCUP, approve updates and publish them to your SCCM server.  From there, to the SCCM admin they are deployed like any Microsoft patch.   The user experience is just like Microsoft patches as well.  

While I have only deployed SCUP in a test environment.  I think it has the potential for there to be less work in deploying updates.   A more consistent user experience can be achieved by deploying these updates through the same methods.   Currently I have a separate wrapper script that tells the user an update is available.   Even if I don’t ultimately deploy all my patches using SCUP, I can use it to deploy Dell and HP BIOS, firmware and driver updates.   As people try to do more with less, computers are being used longer.   It is thus more important to not ignore security and bug fixes in these items.

When you obtain a license to distribute Flash, Adobe sends you a link to download the MSI, EXE or CAB file.   I pointed SCUP directly at the CAB file.   The first time I tried to deploy to a client the install failed.   WindowsUpdate.log reported the error as 0×80070667.   Google (or Bing) tells me that error indicates bad command line switches.   The log file showed the switches as “/qn reboot=reallysuppress allusers=1 msirestartmanagercontro=disable reboot=reallysuppress”.   That has duplicate commands.   I recalled a Jason Lewis blog entry recommending the command line switches be left blank in the CAB file.   SCUP will automatically add silent install switches.  After removing the command line switches in SCUP, I published the change back to SCCM, synced everything and Flash installed without any further problems.

While I haven’t used SCUP in-depth yet, I am excited about what I do have in place.   My thanks go out to Jason Lewis, Program Manager at Microsoft,  for his great blogcasts showing how to set up SCUP.   I also found a PDF from Dell – Dell Catalog to Support Microsoft System Center Configuration Manager for Dell Hardware Updates by Dustin Orrick and Angela Qian to be very helpful.

50 Percent of Enterprise XP running SP2

According to Qualys, 50% of enterprise Windows XP computers are still running Service Pack 2. This was reported by Byron Acohido in a USA Today article.
This matters because MIcosoft will stop providing security patches for computers with this service pack in July. If you’re running XP, you must have service pack 3 to continue to get Operating System and IE patches.
These issues don’t just occur with operating systems. You need to keep your Office applications and other MS apps up to date on their service pack or eventually you’ll find yourself not getting updates. For home users, Windows Update will take care of that. But in a corporate environment where updates are managed, the patch admin might not “approve” all needed service packs. If you dont have a secondary method of checking for patches (e.g. a Qualys) you wont know you’re out of date. An individual in a corporate environment could run Windows Update (select the options to go against the Microsoft server rather than the internal server) or run MBSA. Even if you dont tell MBSA to run using Microsoft’s server, it will tell you if a patch isn’t approved by your administrator.
The end of life for Windows 2000 (all versions) and Windows XP prior to SP3 has been out there for a while. I’ve been using Forescout to find people running old service packs so we’ve caught everyone up on XP and Vista service packs. Windows 2000 has been hanging on on a couple of servers. An upgrade this weekend should take care of one of those.

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.

BitLocker vs Third Party FDE

Like many organizations, we skipped Vista. So with Windows 7 we are facing the question “is Windows 7 good enough” or do we still need to pay for a third-party full disk encryption (FDE) product.

This question was asked back in 2006 at the SANS Desktop Encryption Summit. The FDE vender’s felt their product was better because:
1. Better Management tools
2. Mature product
3. Multiple OS support
4. No requirement for TPM.

BitLocker is no longer a first gen product. Let’s look at today’s reasons for purchasing or continuing to use a third-party FDE product.
BitLocker Minimum Requirements
“BitLocker stores its own encryption and decryption key in a hardware device that is separate from your hard disk, so you must have either a computer with a Trusted Platform Module (TPM) or a removable USB memory device.”
USB memory devices would tend to be stored in the laptop bag, so that isn’t a secure solution.
TPMs are an additional thing to manage. Perhaps it’s not as difficult as I envision. When I did a WAVE eval, I had to go into the BIOS to enable the TPM and set a master TPM password. That doesn’t scale.
“The computer must have been configured with an additional separate active partition to be used as a system partition.”
This extra step now happens automatically, so I don’t think that is a big deal.
“The BIOS must be compatible with TPM and/or support usb devices during computer startup”
It may be necessary to upgrade the BIOS. While probably not an issue on the newer computers we would be using, this could be an issue on upgrades in place.
None of these prerequisite requirements is particularly burdensome. However it leaves out one key minimum requirement: Vista or Windows 7 Enterprise. Our XP systems would still be on the current FDE product requiring two management methods.

OTHER BitLocker Considerations

1. Provable Encryption
With the current FDE product, if a computer is lost I would be able to tell that it was actually encrypted when it was last seen on $date $time. Can BitLocker say the same? I don’t know.
Many states have an encryption safe harbor. Meaning if the lost system was provably encrypted, breach notification provisions do not apply.
2. Usability
The current FDE product syncs the domain password to the pre-boot environment. The user does not need to know a second password. The normal password requirements apply.
With BitLocker the PIN is just that. An enhanced PIN can be required but it is possible that some system BIOS will not support alphanumeric entry in the pre-boot environment. Does this PIN ever expire? It doesn’t seem like it.
3. Recoverability
The standard recovery method is to use a recovery password. This is a 48 digit number backed up to Active Directory. Enjoy typing that in when the user forgets their password.
This method is not FIPS compliant and must be disabled. Instead there are other two options
A recovery key is a 256 bit key that is saved to a flash drive. This method must be done by the end-user and they need to store the key securely. Obviously that isn’t enterprise ready.
The third option is a data recovery agent. A public key is distributed to all BitLocker protected devices. Someone with the matching private key (e.g. me) would need to be physically present at the computer. Apparently even then the OS drive must be installed on another computer running Windows 7 as a data drive.
So basically no recovery options work for us.
4. Standby
BitLocker protection is in effect only when the computer is turned off or in hibernation.
Our current FDE product protects in standby, hibernation or when the computer is off.
Update:This is is no longer true.   a preboot authentication in standby is a false sense of security.
5. Enterprise Manageability
While BitLocker has caught up with third-party encryption products in its ability to encrypt USB drives there are still other areas where FDE vender’s shine. Many FDE vender’s can also encrypt phones and managed hardware based encryption products. It’s a lot more convenient to manage these devices through one vendor.
From my limited reading it seems that there are still a number of items that argue for the continued use of a non-Microsoft FDE product.

Messege Encoding and Blackberry

Last week a user reported trouble reading a message on his blackberry. He would get an error “This S\MIME message was formatted using an encoding that is not supported on handheld.” He could still read the message correctly in Outlook 2007 and in Outlook Web Access.
It turned out the commonality to the problem was him. On this Blackberry, he couldn’t read S/MIME signed messages where people were replying to him. Others couldn’t read his S/MIME signed messages on their Blackberry.
Since the error referred to the encoding of the message, I wanted to see what the encoding was. The headers in Outlook didn’t seem to include that so I opened the message in Thunderbird. In there, it was clear that the message body encoding was Cyrillic. Kind of weird that the Blackberry reads the message just fine if its not digitally signed but gets the error above when it is digitally signed.
RIM wasn’t much help. Their support gave the same answer found in a knowledge base article. Their choices are

    ,li>Do not sign and encrypt the message.

  • In Microsoft Outlook, go to Tools > Options > Mail Format > International Options and select Auto select encoding for outgoing message.
  • In Microsoft Outlook, go to Tools > Options > Mail Format > International Options > Preferred encoding for outgoing message and select Unicode UTF-8 encoding.

Not signing the email isn’t much of a solution. I worry that changing the encoding options in Outlook would effect the readability of email in other situations.
Microsoft has an article on configuring message encoding options in Outlook 2007. There we read that “Outlook uses automatic message encoding by default, scanning the entire text of the outgoing message to determine a minimal popular encoding for the message. Outlook selects an encoding that is capable of representing all of the characters and that is optimized so the majority of the receiving e-mail programs can interpret and render the content properly.” The KB has a table showing supported encodings and whether they are considered for autoselection by Outlook. The article does not state whether we could remove an encoding option however.
Through some trial and error, I found that the problem was in the signature (footer not the digital signature) of the person reporting the problem. He had used what looked like a pipe to separate portions of the signature (like Title and Company). It wasn’t a pipe, it was actually a character inserted through the Symbol key. If I replaced this symbol with a standard pipe character the problem went away completely.
While this was a quick fix for this user, its not very satisfying. Most likely this user saw someone else’s signature and copied it for his own use. I doubt this user was using ASCII codes or hitting the symbol button. If others did the same they would have the same issue. I prefer a better solution than put it in our KB for next time it gets reported.