blog.scottlowe.org

In an update to my previous article on the Windows Metafile flaw, new reports are coming in of greater use of malicious WMF files that take advantage of the flaw, especially by adware companies.  Numerous sites are reporting that malicious WMF files are being used in ad rotations on third-party sites.  For more information, see one of the following articles:

Analysts Fret as Adware Makers Leverage WMF Flaw
http://www.eweek.com/article2/0,1759,1906915,00.asp

Critical Impact: Windows Metafile Flaw a ‘Zero-Day Exploit’
http://www.eweek.com/article2/0,1759,1906177,00.asp

In addition, there are details on just how easy it is to take advantage of this vulnerability available as well.

The particularly bad part of this whole situation is that users don’t have to do a thing—just visiting a web site with a malicious WMF file can affect your system.  And this isn’t an Internet Explorer flaw, either, lest you think that using Firefox will keep you safe.  No, this is a Windows flaw, and Internet Explorer, Firefox, Opera, etc., are all affected.

Let’s hope that a good workaround (not unregistering the shimgvw.dll file, which also disables previewing other image formats in Windows Explorer) emerges soon.

Two separate reports (this article from eWeek and this article from ComputerWorld) have risen today regarding a “zero-day” exploit of a vulnerability in Windows’ handling of WMF (Windows Metafile) images.  According to the reports, simply viewing a WMF file (such as from a web site) can infect your computer.  Sunbelt Software’s blog also offers more details on the vulnerability as well.  Here’s more information from SecurityFocus as well.

According to the reports, this newly discovered WMF vulnerability will allow crackers to run the code of their choice on the affected system(s).  So far, the exploit has been limited to installing spyware, adware, and keyloggers, but there is little doubt in anyone’s mind that the attackers will grow much worse very quickly.  The vulnerability can be exploited in a variety of ways, such as visiting hostile web sites (using either Internet Explorer, Opera, or Firefox); opening an affected WMF file in Windows Picture and Fax Viewer; or previewing an affected file in Windows Explorer.  It’s important to note that this vulnerability affects even fully patched systems with all available patches installed.

Apparently, the only workaround is to uninstall Windows from your computer and immediately install Linux.  OK, just kidding.  Seriously, though, the only known workaround at this time is to unregister the affected DLL using this command:

regsvr32 /u shimgvw.dll

Click “OK” when prompted.  This unregisters the affected DLL and eliminates the vulnerability; however, this may also affect the viewing and previewing of many other types of images.

It’s still early yet in the discovery process, so I fully anticipate that more workarounds and more information will emerge as the security researchers continue their work.

As I’ve mentioned in a couple of previous posts, I have several servers running Red Hat Linux 9.0 that I am looking to upgrade to a newer distribution.  I’ve tried a couple of recent versions of CentOS (a clone version of Red Hat Enterprise Linux), but ran into problems with ntpd (I may have finally resolved those).  I’d heard good things about Debian GNU/Linux, so I decided to give that a try as well.

Prior experience with Ubuntu (as well as some time with Kubuntu) led me to believe that Debian would be equally polished.  So, I downloaded two ISO’s for Debian 3.1 (“Sarge”), the latest stable release.  Information I’d gained from some online research indicated by this release included a 2.6.8 version of the kernel, but upon installation I found I was running a patched 2.4 version instead.  After a couple of attempts to upgrade the kernel via apt-get, I finally managed to locate an appropriate package name in the stable distribution and installed it.

Unfortunately, the 2.6.8 kernel cause the system to fail to boot, listing numerous segmentation faults and finally just halting partway into the boot process.  I was extremely disappointed—after having spent that time downloading the software and then installing it, it was now completely unusable.

I’m sure that Debian fans will point out that I surely did something incorrect and things normally don’t happen that way.  Perhaps that is true; I will certainly be the first to admit that I may have done something incorrectly while using apt-get to upgrade the kernel.  I would be nice to know exactly what it was that went wrong, though.

In the meantime, I’m going to shelve Debian GNU/Linux as a possible replacement OS and continue searching.  At this point, OpenBSD is starting to look really good…

Just so the Windows flaws don’t get all the attention, here’s a reasonably new one:  a flaw in VMware, the machine virtualization software that is tremendously popular, especially among security professionals.  Fortunately, it’s reasonably easy to work around the flaw, and VMware has already released a patch.

