Installation of software, and security. . .

From: John Richard Moser (nigelenki_at_comcast.net)
Date: 07/16/05

  • Next message: zinho_at_hackerscenter.com: "[HSC Security Group] Invision PowerBoard 1.3.x - 2-x Exploit and Patch"
    Date: Sat, 16 Jul 2005 02:52:39 -0400
    To: bugtraq@securityfocus.com
    
    

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    I just had some time to think, and I've come across something that
    bothers me a lot. I've been attempting to write a small reference that
    pools together all of the knowledge I've accumulated about security
    enhancements that can be minimally invasive and cooperate properly in a
    desktop environment, to design a system secure enough for server use but
    specifically friendly for home use.

    The goal of download-click-install software is a particular problem.
    Some stuff from another post I made elsewhere, but it's really good stuff.

    Starting from the ground up, we will examine the current path of
    installation in Windows and various package managers.

    Windows installation has two paths:

    A) A setup.exe program coded by some third party such as Real Networks
    or Nullsoft is executed with administrative privileges to modify the system.
    B) A .msi Microsoft Installer package is unpacked, and a script coded by
    some third party is executed with administrative privileges to process
    shell commands and possibly run a setup.exe program to modify the system.

    Debian follows a slightly different model consisting of multiple steps:

    1) dpkg unpacks a package.
    2) A pre-installation script coded by some third party is executed with
    administrative privileges to prepare (modify) the system or the package.
    3) dpkg copies files to the system.
    4) A post-installation script coded by some third party is executed with
    administrative privileges to configure the system for the package.

    Autopackage also has its method:

    1) The package is unpacked by autopackage. (if autopackage doesn't
    exist, the package is run as a script; but this is out of scope)
    2) A chunk of Autopackage is fed into bash so that it understands prep
    script and install script commands.
    3) The prep script coded by a third party is fed into bash to check
    dependencies. Whatever access the package manager has (administrative
    if installing to the system) are inherited by this script.
    4) The install scirpt coded by a third party is fed into bash to check
    dependencies. Whatever access the package manager has (administrative
    if installing to the system) are inherited by this script.

    The common factor in each of these methods is that third party code is
    run with privileged access before, during, or after the installation.
    This may be a problem.

    I fear that attempting to secure any desktop system may be a futile
    attempt if the package manager allows privileged execution of third
    party code during installation. Measures such as warning the user of
    SUID programs being installed and other good-practices (obviously a full
    audit would be best practice, but not feasible) are pointless if the
    program can simply do its dirty work in the preinstall and postinstall
    scripts, and get itself some SUID.

    Social engineering is a particularly difficult problem. It can't be
    fixed but it can be helped; the risks can be reduced. 99% of programs
    can run fine without SUID/privileged access, so normal users should be
    able to see that as a "red flag" in the same way they see chainletters
    and programs delivered in e-mails as "red flags" when they used to mail
    them around and run them. Nobody has to be a security expert, they just
    need a little help now and then.

    Does anyone else think there's a problem with how application
    installation is handled?

    - --
    All content of all messages exchanged herein are left in the
    Public Domain, unless otherwise explicitly stated.

        Creative brains are a valuable, limited resource. They shouldn't be
        wasted on re-inventing the wheel when there are so many fascinating
        new problems waiting out there.
                                                     -- Eric Steven Raymond
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.1 (GNU/Linux)
    Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

    iD8DBQFC2K60hDd4aOud5P8RAsx9AJ9Z1VQO8TU/Tmk/oKEuvGxfM0N9mwCZAaeL
    /omueksiNCE4as9rIdJMcyo=
    =THNa
    -----END PGP SIGNATURE-----


  • Next message: zinho_at_hackerscenter.com: "[HSC Security Group] Invision PowerBoard 1.3.x - 2-x Exploit and Patch"