Kurt Seifried On The Danger Of Binary RPMs

Curious__George writes "Kurt Seifried on SecurityPortal (4-11-01) writes on a topic that deserves wider notice in the Linux world: The potential dangers of installing BINARY RPMs (as opposed to SOURCE RPMs). Here is the article in standard and printer-friendly versions." (Read more below.)

"He begins: 'I'm always amazed at the lack of articles on topics like RPM and PAM. These are basic systems components and tools that people use every day but which, generally speaking, are poorly understood (if at all). Prepare to be educated.. . . Generally speaking, RPM's must be installed as root, which means that RPMs can do anything on your system: install new files, overwrite files, reconfigure system settings, add new users, etc.

Why is this important? Because many people download RPMs from semi-trusted or untrusted sources and blindly install them.'

Curious George points out: "The potential for danger (with many newbies and not-so-newbies making use of binary RPMs from untrusted sources) is that Linux could develop an unwarranted reputation for problems by someone (or perhaps some Corporation?) purposely diseminating RPMs with built in vulnerablilities or exploits. We should do our part to educate and spread the word on this issue."

Comments

GPG RPM mini-mini howto

[mattdm]

1. Get the GPG key of the maintainer from a trusted source.

2. Add it to your GPG keyring using "gpg --import keyfile.txt"

3. Do "rpm -K somepackage.rpm".

4. If it's signed properly by someone on your keyring, it'll say "md5 gpg OK". If not signed at all, it'll just say "md5 OK". If signed, but not by someone you know, or if it's been tampered with, it'll say "md5 GPG NOT OK".

Er, sure, yah, okay.

[FFFish]

And these self-same newbies are going to be able to download source, *inspect the code for trojans*, and compile?

Security is as security does. Downloading a binary from an untrusted source isn't a whole lot more risky than downloading an indecipherable source code to compile.

Unless you're some sort of Code Hero, you just gotta trust that people aren't out to screw ya. I'll take the convienence of binaries over the P.I.T.A. of source, any day...

--

Re:Er, sure, yah, okay.

[HeghmoH]

The point is, options 1 and 2 are equally secure. There's nothing about source RPMs that make them better unless you're going to go through and examine every line of code. If you're just going to take standard precautions, then there is no difference, security-wise, between binary RPMs and source RPMs.

Re:Er, sure, yah, okay.

[Raven667]

It didn't get much mention, but if you get your packages from a trusted source and check the GPG signature you should be OK. Most of the article detailed all the problems you have getting packages from untrusted sources.

And these self-same newbies are going to be able to download source, *inspect the code for trojans*, and compile?

OK, here's a challenge, think of a better way. I'm not trying to be a PITA but there isn't any easier way to verify that you aren't installing a trojan. You have three options:

1. Install binaries from trusted sources, check GPG signatures.
2. Compile source packages, inspecting .spec file and patches, checking the MD5 sum or signature of the origional source tarball
3. Install binary packages from untrusted sources and eventually get trojaned.

If you can think of a fourth option, I would love to hear it

Unless you're some sort of Code Hero, you just gotta trust that people aren't out to screw ya. I'll take the convienence of binaries over the P.I.T.A. of source, any day...

Hey, I'm sorry man but look around you, this isn't the Internet of 10 years ago. I build firewalls for a living, a job that wouldn't exist if some people out there weren't out to screw other people, most time just for kicks. The phrase "Script Kiddie" would never have entered our lexicon.

This is the one reason that I recommend Linux distributions with large trusted package repositories (Debian) to new users, esp. if they aren't going to be doing much of their own system administration. There's nothing better than being able to just apt-get install any arbitrary piece of software that they hear about and have it just work.

Re:Er, sure, yah, okay.

[treke]

Yeah..I agree..but with source distribution you usually get README and INSTALL files that tell you exactly what is going to happen during the installation process.

