Re: freshmeat editorial about package management security issues
on Sat, May 06, 2000 at 03:56:27PM -0400%, Jeff Johnson said:
JeffC> What facilities does your package manager (or a third party
JeffC> add-on, such as autorpm) provide for automatic upgrading of
JeffC> installed packages?
JeffJ> rpm (and all package managers based on rpmlib) depend on
JeffJ> ordering based on epoch:version-release comparison in order
JeffJ> to identify the "newer" of two instances of a package with
JeffJ> the same name.
What I meant was: Does Red Hat provide the ability for a user to issue
a command that says, "Go get any new versions of the software I have
installed, and install them for me" as Debian does with APT, or can
this only be done with third-party tools such as autorpm?
JeffC> Who controls the package archives from which new packages
JeffC> are downloaded? If it's possible for third party archives
JeffC> to be used, does your package manager warn the user that
JeffC> packages are being downloaded from somewhere other than the
JeffC> official source?
JeffJ> Um, not applicable, as Red Hat packages are often the
JeffJ> "official source".
Red Hat only provides a limited subset of the software available in
the RPM format. On http://www.rpmfind.net/linux/RPM/ , users will
find all of these archives in addition to Red Hat versions and updates:
PowerTools
Perl CPAN
RedHat Contrib Net
Gnome Desktop Environment
Libc6 Contribs
Libc5 RedHat Contribs
Arch Independent RedHat Contribs
No Sources RedHat Contribs
RawHide
Conectiva Linux
HelixCode Gnome distribs
Mandrake
Mandrake Cooker
XBF X-Windows servers
SuSE
Linux/PPC
Yellow Dog PPC
OpenLinux
Caldera Contribs
TurboLinux
Archives for blind users
DLD
UltraPenguin
SGIlinux
LinuxM68k
Freshmeat
Coda
Beowulf
RPM.Org
Stuff on Rufus.W3.Org
Solaris packages on Real-Time.Com
RPMs for Cygwin32/Windows
and many of these have multiple subdivisions.
The question I was asking was: Since you obviously can't verify the
thousands of RPM files packaged by all of these distributions and
individuals, does rpm provide a warning like "This package has not
been prepared by Red Hat. While it's probably fine, we cannot confirm
that it will work with your system. Continue installation? [Y/n]"?
JeffC> Are there procedures in place to check for
JeffC> trojans/virii/etc. in the package itself (for example, in
JeffC> the scripts used to install the package)?
JeffJ> Signed rpm packages cannot be altered without being able to
JeffJ> detect the alteration. The scripts are part of the header,
JeffJ> which is signed, and so cannot be altered without being
JeffJ> able to detect the change.
I'm not asking about them being altered after the fact; I'm just
confirming that a procedure is in place to double-check the official
signed packages to confirm that, for example, a disgruntled employee
on his last day of work doesn't add "/bin/rm -rf /" to the preinstall
script of the binutils package and place it in the errata FTP space.
[Debian folks: This is even more of a question for you, since you're
accepting packages from people from all over, who may only have their
reputations, not their jobs and the threat of prosecution, hanging
over them and keeping them in line.]
JeffC> The answer to the previous question is naturally somewhat
JeffC> dependent on the nature of the trojan. As a worst case
JeffC> scenario: Is it possible for someone to insert a trojan
JeffC> into your upgrade stream which would disable your package
JeffC> upgrade system on the client side, making it impossible for
JeffC> you to distribute a fix through the normal method?
JeffJ> Signed rpm packages cannot be used as a vector for trojan
JeffJ> horses (assuming the installer checks the signature).
Let's say Joe Packager uploads a new package of sendmail to a contrib
directory. Jane User runs her automatic update script. It sees that
she has sendmail installed, spots Joe's package, and offers to install
it for her. Jane checks the signature. Yes, it's from Joe and has
not been tampered with, so she installs it.
A couple of days later, someone notices that sendmail has been altered
in this package to silently send copies of all mail to Joe and all his
friends. You put out warnings about it and distribute a package with
a version number higher than Joe's, so those people (like Jane) who
don't bother to read security lists will at least get the fix when
they run their update scripts.
Unfortunately, Joe's package also did something else: It replaced
/bin/rpm with a version that will not install any version of sendmail
or RPM other than Joe's. It will pretend to install your replacement,
but won't actually do it, so Jane will never know that her system's
been compromised.
You might say this really isn't your problem, because if people want
to be safe, they shouldn't install any packages that don't come from
you, but it isn't reasonable to expect that, since there's a lot of
software people want that Red Hat doesn't package (otherwise,
Mandrake, etc. wouldn't exist). People *are* going to be getting
their RPMs from other places.
Would you consider either of these valid solutions to the problem?:
1. Informing users when they're about to install a package that didn't
come from you.
2. Making certain core files untouchable by non-Red Hat packages, or
at least providing much stronger warnings like "WARNING! This
package, which is not an official Red Hat packages, wishes to
overwrite /bin/sh, which is a protected Red Hat file. This could
have dangerous consequences. Proceed at your own risk, and run rpm
again with --force if you really want to install this package."
Do you have any other ideas about what could be done?
Thanks,
Jeff
Reply to: