Blocking of Unsigned Binaries Not Present in White-listing Policy Appears to Fail in Older Versions of Windows

Products

• Embedded Security Critical System Protection

Issue/Introduction

When a white-listing policy is applied to a system running an older version of the Windows operating system (e.g. Windows XP) and one attempts to run an unsigned binary (e.g. the 1997 version of zip.exe or the post-1997 version thereof that was open-sourced under the name Info-ZIP), one may find that the binary still produces command-line output, whereas the same may not happen on a more recent version of the Windows operating system (e.g. Windows 7), giving the impression that the binary is not actually blocked in that older version of the Windows operating system.

Copyright (C) 1990-1997 Mark Adler, Richard B. Wales, Jean-loup Gailly,
Onno van der Linden and Kai Uwe Rommel.
Type 'zip -L' for the software License.
Zip 2.2 (November 3rd 1997). Usage:
zip [-options] [-b path] [-t mmddyyyy] [-n suffixes] [zipfile list] [-xi list]
  The default action is to add or replace zipfile entries from list, which
  can include the special name - to compress standard input.
  If zipfile and list are omitted, zip compresses stdin to stdout.
  -f   freshen: only changed files  -u   update: only changed or new files
  -d   delete entries in zipfile    -m   move into zipfile (delete files)
  -R   recurse into directories     -j   junk (don't record) directory names
  -0   store only                   -l   convert LF to CR LF (-ll CR LF to LF)
  -1   compress faster              -9   compress better
  -q   quiet operation              -v   verbose operation/print version info
  -c   add one-line comments        -z   add zipfile comment
  [email protected]   read names from stdin        -o   make zipfile as old as latest entry
  -x   exclude the following names  -i   include only the following names
  -F   fix zipfile (-FF try harder) -D   do not add directory entries
  -A   adjust self-extracting exe   -J   junk zipfile prefix (unzipsfx)
  -T   test zipfile integrity       -X   eXclude eXtra file attributes
  -!   use privileges (if granted) to obtain all aspects of WinNT security
  -$   include volume label         -S   include system and hidden files
  -h   show this help               -n   don't compress these suffixes

(unexpected output shown on Windows XP, in spite of zip.exe not having been added to a white-list policy)

Environment

Symantec Embedded Security: Critical System Protection 

Cause

SES:CSP works by inserting correct hooks in the operating system. More precisely, the SES:CSP Windows drivers insert callbacks in the operating system to be made aware of when a process gets launched. This mechanism is dependent upon the vagaries of the operating system and in a re-design of the OS, it is expected that some aspects of these callbacks will  change, as happened across pre-Windows Vista operating systems (e.g. Windows XP) and post-Windows Vista operating systems (e.g. Windows 7). Since the nature of these callbacks change, the handling of these also necessarily change. It is this handling that manifests itself in the behaviour seen across XP and Windows 7. To elaborate a little, the callbacks in post-Windows Vista (e.g. Windows 7) are more effective and allow us to exercise a greater degree of control on an application launch then what we experience in a pre-Windows Vista environment (e.g. Windows XP). It is this degree of control that results in the variance of the observed behaviour.

Resolution

To illustrate the above, the source code of zip.exe was downloaded and compiled on a system. The pseudo code looks as follows:

Main function, aka, start of zip.exe
Check for number of command line arguments passed
If zero, print usage text
If more than one, do whatever.
 
Like its 1997 predecessor, this version of zip.exe gets routed to the deny_ps sandbox, which is a sandbox that has no access to any resource. To further illustrate that this causes no lack of enforcement, the zip code was updated with the following code, then compiled and deployed to a Windows XP system:

Main function, aka, start of zip.exe
Check for number of command line arguments passed
Open a file and append text to the file
If zero, print usage text
If more than one, do whatever.
 
Now, if the step "Open a file and append text to the file” were to run, then it would mean that enforcement was lacking (i.e. although the application is not present in the white-list, it is still executed and able to modify the state of the system). However, the test showed this was not the case. The enforcement was correct and the file write request was denied, as it should be.

Other applications were tested on Windows XP and found they were blocked in a similar way as on Windows 7. The 1997 version of zip.exe and its open source successor (Info-ZIP, which lives on until this day) were the only applications with which it was possible to elicit this behavior, but this does not exclude the possibility there may be other applications that show a similar behavior. As explained above, this is due to the specifics of older Windows operating systems and there is no cause for alarm, as restrictions will still be correctly enforced, regardless of the perceived behavior.