Home page logo
/

bugtraq logo Bugtraq mailing list archives

RE: Installation of software, and security. . .
From: "Burton Strauss" <Burton () SmallNetSolutions com>
Date: Mon, 18 Jul 2005 17:35:48 -0500

Remember, if you DID NOT require 'root' access to install a privileged
binary, that in itself represents a major privilege escalation hole.  So the
reality is that to install software (binary or source you compile yourself)
- regardless of platform - at some point you need to access privileged
system resources (whether that's /usr/sbin/ or the Windows registry doesn't
matter).

That is precisely why you should only install binary packages from reputable
sources and why said reputable sources should sign their package such that
you can verify that the downloaded file is in fact the one you expected to
receive (this is typically through some form of a hash value or signature).

How many of us actually do this?  That's a matter for another thread...


As to why you need the option to 'do anything'?  It's because there is no
simple set of transformations that everyone agrees on which are required as
part of an installation.  Start simple:

  Write to the binary directory.  Ok, what are they?  That's distribution
dependent (/usr/sbin, /sbin/, /opt/sbin, what???)
  Create a user/group.  Remember, different distributions have different
structures for users (RedHat's user-specific groups)
  Change file ownership.

etc., etc., etc.

Keep building the list.  But remember: Anything you forget to permit will
cause some package, somewhere out there to fail to install.  And that's why
most packaging processes allow unlimited scripting.


-----Burton 



-----Original Message-----
From: John Richard Moser [mailto:nigelenki () comcast net] 
Sent: Sunday, July 17, 2005 3:09 PM
To: Klaus Schwenk
Cc: bugtraq () securityfocus com
Subject: Re: Installation of software, and security. . .

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



Klaus Schwenk wrote:
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

Exactly my point.  How do you manage or reduce risk when you can't even tell
what changes are to be made?  An executable has to be run to truly
understand its actions; scripts can self-modify (variables run as code),
executables can have odd logic that obfuscates things from heuristics
examinations.  You can't make an auditing tool to list all changes about to
be made and actions to be taken by installing the program (aside from a
spare machine and a debugger).

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

Flaw in the virus scanner but eh.

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).


Yes, evil.  Nuff said.

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

Package managers found in Linux typically run a pre-install script to
prepare the system, and a post-install script to post-configure the system.
These scripts are bash scripts run as root.

Installing blackdown java on Debian or Ubuntu is something you have to be
very careful about.  The pre-install asks about licensing; if you say "No"
it stores that you refused the license agreement in a debconf database
somewhere and aborts the install.  You can try to install the package again,
but it will abort.  All combinations of --purge and manually editing the
dpkg database do nothing.  I couldn't find the debconf settings database
thing it used, so I had to reinstall the system.

That pre-install script could very well have 'dd if=/dev/urandom
of=/dev/hda' and that would be it (I'm on sata so it'd be /dev/sda).

It's a step in the right direction; files are copied where they go by the
package manager.  Problem is, other files can be copied around by the
scripts too, and the PM won't remove those.

what a specific packet will do exactly. As for Windows the situation 
is more or

It will install X files, and run some script that you can read, but probably
won't understand.

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.


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"?

<snip />


  By Date           By Thread  

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