Home page logo
/

bugtraq logo Bugtraq mailing list archives

Re: Installation of software, and security. . .
From: Klaus Schwenk <zooloo_0 () web de>
Date: Sun, 17 Jul 2005 21:52:42 +0200

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

I had some similar thoughts on that topic recently and do agree with you that
the current habit of installation handling has several problems.

First of all (at least on MS-based OS's) it's pretty hard to tell what exactly
is done by the installer. Even harmless software does not always keep a log of
its actions nor is it observed by some system service. As with malware and/or
malicious scripts it is relatively easy to hide inside the installer letting it
pass through virus detections and the like. In any case this may lead to
unwanted alterations to the system (be it with good or bad intentions).

Now this has been discussed more than once before (and I hope I did not annoy
too many of you), but besides common sense advise to not execute every program
Joe User stumbles upon there has been little to no effort to reduce the usage of
installation scripts/executables. Packet managers as found on *nix derivates are
imho a step in the right direction but need to be better at telling the user
what a specific packet will do exactly. As for Windows the situation is more or
like a complete mess. Far too many programs wouldn't need an installation in the
first place. And it's hard to give end users a rule of thumb on how to handle
installation programs when there is no real agreement on what installers should
(not) do. At least from my POV.

John Richard Moser schrieb:
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 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC2rcKlTx3gW8+0V4RAi92AKCOKpu/WvrS52yu/fl7/aGu85FUTwCfaoIi
MURxyuqvM4IP+4C0A5aNyq8=
=vGMC
-----END PGP SIGNATURE-----


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]