[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <42DD2A3D.4060907@roaringpenguin.com>
Date: Tue, 19 Jul 2005 12:28:45 -0400
From: "David F. Skoll" <dfs@...ringpenguin.com>
To: bugtraq@...urityfocus.com
Subject: Re: Installation of software, and security. . .
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"?
But who cares? Suppose you invent a package format that ONLY
allows packages to copy files into their final locations. And it doesn't
permit script execution, nor does it permit SUID or SGID files.
It's still dead easy to compromise the system. I can think of several
ways off-hand (all examples are UNIXy):
- Install a malicious startup script in /etc/init.d
- Install a malicious cron job in /etc/cron.d
- Install a malicious script in /etc/profile.d for those systems that use it
You're assuming that an installation mechanism that allows an attacker
to place whatever files he wants in whatever locations he wants is
somehow safer than one that also permits install scripts to run.
That's pretty naive.
Even if the package manager knows about /etc/init.d, /etc/cron.d and
friends and refuses to permit packages to drop scripts there, some
random package X might make use of a script or module directory that
a malicious package Y can drop files in.
Essentially, you should consider it just as dangerous to install software as
to run it.
Regards,
David.
Powered by blists - more mailing lists