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. The fol- does not attempt to install it. Because of the frequency lowing segment of code will return all the information with which the patch program will be run, it is neces- needed. sary that the script be efficient when evaluating the current state of the client. Therefore no attempt is ($osString,$majorVer,$minorVer,$osBuild, made to verify the integrity of previously installed $osId) = Win32::GetOSVersion (); updates or to examine the version of installed files. The “install patch directory” field is the name of the $osString OS revision string directory containing the update. This is a path relative $majorVer Major version number to the previously determined OS specific patch direc- $minorVer Minor version number tory and will be used during the patch installation pro- $osBuild OS build number cess described in the next section. $osType integer (win32s = 0; Win95 = 1; WinNT = 2) Figure 2: Win32::GetOSVersion() and return values 2.4. Patch Installation
The OS specific patch location is determined by test- During the development of Patch32, one goal was to ing $osType and then creating a directory path by provide a method of deploying new patches with catenating the Patch32 root directory specified at the minimal effort. By default, all Windows NT hotfixes beginning of the script with the OS name (either win95 released by Microsoft store a patch identification or winnt) and $osBuild. For example, Windows 95 number in the following registry key OSR1 has a build number of 67109814. The full path to the correct patches would be HKEY_LOCAL_MACHINE Software $basedir\win95\67109814 Microsoft Windows NT From this patch directory, the program will open a list CurrentVersion of updates to be applied to the client. The format of a Hotfixes patch listing entry is given below.
Each entry is delimited by a carriage return. Lines HKEY_LOCAL_MACHINE beginning with a semicolon (;) or a pound sign (#) are Software Microsoft rundll.exe setupx.dll Windows NT InstallHinfSection 132 CurrentVersion DefaultInstall
The existence of an installed service pack may then be update.exe -z -u –q
The last issue to be resolved is to guarantee that the 3.1. Permissions client machines will execute the patch script on a regular basis. This program must be run during the operating system boot process but after network sup- When run under Windows NT, the patch program must port has been enabled. run as a local administrative account in order to update system files. This results in three security issues that Windows 95 clients are able to run the program during must be addressed. These are the integrity of the patch a domain login script or from the files themselves and their associated setup programs, the security of the registry keys which are defined by HKEY_LOCAL_MACHINE the system updates and the security of the batch file Software run by the AutoexNT service. Obviously the last two Microsoft issues are irrelevant in Windows 95 since such access Windows control does not exist and because the AutoexNT RunOnce service is not used. registry key which can be set using a remote update of In order to insure the integrity of the update packages, the system policies. write access to the files should be restricted to admin- istrative accounts only. Without this protection, a vi- In order to install updates on Windows NT clients, the rus or Trojan Horse program could easily be distrib- update program must have administrative privileges on uted to clients by modifying the patch files on the the local host. Therefore the patch program may not server. be run during a normal user’s domain login script. The Windows NT 4.0 Server Resource Kit contains a It is also important to maintain the security of the sys- service utility named AutoexNT that, upon start up, tem registry keys created by the updates because these executes a batch file named %SYSTEM- are the only means by which the Patch32 program can ROOT%\System32\AutoexNT.bat. By configuring the determine whether or not an update has been installed. service to start up automatically, AutoexNT.bat will be If the security of these keys were comprised, it would executed during the boot process. It is from this batch be possible to avoid the installation of an update sim- file that the Patch32 script is launched. By running the ply by creating the correct registry key. It is important AutoexNT service under a local administrative ac- to remember that the patch script makes no attempt to count, the program is able to update system files and verify the status of currently installed patches. It is not settings. technically difficult to perform this type of system examination, but would result in an increased execu- tion time and degraded system performance. @echo off set LOG=%SYSTEMROOT%\log\autoexnt.log The last security issue to address is the AutoexNT set PERL=\\GUESTSERVER\perl\bin\perl.exe service. As stated previously, this service runs as a set PATCH32=\\GUESTSERVER\bin\patch32.pl local administrative account and executes the contents of the AutoexNT.bat file whatever they may be. It is therefore extremely important that only administrative echo :::::::::::::::::::: >> %LOG% accounts be allowed to modify this file for reasons date /t >> %LOGFILE% similar to those given for ensuring the integrity of up- time /t >> %LOGFILE% dates packages. echo :::::::::::::::::::: >> %LOG% net start LanManWorkstation >> %LOG% %PERL% %PATCH32% >> %LOG% 3.2. Logging
In a distributed environment, it is important not only to Figure 8: Example AutoexNT.bat script be able deploy updates effectively, but also to be able to determine which machines were successfully up- dated and those which failed. Patch32 supports log- ging to the Windows NT EventLog via Perl’s Another possibility of expanding the current installa- Win32::WriteEventLog() function. tion method would be to determine it based on the OS build number. Then each version for Windows 95 and 3000 The patch32 script completed Windows NT would have a separate method for in- successfully stalling updates. This would be most helpful when 3001 The patch32 script failed supporting Windows NT 3.51 and 4.0 clients from the 3002 The %1 patch was installed same server. successfully 3003 The %1 patch installation failed 5. Conclusion and Future Development 3004 The system was rebooted due to patches having been applied In conclusion, the Patch32 system provides a flexible means of deploying system updates to Windows 95 Figure 9: Patch32 EventID’s and descriptions. and Windows NT clients on a regular basis. Thus far Patch32 has been implemented to manage Windows NT 4.0 and Windows 95 clients, but has also been 4. Customization tested with Windows NT 3.51, Windows NT 5.0 Beta 1 and Windows 98 clients. The current system sup- During the initial installation, Patch32 requires that ports over two hundred Windows 95 machines and certain variables, which determine paths to OS up- approximately forty Windows NT 4.0 Workstations. dates, be defined. These variables, located at the be- ginning of the source file, allow the administrator to One issue that arose from the experience of imple- specify the base location of the Patch32 directory hier- menting this system is the question of ‘What is a archy and the install methods and parameters for Win- patch?’ A system update is really nothing more that a dows 95 and Windows NT updates. The server ad- reconfiguration of the client machine. Files and regis- ministrator may also choose to modify the reboot mes- try keys are created, updated and deleted. In essence, sage that is executed upon the successful application this is software installation. It is perceivable that the of an update. Patch32 system could be used to configure software packages on client machines. This, however, is left as One advantage to Patch32, besides the fact the all an exercise for the reader. software components are freely available, is that the patch script itself is very short, about two hundred lines at the time of this writing. Because the code is Appendix A: URL’s easy to understand, site specific changes can be made easily. This makes Patch32 extremely flexible. For example, one of the many, freely available SMTP con- This section lists relevant URLs for freely available sole mail programs such as Blat (see Appendix A) software discussed in this paper. could be used to augment the system’s current logging abilities. In this way, network administration would be Samba is available under the GNU General Public notified via e-mail upon update completions or fail- License and comes with full source code. Information ures. is available at http://samba.anu.edu.au/samba.
The patch installation method is also very flexible. The Microsoft OS updates for Windows 95 and Win- The current configuration at the College of Engineer- dows NT are available from Microsoft’s web server ing uses methods available with the updates released and FTP server. See http://support.microsoft.com and by Microsoft. A simple alternative to this would be to ftp://ftp.microsoft.com/bussys/winnt/winnt-public/ use a batch script named “update.bat” that would exe- fixes. cute specific patch installation programs. This would provide the ability to have an individual installation ActiveState distributes Perl5 for Win32 which avail- mechanism for each OS patch. The only restrictions able at http://www.ActiveState.com. would be that the update program runs non- interactively under Windows NT and that it creates the All source code for the Patch32 system are available registry key necessary to allow future executions of on-line as will be future versions. See Patch32 to determine its existence. http://www.eng.auburn.edu/users/cartegw/Patch32 for References information about obtaining the files. [1] Windows NT 4.0 Server Resource Kit, Blat is a public domain console SMTP mailer for the Microsoft Press, Redmond, Washington, win32 platform. It is designed to run under Windows 1996. ISBN 1-57231-344-7 NT and comes with full source code. Visit http://gepasi.dbs.aber.ac.uk/softw/blat.html for more information.
Appendix B: Patch32 source listing
####################################################################### # Filename : patch32.pl # Author : Gerald ( Jerry ) Carter # [email protected] # Date Created : November 17, 1997 # Last Update : June 6, 1998 # # ATTN: Some lines have been wrapped for readability. The real # source may be downloaded from # http://www.eng.auburn.edu/users/cartegw/Patch32 # # Perl5 for Win32 script to patch Windows 95 / NT clients on the # College of Engineering network. Client supported are # Windows 95 OSR1, OSR2, OSR2.1 # Windows 98 # Windows NT Workstation 3.51, 4.0, 5.0 Beta 1 # # The following variables must be set for each OS # $basePatchDir Base directory of all patches # $patchDirectory Location of the patch files # $installPatch Patch installation method # $installParameter Patch install parameters # $rebootMessage win32 command that will run if any # patches are installed # # $installPatch . $patchDirectory . '\' . $pSourceDir . # '\' . $installPatchParameter # # ======# LICENSE # ======# This program is free software; you can redistribute it # and/or modify it under the terms of the GNU General Public # License as published by the Free Software Foundation; either # version 2 of the License, or (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public # License along with this program; if not, write to the Free # Software Foundation, Inc., 675 Mass Ave, Cambridge, # MA 02139, USA. # #######################################################################
# Needed module for registry functions use Win32::Registry; # Setup some script variables $DEBUG = 1; $reboot = 0; $eventLog = 0; $eventSource = "Patch32"; $computer = $ENV{'COMPUTERNAME'}; $eventLogFile = "Application";
####################################################################### # Script variables - Fill these in with values appropriate for # your site
# Base patch directory $basePatchDir = "\\\\ivy\\patch32";
# Win95 patch install method $win95InstallPatch = 'rundll.exe setupx.dll,InstallHinfSection DefaultInstall 133 ';
# Win95 patch install method parameter $win95InstallPatchParm = 'install.inf';
# Win95 reboot message to be executed if patches are applied $win95RebootMsg = "$basePatchDir\\win95\\w95upd.exe";
# WinNT patch install method $winntInstallPatch = '';
# WinNT patch install method parameter $winntInstallPatchParm = 'update -z -u -q';
# WinNT reboot message to be executed if patches are applied $winntRebootMsg = "start $basePatchDir\\winnt\\shutdown /l /y /r /t:30 \"Patches completed. System rebooting.\"";
#######################################################################
# First we must determine what OS we are running ($osString, $majorVer, $minorVer, $osBuild, $osId) = Win32::GetOSVersion (); if ( $DEBUG >= 2 ) { print "ID = $osId\n"; } # win32s if ( $osId == 0 ) { print "Can't patch win32s!."; exit ( -1 ); } # Windows 95 elsif ( $osId == 1 ) { # Print the OS information print "OS version is Windows 95$osString.\n";
# Set the $patchDirectory $patchDirectory = "$basePatchDir\\win95\\$osBuild"; $installPatch = $win95InstallPatch; $installPatchParameter = $win95InstallPatchParm; $rebootMessage = $win95RebootMsg; } # Windows NT elsif ( $osId == 2 ) { # Needed by Windows NT EventLog require "NT.ph";
# Print the OS information print "OS version is Windows NT $majorVer.$minorVer "; print "(build $osBuild: $osString)\n"; $patchDirectory = "$basePatchDir\\winnt\\$osBuild"; $installPatch = $winntInstallPatch; $installPatchParameter = $winntInstallPatchParm; $rebootMessage = $winntRebootMsg;
$eventLog = 1; Win32::OpenEventLog ( $ntlog, $computer, $eventLogFile) || warn $!; } # Unknown else { print "Unable to determine what OS we're running!\n"; print "Script exiting...\n"; exit ( -1 ); } if ( $DEBUG >= 1 ) { print "Patch Directory = $patchDirectory\n"; print "Install Patch method = $installPatch\n"; print "Install Patch parameters = $installPatchParameter\n"; print "Reboot Message = $rebootMessage\n"; }
# Now we are ready to gread the patch.list file open ( PATCHLIST, "$patchDirectory/patch.list" ) || die $!;
# Now we loop through the listing of patches while ( $patch =
# Check for comment $tmpChar = substr ( $patch, 0, 1); if ( ("$tmpChar" ne ";") && ($tmpChar ne "#") ) {
# Get the individual patch information chop ( $patch ); ( $pRegKey, $pSourceDir ) = split ( /:/, $patch );
# ...This should be able to handle other hives as well as HKLM... # ...a kludge for now... $pRegKey =~ s/HKLM\\//; $regObject = $HKEY_LOCAL_MACHINE;
# If we can open the given registry key, then we assume that # the patch is in place and go on if ( $pRegKey ne "" ) { if ( $DEBUG >= 2 ) { print "Patch Registry Key = \n $pRegKey\n"; print "Patch Source Directory = \n $pSourceDir\n"; } if ( $regObject->Open ( "$pRegKey", $patchVer ) ) { print "Patch $pSourceDir already installed!\n"; } else { $reboot = 1; print "Installing $pSourceDir...\n"; $installTmp = $installPatch . $patchDirectory . "\\" . $pSourceDir . "\\" . $installPatchParameter; print "$installTmp\n"; system $installTmp; print "\n"; if ( $eventLog == 1 ) { if ( $regObject->Open ( "$pRegKey", $patchVer ) ) { Win32::WriteEventLog ( $computer, $eventSource, &EVENTLOG_SUCCESS, &NULL, 3002, &NULL, 0, "$pSourceDir" ); } else { Win32::WriteEventLog ( $computer, $eventSource, &EVENTLOG_ERROR_TYPE, &NULL, 3003, &NULL, 0, "$pSourceDir" ); } } } } } }
# Check to see if we installed patches if ( $reboot ) { system $rebootMessage; if ( $eventLog == 1 ) { # Event : rebooting the system Win32::WriteEventLog ( $computer, $eventSource, &EVENTLOG_INFORMATION_TYPE, &NULL, 3004, &NULL, 0, "" ); } } if ( $eventLog == 1 ) { # Event : Successful script completion Win32::WriteEventLog ( $computer, $eventSource, &EVENTLOG_INFORMATION_TYPE, &NULL, 3000, &NULL, 0, "" ); Win32::CloseEventLog ($ ntlog ); } exit (0);
########## end of patch32.pl ########################################## #######################################################################
Appendix C: Example patch.list
; ; Patch listing for Windows NT 4.0 ( build 1381 ) ; ; Author : Gerald ( Jerry ) Carter ; [email protected] ; College of Engineering Network Services ; Auburn University ; Date Created : February 20, 1998 ; Last Update : June 1, 1998 ;
; Service Pack 3 HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\ServicePack3:sp3
; This fix corrects GETADMIN problem HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\Q146965:admnfix
; This fix corrects the chargen/telnet port issue (135) HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\Q154460:chargen
; Workaround for Pentium problem with invalid opcode HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\Q163852:pentfix
; Fix for newtear and bonk attacks. Also ICMP attacks HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\Q179129:tearfix
; This fix is for lsahack.exe problem.. Also increased encryption on ; the LSA secrets in the registry. HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\Q184017:lsa2fix