If the RPM cant be trusted, then neither can the README or the INSTALL file. Even the source can't be trusted following this line of though. Might I recommend you read what Ken Thompson has written on the topic of trust? http://www.acm.org/classics/sep95/. Eventually you have to decide who you are going to trust, if the packages are from the softwares author, then I see no reason to doubt the RPMS above the source code. Same with the authors of your distribution. I'd be more wary about packages without any form of acknowledgment from someone related to the program itself.
treke
Fame is a vapor; popularity an accident; the only earthly certainty is oblivion.

You've got to trust somebody.

[landley]

Remember Ken Thompson's trojaned compiler that realised when it was recompiling itself and patched the trojan in so it wasn't anywhere in the source code?

It's possible to be paranoid enough to qualify for medication and STILL not be 100% sure they can't "get you". NSA spooks sniffing your monitor's EM radiation to see your screen. A virus in your flashable bios. Those fun kernel module rootkits you can't detect without a clean boot disk and a hex editor (which is a fun way to inspect a 40 gigabyte drive...)

Personal inpsection simply doesn't scale. It hasn't been a realistic option for anybody who couldn't afford to do it as a full time job since the days of the commodore 64.

What you do is you find somebody to trust who will do this for you. Then you have to trust them. If Red Hat doesn't do it, than somebody who makes a distro based on paranoia (Red Helmet?) will make money by being, basically, paranoid and proud of it.

Red Hat obviously isn't it. It installs nfs by default. It installs a network writeable LPR even if you haven't installed printer support. That's just wrong...

But RPM's are just Linux's equivalent of running normal programs under an MS os. You can get viruses/trojans/whatever we're calling the variant this week. That's what being root means, and some things HAVE to have that access. (By definition, configuring the system requires the ability to make changes to it. Why does this seem to suprise people?)

Rob

Who is a trusted source?

[winterstorm]

The problem still remains. It lies not with the technology but with the lack of a trusted source. Are there any existing systems for building RPM signature trust?

I have just registered TRUSTEDRPM.NET for the purpose of hosting an application to help build trust amoung RPM signers and users, assuming somethign doesn't already exist.

Re:Inadequate security model

[listen]

Unfortunately, a strap-on security model
is always very sucky. Look at ACLs on any
unix or even NT. Your model sounds like a
typical hacked up pile of shite.

What you want is capabilities.
See www.eros-os.org

Basically - a capability is an
unforgeable object reference.
In a true capability system,
that is the only way to do
anything outside your own address space.

This allows anyone to implement a very
simple security model which is much
easier to verify. It also gets
rid of all the dumb ass home grown
authentication systems on unix. (ie Each
app authenticating people in a funny way)

Re:signed rpm's help a little

[Menthos]

Umm, rpm has supported signed packages for quite some time now. Red Hat does sign all their packages using GPG. This is the signature information included with every official Red Hat update:

These packages are GPG signed by Red Hat, Inc. for security. Our key is available at:

http://www.redhat.com/corp/contact.html

You can verify each package with the following command:

rpm --checksig

If you only wish to verify that each package has not been corrupted or tampered with, examine only the md5sum with the following command:

rpm --checksig --nogpg

So it's not exactly a new idea :-)

The "problem" is also the "solution"

[coyote-san]

In this case, the "problem" can also be the "solution."

I've written some (Debian) packages which do nothing but set/clear the immutable flags of selected files when they're installed/removed.

Some examples:

lockdown-kernel will "chattr +i" the kernel images and modules, plus the configuration files used by the module loader. This helps stop installation of malicious kernel modules.

lockdown-users will "chattr +i" much of the user database. (Not /etc/shadow, for obvious reasons.) This helps stop malicious installation of users, or compromising existing ones.

lockdown-apt will "chattr +i" the configuration information used by "apt". This helps stop malicious modification of my system upgrade process.

lockdown-lib will "chattr +i" the core libraries, and the ldconfig information. This helps stop malicious modification of the core libraries - or the library search path.

I'm sure you get the idea. If I really do want to modify something, e.g., adding a user or installing a new kernel, I just remove the "lockdown" package, do the work, then reinstall it. This approach isn't perfect - unless I also change the capacities bounding set a malicious package can simply call "chattr" itself - but it's a good first step.

