RE: Installation of software, and security. . .
Date: 07/20/05

  • Next message: Moritz Naumann: "Re: Anonymous Anonymity - Request For Comments"
    Date: Wed, 20 Jul 2005 09:02:55 -0400
    To: <>, <>

    Trojans embedded in installation scripts have been a problem in commercial
    space for many years, despite risk of exposure. I can recall a DBMS that
    installed its basic relational engine to run at elevated priority relative
    to everything else on the box, apparently in order to make itself look better,
    particularly in side by side tests with competitors. I can recall also various
    instances of commercial products adding backdoor accounts "for maintenance" without
    so much as a by-your-leave, and more. The more obscure the installation script,
    the greater the temptation to some outfits to put in functionality for their own
    convenience or advantage. Of course, with spyware now not blushing to add keystroke
    monitors and backdoors, simple jiggering with priorities sounds very tame indeed.

    The platform features to find out about this are still that there need to be ways
    to get install scripts to report what they would do, in detail, rather than
    actually altering anything on the box, and to unhide operations that otherwise
    might be kept quiet. Ideally this should be possible at any time to the box owner,
    regardless of the wishes of the installer, and there ought to be a further option
    to create a detailed log. The other necessary thing to get rid of such behavior by
    anyone is that disclosure of what is going on should be protected from legal
    challenge (so long as it is truthful) and should be paid attention to by the buying

    It is simply not true that commercial vendors are always clean here; even very
    large ones have sometimes strayed into underhanded behavior for many years.
    That almost nobody tries to (or even can) examine install operations before
    turning them loose just makes matters worse.

    Glenn Everhart

    -----Original Message-----
    From: Jason Coombs []
    Sent: Tuesday, July 19, 2005 1:16 PM
    To: Tim Nelson
    Cc: John Richard Moser; Klaus Schwenk;
    Subject: Re: Installation of software, and security. . .

    Tim Nelson wrote:
    > On Sun, 17 Jul 2005, John Richard Moser wrote:
    >> Yes, you hit the nail on the head with a jackhammer. One discussion on
    >> autopackage was that the devs don't want to limit the API and thus want
    >> the prepare, install, and uninstall to be a bash script supplied by the
    >> package "so it can do anything." I hate this logic. Why does it need
    >> to be able to do "anything"?
    > I think you're both right :). I agree that packages need to be able > to do anything, but it'd be nice if we could try to eliminate the pre
    > and post install scripts.

    Developers think that installers need to be able to do anything because
    the developers think of themselves as being trustworthy. The code
    written for an installer doesn't do anything harmful and it can be
    trusted, so why should it not have the ability to do anything that the
    developer decides it needs to do?

    All malicious attacks originate from the hands and minds of other
    people, malicious people, therefore a typical developer cannot see any
    harm in their own way of thinking or in their own installer. Even those
    developers who perceive an unacceptable risk or intrinsic flaw in the
    way that these things get built and deployed have a very hard time
    seeing themselves as responsible for the harm caused by others.

    The truth is that people who expressly allow systems that are harmful to
    continue to exist can be held responsible for the damage that those
    systems cause, regardless of the fact that the malicious actor who
    initiates the specific harm in each instance is somebody else entirely.

    See: Metro-Goldwyn-Mayer Studios Inc. v. Grokster, Ltd.

    Thus, if you are a developer and you deploy software without giving
    serious thought to the things that you could do to make the entire
    process of software distribution and installation safer for everyone,
    then you are part of the problem.

    Hopefully everyone can now see that applying digital signatures to code
    is a pointless exercise in somebody else's arbitrary business strategy
    (i.e. VeriSign and other purveyors of so-called 'federated identity
    solutions') and is not being used today as a means of achieving improved
    information security. A very sad state of affairs, given that signed
    code at least attempts to address these issues of security during the
    software installation/distribution process, albeit today's
    implementations as a rule are very poorly-conceived.

    We would all receive vastly-improved installation security if every
    software vendor would adopt a standard for code/data/installer
    authentication (that does not require digital signatures but that could
    optionally use them) based on a keyed hash algorithm and a low-cost
    specialized electronic device that sits on the desktop or in the server
    room alongside the box to which software is deployed and is used to
    verify hashes and explain forensically what the installer intends to do
    to configure the box and deploy the code and data to it.

    Of course that's just the ideal improvement, which I personally believe
    the industry could even train end-users to understand and use.
    Particularly if the proposed device were to generate an installation key
    that the user would be required to enter in order to install the
    software. (Sure, greedy people would try to use this to increase license
    revenue or improve controls over intellectual property and copyright;
    they will just have to be fought back by those who understand that the
    point is security not personal enrichment.)

    Short of the ideal stand-alone embedded system this concept could also
    be built as software-only. Does anyone care? Will anyone ever build it?


    Jason Coombs

    This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you

  • Next message: Moritz Naumann: "Re: Anonymous Anonymity - Request For Comments"

    Relevant Pages

    • RE: Base system install- eval: 3: Syntax error: newline unexpecte d (expecting ")")
      ... moved past the earlier problem area and was installing when I left it with no ... install scripts all night. ... USE_COMPONENTS, set in the main script, debootstrap, is empty. ... evaluate to paths that don't even exist on the CD or the installation ramdisk. ...
    • Re: Uninstalling djb daemontools, djbdns
      ... Debian packages. ... Follow the manual and install scripts backwards. ... Considering there isn't an installation script ... ... To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx ...
    • Re: Can extra processing threads help in this case?
      ... computers installed in the White House. ... after the installation, hordes of NSA-types descended on the White House to track down the ... This is yet a different form of physical security: the early "smart cards" had encryption ... Bandwidth for connected servers, the path of the data, ...
    • Re: lighting---hacked!
      ... the only possible security measure one might take. ... I made to turn off ipchains which we have only been running for about ... Take, in particular, the installation of ipchains, which is what ... >From the GUI interface and what documentation I had ...
    • Re: Software Distribution Service 3
      ... to a checkpoint prior to that installation. ... to restore prior to the checkpoint before this Windows Update was applied I ... your best bet would be to open a free support incident. ... security updates. ...