This link offers more details on the VMware security flaw, which apparently affects almost all of the VMware products, with the notable exception of ESX Server.  VMware’s security advisory also provides complete details and information on how to protect against it, plus a link to download the patch.

VMware users can sidestep the security issue by not using NAT networking for their virtual machines, as pointed out in the security advisory.

While security flaws in Microsoft’s Windows operating system and Internet Explorer web browser get most of the attention these days, all products have them.  Users of Linux or Mac OS X like to proclaim their immunity, but no one is immune.  This recent vulnerability merely highlights the fact that we must all be vigilant and watchful in order to maintain the security and integrity of our networks and systems.

I’d like to take a moment to wish everyone a very Merry Christmas and a Happy New Year!  I hope that the Lord blesses each of you very richly in the coming year.  Let us be sure not to forget the true reason for this season—the birth of Jesus Christ, our Lord and Savior.

The NTPd problem that I wrestled with in CentOS 4.1 and again in CentOS 4.2 has finally been resolved.  Mostly.  I think.  The specific steps I took to resolve the issue came from a number of sources, so read on for all the details.

Since these servers are virtual servers running under VMware, I first consulted the VMware Knowledge Base and turned up this article on slow and fast clocks for Linux guest VMs.  Based on that information, I added a few extra commands to the grub configuration:

noapic nosmp nolapic clock=pit

In addition, I found a number of forum postings in various sites (too many to list or link here) that referenced problems with NTP and ACPI.  So, based on that information, I further edited the grub configuration to look like this:

noapic nosmp nolapic clock=pit acpi=no

Finally, based on information regarding NTP itself and the NTP configuration parameters, I added the “burst iburst” parameters to the server lines in my ntp.conf file, like this:

server W.X.Y.Z burst iburst

This helped, as at least now NTP would synchronize against something other than the local clock (which was more than it had done previously).  For some reason, though, the /var/log/messages log file was filling up with messages about synchronizing against the local clock, then synchronizing against the server, then against the local clock, etc.  (You get the picture.)

Given that I was synchronizing against a Windows Server 2003-based computer, I thought perhaps that Microsoft’s NTP implementation was simply broken.  (This certainly wouldn’t be the first time.)  So I configured OpenNTPd on an OpenBSD server (running OpenBSD 3.8) and re-configured the CentOS server to synchronize against the OpenBSD NTP server.

<aside>OpenNTPd is ridiculously simple to configure and operate, and just works.</aside>

The repetitive synchronization messages still appeared, but were appearing with far less frequency.  And the time still isn’t synchronized to the level I would like, but it does stay within a minute or so of the rest of the network (well within the 5 minute gap required in order for Kerberos authentication to work).

So, it’s still not working as cleanly as the older Red Hat Linux 9.0-based servers, but it is working.  Given that I’m still running these servers under an old version of VMware (which, technically, doesn’t support Linux 2.6 kernels) I may try upgrading to a new version of VMware to see if that helps at all.

UPDATE:  These instructions are for Windows 2000 Server and Windows Server 2003 pre-R2.  For the R2 release, please see these updated instructions.

There are several articles posted here that discuss, in general terms, how to authenticate Linux against Active Directory.  For example, see this brief article on the broad direction of the integration, or this posting on using computer accounts for Linux servers (most how-to documents I’ve seen discuss the use of a user account for this purpose).

Over the last week or so, I’ve been having to rebuild one Linux server a number of times in an effort to fix a separate problem (see this article on NTPd problems with CentOS 4.1 and the recurrence of the problem with CentOS 4.2).  As a result, I’ve had to go through the process of configuring this Linux server (and preparing Active Directory) for authentication several times, and I found that I kept having to go back to my scattered and dispersed notes to remember what had to be done.  In the hopes of correcting that, I am collecting all the pertinent information I have here in this article.

Preparing Active Directory (One-Time)

There is a one-time preparation of Active Directory that is required.  In order to authenticate Linux logins against Active Directory, Active Directory’s schema must be extended to include Linux-specific attributes such as home directory, UID, GID, and default shell.  There are a couple of different ways to do this; I chose to use Microsoft’s Services for Unix (SFU) to extend the schema.  There are two reasons I chose SFU: 1) it’s free; and 2) the SFU schema is being included by default in Windows Server 2003 R2.