It's all about trust

[Pingo]

This rpm issue is simply not just about if RPM's are binary or source.

The issue is, can I trust this software to be free from trojans or other evil stuff?

It's like using credit cards, you will happily use your credit card at some well reputable store but will be reluctant to use it in some shady dark alley business.

It's just the same with software. A well known softwarehouse such as RedHat, SuSe, Mandrake ... have everything to loose if intentionally delivering shady software. Just look how anxious they are wat providing security updates to their products for faults that no one really can blame them for.

Also single persons with a good reputation such as Wietze can easily be trusted since this guy has so much reputation to loose if he intentionally does an evil act with his software. The same goes for other people that seems to be proud of what they are doing.

It's all about trust. You can trust the person or organisation that has much to loose if they provide software with trojans etc.

These softwarehouses signs all their RPM's cryptografically with the company key and you can easily check that it's a genuine package made in good faith.

//Pingo

Source vs. Binary

[psocccer]

I personally use source tarballs all the time, since slackware's "package" management is just tarballs with an installer bootstrap. Do I feel any less succeptable?

NO

Why? I'm using the source right? Well, it's not like every time I download a new program I inspect every line of code. That would be rediculous. I don't know how everyone else is, but if there is a configure script, hell, I won't even read the INSTALL file. If I can get it working the first time, I won't even read the README. I've been through enough 'configure ; make ; make install' cycles that I try what looks right first and ask questions later. And I'd bet most others do to. Which makes us all just as vulnerable to attack as the 'binary downloading newbies'.

Inadequate security model

[Animats]

The real problem is installing as root. The security model for most existing OSs, Linux included, is so weak that there's no real way to handle installs securely. But it could be done:

• NSA Linux mandatory security controls should be used.
• Files, processes, etc have an associated "integrity level" and "integrity compartment". Data cannot flow into an integrity compartment or upwards in integrity level except through the assistance of a trusted "upgrader/downgrader" program, which is seldom used and requires very explicit user invocation.
• Integrity levels might be KERNEL_INSTALL, KERNEL_CONFIG, TRUSTED, REGISTERED, UNTRUSTED, HOSTILE. Software running at a given level cannot affect data at a higher level.
• Each software vendor with a known digital signature gets an "integrity compartment". Installs go into that vendor's integrity compartment. The install program is thus locked out of affecting software from any other vendor. Such installs go in at REGISTERED level.
• Untrusted software gets a new integrity compartment for each install, and goes in at UNTRUSTED level. Games and web content work this way.

Basically, this doesn't let application A mess with application B's stuff. It enforces a rigid model on package structure, which may not be a bad thing. It forces vendors to clearly identify apps which need to mess with other apps, because they'll need extra privileges, which users might not want to give them.

How many people verify the signatures anyway?

[HuskyDog]

Mr Seifried may well be right when he says that checking the GPG signature is not totally secure, but I am sure that it is better then nothing. However, I never check the signature on any of the RPMs I download because I can't figure out how. I have read the "PGP SIGNATURES" section in the RPM man page but it doesn't make any sense to me. I would love to implement the fix in the security portal advisory refered to, but I can't understand it.

What I (and many other idiots) need is a step by step idiot's guide to getting RPM signature verification working. Someone must have written such a thing, does anyone know where to find it? It won't allow me to achieve the supreme security level advocated by Mr Seifried, but I will be much better off than I am now.

Red Carpet

[e_n_d_o]

I can't believe that there isn't a single mention of Red Carpet in this entire thread except for some poor bastard who got moderated down to "0".

The obligatory link:

http://www.ximian.com/apps/redcarpet.php3

Anyway, this is THE TYPE of product that is necessary for newbies to use Linux. It lets you install packages you have downloaded yourself in addition to providing "channels" which contain many of the packages you might want. It also alerts you to updated software (possible security fixes) in those channels. Before installing a package, it automatically checks crytographic signatures. I think that a product like this with access to a broader software library than Ximian provides would take a significant chunk out of this problem.


---