BindView report on vulnerabilities in OS patch distribution

[Matt Power <mhpower () BOS BINDVIEW COM>]

The bugtraq mailing list and other security forums regularly announce
dozens of new security patches every month; however, there has been
little or no mention that there are substantial differences across
vendors in the extent to which their patch distributions offer
authentication and integrity protection. Over the past few months,
BindView Corporation has been working on identifying and pointing out
vulnerabilities in the processes by which operating-system vendors
distribute security patches. This effort has involved operating
systems from 27 vendors. More details are available in our report; see
http://razor.bindview.com/publish/papers/os-patch-sum.html

Our main focus has been on whether patch distribution is accompanied
by digital signatures (or, in general, some type of cryptographic
authentication). We found that the majority of the vendors studied do
provide digital signatures, most commonly via PGP or similar software.
Some of the changes that have occurred are:

  -- In the past, messages from IBM concerning AIX security issues
     (which may include patch locations and patch checksums) have not
     always been PGP signed. On 30 November 2000, we were told that
     "Henceforth, all messages from the AIX Security Team will be PGP
     signed with the Security Alert public key."

     Similarly, files under ftp://ftp.software.ibm.com/aix/ have not
     always had accompanying PGP signatures. On 30 November 2000, we
     were told that "From now on, my policy when sending patches and
     README-type text files to be put on our ftp site is to use
     detached PGP signatures only for binaries. ASCII files will use
     the incorporated PGP signature. All files we submit for posting
     will be PGP-signed."

  -- For the past several months, Caldera security announcements
     have been PGP signed with a key that has the userid

       Caldera Systems Security <security () calderasystems com>

     however, up until 10 November 2000, there was a file
     ftp://ftp.calderasystems.com/pub/pgp-keys/README stating that
     such announcements were signed using a key with the userid

       Caldera security <security () caldera com>

     (The first one has the KeyID 0x703FA9FC; the second 0x3DE7C2E9.)
     This possibly led to some degree of confusion about, or
     unnecessary distrust of, Caldera's signed announcements. That
     ftp site has since been updated with the correct key data.

When security announcements and related software updates are
accompanied by digital signatures generated with a recognized and
trusted signing key, users are in a much better position to verify
that they have obtained a correct patch, rather than a trojan horse.
Well-known trojan-horse software distributions in the past have
included the ones described at

  https://www.cert.org/advisories/CA-1999-01.html  (TCP Wrapper)
  http://www.securityfocus.com/archive/1/12103     (util-linux)

The existence of a digital signature does not mean that all
authentication concerns are addressed, since (for example) a file
might have a signature that is valid but was not actually made by the
key owner, or a file might have a signature that is not valid but one's
verification software (e.g., PGP) may itself be a trojan horse that
incorrectly reports a valid signature. Still, providing digital
signatures (ideally, ones that are generated off line) for security
patches is a practice that more vendors should adopt. A number of
vendors (including some that are Fortune 500 companies) are currently
not providing digital signatures or any similar type of authentication
for their patches. This is particularly a problem in situations where
host security on a patch-distribution server is not closely monitored.
Again, http://razor.bindview.com/publish/papers/os-patch-sum.html has
a link to our report with more details on this aspect of the issue.

Matt Power
BindView Corporation, RAZOR Team
mhpower () bos bindview com