The following paper was originally published in the Proceedings of the Large Installation System Administration of Windows NT Conference Seattle, Washington, August 5–8, 1998 Patch32 : A System for Automated Client OS Updates Gerald Carter Auburn University For more information about USENIX Association contact: 1. Phone: 510 528-8649 2. FAX: 510 548-5738 3. Email: [email protected] 4. WWW URL:http://www.usenix.org/ Patch32 : A System for Automated Client OS Updates Gerald Carter Engineering Network Services Auburn University [email protected] Abstract the various requirements of such an update system. Section 3 describes security concerns related to The adage “a chain is only as strong as its weakest Patch32 and ways to address these concerns. For link” is true for network security, the link being the those wishing to implement the system, suggestions host on the network. To secure a network, hosts must for customization are described in Section 4. Finally, be thoughtfully installed and kept updated with the lessons learned from the implementation process as appropriate patches. For hosts running Microsoft well as plans for future enhancement are included in Windows 95 or Microsoft Windows NT Workstation Section 5. The appendix contains the perl source code keeping patches current is problematic. for the Patch32 script, example patch listings, URL’s and other references for the reader interested in finding Unlike most Unix variants, neither Windows 95 nor out more about the software and ideas presented here NT Workstation ship with a network extensible update mechanism. Though third party solutions are available, they can be costly to implement for large networks. 2. Implementation This paper presents a free update mechanism for hosts running Windows 9x or NT Workstation served by 2.1. File Access Samba (see Appendix A). The file services needed to support Patch32 are pro- Developed to patch Microsoft’s 32 bit operating sys- vided by a dedicated 196MB Sun Ultra 170 running tems, the name Patch32 was adopted. Patch32 was Solaris 2.5.1. Samba, which is available under the developed for an existing network dominated by Sun GNU General Public License, provides file and print Microsystems’ SPARC servers running Solaris, how- services to Server Message Block (SMB) clients in- ever, Patch32 can be used in any environment that cluding Microsoft’s Windows for Workgroups, Win- provides SMB file services. dows 95 and Windows NT. Samba also includes the capability to act as a Primary Domain Controller (PDC) for Windows NT Domains, although this sup- 1. Introduction port is currently in the testing stages and is not in- cluded in the main source distribution as of version The initial design criteria for Patch32 was simple: 1.9.18p7. Provide for completely automated, remotely adminis- tered updates to Microsoft’s 32 bit operating systems. SMB services were chosen rather than other file shar- Essential to any automated update mechanism is the ing protocols such as NFS due to the native support for ability to determine what operating system the ma- SMB within the Microsoft operating systems. This chine is running and what updates have already been support, combined with the Microsoft Network Client, installed so that the necessary updates can be deter- allowed built-in tools such as domain login scripts and mined. To be effective, any update mechanism must System Policies to be used to configure the execution be able to access the necessary updates from a central of patch scripts on remote machines. location without human intervention and with a mechanism to guarantee that the program will be run Two separate copies of Samba were configured on the on the client systems with reasonable regularity. physical server, each have its own network interface. This was accomplished by utilizing two settings in the This paper addresses issues that arose during the im- samba configuration file (smb.conf). The “interfaces” plementations of Patch32. The remaining sections are parameter specifies the correct network interface to organized as follows. Section 2 discusses solutions to which the samba processes should attach and the value for the “socket address” parameter determines the IP tion files, device drivers or any other imaginable por- address to which the samba processes should bind. tion of the local system. The reader should be aware that using this second pa- rameter may cause problems with network browsing. The second component is the patch installation pro- The problem has been reproduced when the domain gram. Windows 95 updates normally rely on the controller is bound to the second network interface rundll.exe and setupx.dll files, which are by default which has been created as a virtual interface. There- located in the \windows and \windows\system directo- fore it may be necessary to use a central WINS server ries respectively. Windows NT Service Packs and in order for a client to resolve names correctly even if Hotfixes normally include an installation executable. it is on the same subnet as the samba server. The final necessary component for an installation pro- At the College of Engineering, the first samba server, gram is a listing of directory locations and registry \\USERSERVER, provided access to department keys where the updated files and information is to be shares, user shares, and various network printers. The placed. This listing may be internal to the installation second copy of samba, \\GUESTSERVER, provided executable or, as is the case with both Windows 95 access to various system and development tools such and Windows NT fixes, external in the form of an in- as the Java SDK, Perl5 for Win32, administrative formation file (INF). scripts and command line utilities. Both the Windows 95 and the Windows NT updates Both servers are configured with user level security released by Microsoft are packed in a self-installing however, \\GUESTSERVER is configured to only al- executable file. The method for extracting the internal low guest connections. This is accomplished by de- files is different for each operating system. fining GUEST_SESSETUP to be the integer 2 in the file local.h, which is part of the samba source code To install a Windows 95 update such as the Service distribution, and by isolating \\GUESTSERVER from Pack 1, a user would normally simply launch the up- the normal list of accounts. Therefore any user at- date executable. At this point the setup program will tempting to connect is validated as the guest account extract the archived files into the %TEMP% directory. specified in the smb.conf file. This mechanism allows When prompted to continue with the update, the user machines to access specific shares without validation. may then make a copy of the files that have been ex- Since all files accessible on \\GUESTSERVER have tracted and cancel the setup program. been deemed as public access, the setup does not cre- ate a security concern. In order to extract the archived files from either a Windows NT Service Pack or Hotfix, one must simply At this point is may be obvious why it was decided to run the archived executable from a console window run two separate samba servers. Guest connections are and pass the appropriate parameter to the program. not often desired to shares containing data or to print- For example, to extract the files contained in the up- ers where page accounting has been enabled. It is pos- date named “hotfix1_i.exe”, the standard method sible to recreate this same type of behavior without would be run “hotfix1_i.exe /x” from a command maintaining two servers, but separation was deemed prompt. Please consult the service pack or hotfix necessary for management purposes. documentation for the correct syntax. 2.2. Patch Preparation 2.3. Script Implementation The updates discussed in this paper were released by Once machines are able to the access the updated files Microsoft and downloaded from the their web site (see from a central location, the next step is to automate the Appendix A). This section will discuss the preparation process of applying the patches. For this process, Perl of the archived files necessary to integrate the patches (see Appendix A) was chosen as the implementation into the model presented here. language. Reasons for selecting Perl include fast de- velopment time due to familiarity with the language A system update contains three basic components. on a Unix platform as well as the availability of mod- The first is the collection of updated files. This may ules to interface with specific Windows 95 / NT enti- include dynamic link libraries, executables, informa- ties such as the event log and the system registry. determine what OS we are running; ignored as comments as are blank lines. The “registry set the patch directory; key” field is the absolute path to a key in the local set the install method; system registry whose existence implies a previous open $patchdir\$patchFile; application of the patch. The hive key foreach ( entry in patch listing ) { HKEY_LOCAL_MACHINE is abbreviated as HKLM. split the entry into parts; if ( registry key does not exist ) { ; This fix corrects GETADMIN problem install the patch; HKLM\SOFTWARE\...\Hotfix\Q146965:admnfix } } Figure 4: Example patch listing entry. A portion of the registry key field has been deleted to prevent line if ( any patches have been installed ) { wrapping. execute rebootMessage; } Once the patch entry is read, it is split into its compo- nent parts. Using the given registry key, the program Figure 1: Patch32 algorithm checks for its existence in the local registry. The nonexistence of the registry key indicates that the As stated previously, the first thing that is necessary to patch has not been installed. If it does exist, then the install updates to an operating system is to determine patch has previously been applied and the program what version of the OS is currently running.