Once SFU has been installed and the schema has been extended, then the specific Active Directory accounts that are allowed to authenticate via Linux must be configured with a UID and other UNIX attributes.  This is accomplished via the new “UNIX Attributes” tab on the properties dialog box of a user account.

You’ll also need to create an account in Active Directory that will be used to bind to Active Directory for LDAP queries.  This account does not need any special privileges; in fact, making the account a member of Domain Guests and not a member of Domain Users is perfectly fine.

After all the user accounts have been configured, then we are ready to perform the additional tasks within Active Directory and on the Linux server that will enable the authentication.

Preparing Active Directory (Each Server)

For each server that will be authenticating against Active Directory, follow the steps below.

1. Create a computer account in Active Directory.  When creating the computer account, be sure to specify that this account may be used by a pre-Windows 2000–based computer.
2. Use the following command at a command prompt to configure the new computer account:
   ktpass -princ host/fqdn@REALM -mapuser DOMAIN\name$
-crypto DES-CBC-MD5 -pass password -ptype KRB5_NT_PRINCIPAL
-out filename
   Of course, you’ll need to substitute the appropriate values for “fqdn” (the fully-qualified domain name of the computer), “REALM” (the DNS name of your Active Directory domain in UPPERCASE), “DOMAIN” (the NetBIOS name of your Active Directory domain), “password” (the password that will be set for the new computer account), and “filename” (the keytab that will be generated and must be copied over to the Linux computer).

If you need to rebuild the Linux server for whatever reason, you’ll need to delete the computer account you created and repeat this process.

Preparing the Linux Server

Follow the steps below to configure the Linux server for authentication against Active Directory.

1. Make sure that the appropriate Kerberos libraries, OpenLDAP, pam_krb5, and nss_ldap are installed.  If they are not installed, install them.
2. Be sure that time is being properly synchronized between Active Directory and the Linux server in question.  Kerberos requires time synchronization.
3. Edit the krb5.conf file to look something like this, substituting your actual host names and domain names where appropriate:
   [logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
 
[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_realm = true
dns_lookup_kdc = true
 
[realms]
EXAMPLE.COM = {
kdc = host.example.com:88
admin_server = host.example.com:749
default_domain = example.com
}
 
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
 
[kdc]
profile = /var/kerberos/krb5kdc/kdc.conf
 
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}
4. Edit the /etc/ldap.conf file to look something like this, substituting the appropriate host names, domain names, account names, and distinguished names (DNs) where appropriate.
   host 10.10.10.10
base dc=example,dc=com
binddn cn=ldap,cn=Users,dc=example,dc=com
bindpw adldapbindpw
scope sub
ssl no
nss_base_passwd dc=example,dc=com
nss_base_shadow dc=example,dc=com
nss_base_group dc=example,dc=com
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_objectclass posixGroup group
nss_map_attribute uid sAMAccountName
nss_map_attribute uidNumber msSFU30UidNumber
nss_map_attribute gidNumber msSFU30GidNumber
nss_map_attribute loginShell msSFU30LoginShell
nss_map_attribute gecos name
nss_map_attribute userPassword msSFU30Password
nss_map_attribute homeDirectory msSFU30HomeDirectory
nss_map_attribute uniqueMember msSFU30PosixMember
nss_map_attribute cn cn
5. Securely copy the file created using the ktpass.exe utility above to the Linux server in question, placing it in the /etc directory as krb5.keytab.  (SFTP or SCP are excellent candidates for this.)
6. Configure PAM (this varies according to Linux distributions) to use pam_krb5 for authentication.  Many modern distributions use a stacking mechanism whereby one file can be modified and those changes will applied to all the various PAM-aware services.  For example, in Red Hat-based distributions, the system-auth file is referenced by most other PAM-aware services.
7. Edit the /etc/nsswitch.conf file to include “ldap” as a lookup source for passwd, shadow, and groups.

That should be it.  Once you do that, you should be able to use kinit from a Linux shell prompt (for example, “kinit aduser”) and generate a valid Kerberos ticket for the specified Active Directory account.

At this point, any PAM-aware service that is configured to use the stacked system file (such as the system-auth configuration on Red Hat-based distributions) will use Active Directory for authentication.  Note, however, that unless you also add the pam_mkhomedir.so module in the PAM configuration, home directories will have to be created manually for any Active Directory account that may log on to that server.  (I generally recommend the use of pam_mkhomedir.so in this situation.)

A while back, I started working with CentOS (version 4.1 at the time, see my impressions here) as a candidate replacement for the Red Hat Linux 9.0-based servers still in service on the network.  Although I was (and still am) very comfortable with Red Hat Linux 9.0, it’s getting a bit long in the tooth and I wanted to update the servers to a more modern software base.

The problem is, I kept running into issues with time synchronization on the CentOS server.  This time synchronization issue did not appear on the Red Hat Linux servers.  I tried to resolve the issue, but never did find the solution.  Instead, I just used ntpdate in a cron job.  That seemed to work well enough, but I really wanted it to work PROPERLY.

So I started working with CentOS 4.2 earlier this week, hoping that whatever had plagued me with the previous version wouldn’t afflict me this time.  Unfortunately, the exact same problem has cropped up again, and I am at a loss trying to figure out why it doesn’t work.  The output from “ntpq -p” indicates that communication is occurring with the desired time servers, but the NTP daemon still keeps choosing to synchronize with the local clock.  SELinux is disabled, so it can’t be interfering with NTP (I think that was the problem with the earlier CentOS 4.1 installation), iptables is not running (so it can’t be a firewall issue), file permissions and ownership look OK—what could I be missing? If anyone has any ideas, please let me know.

Before I switched to Mac OS X, I was a heavy duty Windows user.  I had Windows XP on my laptop, Windows 2000 on my servers, and used a Windows CE-based Compaq iPaq H3765.  Since that time, I (of course) switched to Mac OS X on my laptop (a 15“ PowerBook G4 with SuperDrive); a mix of Linux, OpenBSD, and Windows on my servers; and a Palm OS-based handheld (currently a Treo 650, previously a Tungsten T3).  As a result, I still had this iPaq sitting around doing nothing.  So, on a whim, I decided to install Linux on my old iPaq.

Using the installation instructions at familiar.handhelds.org, I downloaded an Opie image, installed the bootloader, and reflashed the iPaq from a spare 128MB CF card (I had a CF sleeve with external battery for the iPaq).  After only a few minutes (the entire process was really quite painless), I was up and running with Linux on my iPaq.

Having Linux running on the iPaq is great, but now I have to figure out what to do with this Linux-based PDA.  Suggestions, anyone?

I coined the term “application specific VPNs” as I began exploring the many uses of tools such as SSH (the OpenSSH implementation, in particular) and Stunnel (the open source SSL wrapper).  An “application specific VPN” is a technique for employing encrypted communication with a particular remote application that does not affect the operation of other applications (local or remote) on the system.

In general, most VPNs employ technology such as PPTP or IPSec.  These protocols usually affect all traffic originating from that system (unless we use split tunneling).  With an application specific VPN, only particular types of traffic are affected, and these particular types of traffic are wrapped in an encrypted SSH or SSL tunnel using either OpenSSH or Stunnel, respectively.  Other types of traffic are unaffected.

While this may seem old hat to long-time Linux, Unix, or Mac OS X users, this is a relatively new concept to other platforms.  Being a (fairly) new convert to Mac OS X myself, I found myself enjoying the tremendous flexibility offered by application specific VPNs.  However, this functionality is certainly not limited to these platforms, and it is possible for Windows users to utilize this functionality as well.

Some Examples

Here’s a few examples of how you can use application specific VPNs:

• Citrix Presentation Server:  Users can wrap Citrix ICA traffic in SSL using Stunnel; this avoids the need to pay for commercial solutions (although, quite honestly, the commercial solutions are typically easier to deploy and manage).
• E-Mail:  Lots of people talk about securing e-mail, but not usually in the context of securing client-to-server traffic.  With Stunnel, you can add SSL support for IMAP, POP, and/or SMTP even if the server doesn’t support SSL natively.  In fact, you can add Stunnel to Microsoft Exchange to help bolster that product’s built-in support for SSL (such as using SMTPS instead of STARTTLS for encrypting SMTP traffic).
• Remote Desktop:  This is a great technique for sysadmins.  Need to use Remote Desktop to manage a Windows-based server remotely, but don’t want to run into security problems?  Use Stunnel or OpenSSH to encrypt the RDP traffic.  Stunnel, in my opinion, is particularly good here, since it’s incredibly easy to use the Windows port of Stunnel to establish an SSL listener on an arbitrary high port for this very purpose.

Using Stunnel for SSL-based Application Specific VPNs

On Windows, there is no graphical user interface (GUI) for configuring Stunnel; all configuration must be done with the stunnel.conf configuration file.  A sample stunnel.conf file is found below; this file listens on TCP port 1494 and forwards traffic to TCP port 3389 on the same system. (Note that this would be a sample stunnel.conf file for a server-side configuration.)

CApath = c:windowssystem32stunnel
cert = c:windowssystem32stunnelstunnel.pem
client = no
service = SSLTunnel
[rdp]
accept = 1494
connect = 3389

Once Stunnel has been configured, running “stunnel –install” will install it as a system service; this service can then be stopped and started through the Services MMC console just like any other background service.

Of course, this is only half the work; you’ll also need an equivalent Stunnel configuration on the client side, since the Microsoft RDP client (the Windows version or the Mac OS X version) does not support SSL.  Also, note that the SSL certificate used by Stunnel needs to be in PEM format (which is a nice lead-in to my article discussing the conversion of certificates).

On Mac OS X, there is a graphical utility for managing Stunnel called SSL Enabler.  (Note that I was not able to find a home page for this utility; downloads can be found at various sites.)

On Linux, the configuration again involves editing the stunnel.conf file and launching stunnel (either in the foreground or as a daemon).  I’m not aware of any GUI utilities for configuring Stunnel on Linux, but that certainly doesn’t mean they don’t exist.

Using SSH for Application Specific VPNs

As with Stunnel, it’s also possible to use SSH to create application specific VPNs.  Mac OS X comes with OpenSSH, as do most distributions of Linux and various flavors of BSD.  Windows users can also find various ports of OpenSSH and utilities such as PuTTY that make it possible to use SSH for application specific VPNs as well.

On Mac OS X, the following command in Terminal will create an application specific VPN to encrypt IMAP traffic to a remote server:

ssh -L 1143:imapserver.domain.com:143 -N -f  user@sshserver.domain.com

This same technique could be used to encrypt WebDAV traffic to a remote web server, other types of mail traffic (POP3 or SMTP, for example), RDP (for Remote Desktop), etc.  Note that it doesn’t work well with HTTP traffic that requires the use of host headers.

There are a few graphical utilities on Mac OS X for managing SSH tunnels; these include SSH Tunnel Manager and AlmostVPN.

Not being a regular day-to-day Linux user (not on the desktop, at least), I don’t know of any SSH tunnel management applications, but I would be very surprised if they didn’t exist.

Creating Site-to-Site Application Specific VPNs

Most of the examples so far have been using SSH and/or Stunnel to connect endpoints (i.e., a single laptop or desktop computer) to a remote resource via an application specific VPN.  However, it’s also easily possible to create application specific site-to-site VPNs, whose purpose is to secure only a particular type of traffic between two locations.

Consider this two example.  CompanyA wants to send e-mail to CompanyB, but wants that e-mail to be secure.  If both mail servers support TLS, then the organizations could use TLS to secure the SMTP traffic.  If not, then the companies can use Stunnel to establish an SSL connection between two systems.  HostA at CompanyA can use Stunnel as a client side application to listen for unencrypted connections and pass them as encrypted connections to HostB at CompanyB.  HostB at CompanyB is using Stunnel to listen for encrypted connections and passes them unencrypted to the mail server at CompanyB.  With a simple configuration, the mail servers at both companies can be configured to pass mail connections for other company through the Stunnel connection.  With no additional cost and very little configuration, all e-mail traffic between the two organizations has now been secured.  All this without the complexity of a typical B-to-B VPN and the associated access controls.

For more information, documents on application specific VPNs with SSH and application specific VPNs with Stunnel are available.