Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Auto-updating and security.

By Inoshiro in Technology
Sun May 14, 2000 at 02:23:24 AM EST
Tags: Security (all tags)
Security

Freshmeat has an article discussing some of the security implications of automatically updating your system.

I think this would be of interest, considering the number of people who talked about auto-updating with Debian and Redhat when I posted the "Auditing Kuro5hin" piece.


The formatting leaves a bit to be desired, but it's interesting because the author actually discussed the issue with Debian and Redhat people. The first thing the Debian fellow points out is that unless you verify signatures or hand-audit the code, the 'old-timers' don't gain anything from grabbing random tarballs versus regular grabs of unchecked binaries :-)

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o Kuro5hin
o Freshmeat
o Freshmeat [2]
o an article
o Auditing Kuro5hin
o Also by Inoshiro


Display: Sort:
Auto-updating and security. | 17 comments (17 topical, editorial, 0 hidden)
:The formatting leaves a bit to be ... (4.00 / 2) (#4)
by Qtmstr on Sat May 13, 2000 at 08:16:48 PM EST

Qtmstr voted 1 on this story.

:The formatting leaves a bit to be desired, but it's interesting because the :author actually discussed the issue with Debian and Redhat people. The :first thing the Debian fellow points out is that unless you verify signatures :or hand-audit the code, the 'old-timers' don't gain anything from :grabbing random tarballs versus regular grabs of unchecked binaries :-) True, but merely looking at which libraries ./configure checks for and which libraries are actually linked can be helpful, e.g., "This is a CD Player! Why is it linking against SDL, SomeEncryptionLibrary, and e2libs?!!?"


Kuro5hin delenda est!

Re: :The formatting leaves a bit to be ... (none / 0) (#7)
by pretzelgod on Sun May 14, 2000 at 05:56:15 PM EST

Checking the dependencies of a package would tell you the same thing checking the output of ./configure would tell you about what libraries the package uses.

-- 
Ever heard of the School of the Americas?


[ Parent ]
Re: :The formatting leaves a bit to be ... (none / 0) (#12)
by Qtmstr on Mon May 15, 2000 at 01:47:28 AM EST

It would be possible to create an rpm that did not list all its actual dependances, whereas it would be impossible to create such a program that did not link to the appropriate libraries.


Kuro5hin delenda est!
[ Parent ]
Re: :The formatting leaves a bit to be ... (none / 0) (#17)
by bafungu on Wed Sep 20, 2000 at 02:01:07 PM EST

./configure is a script. It can do absolutely anything the wicked writer desires. Certainly it can suppress what libraries will get linked to, including making the generated Makefiles lie about what they're really doing.

For example, this makefile:

all:
        @echo cc foo.o -o foo
        @touch h4x0rd;sleep 2
will look like it's linking a "foo" program when you run make, whereas in fact it creates a file "h4x0rd" in the current directory and pauses a bit to make you think it's linking.

[ Parent ]
In my opinion, auto-updating first ... (3.00 / 1) (#1)
by Perpetual Newbie on Sun May 14, 2000 at 12:48:48 AM EST

Perpetual Newbie voted 1 on this story.

In my opinion, auto-updating first requires that you either have complete confidence in your source of update packages, or a complete lack of confidence in yourself to be able to update your system. As a Windows user, I delete or disable any auto-update feature that I see.

This is a nice article, very good reading.

I don't like autoupdate, I could se... (2.50 / 2) (#3)
by slycer on Sun May 14, 2000 at 12:56:22 AM EST

slycer voted 1 on this story.

I don't like autoupdate, I could see how there could be securtiy issues with it. But, when it comes to my system.. I am a control freak, that's why I use Slack :-)

Not to start a distro war discussion though..

just plain boring... (1.00 / 7) (#2)
by Ticker on Sun May 14, 2000 at 01:00:17 AM EST

Ticker voted -1 on this story.

just plain boring

Foo (3.60 / 5) (#5)
by henrik on Sun May 14, 2000 at 12:54:18 PM EST

I guess that'd be me.. :)

I personally think the risk that someone has compromised the debian (or redhat) servers is a lot smaller than the risk of having a system running with a well known hole.

The fact is that it's easy to miss a security announcement, and to continually upgrade everything that's been found to have a hole. If someone else takes care of finding the holes, and then packages it so that it can be easily included on my system with one command, it's just so damn convenient it's hard not to get used to it.

As for all the security problems with trusting binary packages - as you point out, they are the same even if you do it yourself.. (how many people even look at the code before compiling?)

-henrik

Akademiska Intresseklubben antecknar!

Re: Foo (3.25 / 4) (#6)
by rusty on Sun May 14, 2000 at 03:37:51 PM EST

Maybe the best solution for the paranoid sysadmin would be a not-quite-auto update. Instead of updating the system, your updater would look for security fixes, download all the necessary packages, and then email you (or ping your cell phone or pager or watever will get your attention) and say "Hey! I have the following security holes: ... And the following packages have been downloaded and are all ready to update: ... . Press "go" to continue!" Not precisely that, but that's the idea. Build in MD5 checks and the ability to stop the update at the last step and confirm with the admin that it's ok, and I think you've got a winner.

____
Not the real rusty
[ Parent ]
Re: Foo (2.00 / 1) (#13)
by henrik on Mon May 15, 2000 at 08:05:57 AM EST

That's an excellent idea... It'd be a real selling point for the first dist that included it. It shouldn't be too hard to implement ontop of apt either. Hmm.. :)

-henrik

Akademiska Intresseklubben antecknar!
[ Parent ]

Semi-auto (4.00 / 2) (#8)
by kmself on Sun May 14, 2000 at 06:10:02 PM EST

Running Debian GNU/Linux, I use a semi-automated update procedure, updating package lists and downloading updates on a regular basis via cron scripts, but running the updates themselves manually. Debian actually enforces this policy as the installation process (to borrow my favorite phrase from Postcards From the Edge), needs you to be there for it. No surprises behind your back. I'm occasionally bitten by misbehaving packages, but not debilitated. No trojans (yet).

Both these systems are personal workstations, and I'm running a Potato/Woody mix (frozen/unstable) mostly. For a production server, I'd stick to stable and update on an as-needed bases for security/stability purposes only. These are more sandboxes for me to play with.

--
Karsten M. Self
SCO -- backgrounder on Caldera/SCO vs IBM
Support the EFF!!
There is no K5 cabal.

Re: Semi-auto (4.50 / 2) (#9)
by rusty on Sun May 14, 2000 at 06:14:40 PM EST

Ah. Good to see that there is such a system as I suggested. This seems like the most sensible way to handle it, to me. Granted, this is the advice of a bad sysadmin so don't take my word for it. :-)

____
Not the real rusty
[ Parent ]
Re: Semi-auto (4.00 / 2) (#11)
by Pseudonymous Coward on Sun May 14, 2000 at 09:53:34 PM EST

Running Debian GNU/Linux, I use a semi-automated update procedure, updating package lists and downloading updates on a regular basis via cron scripts, but running the updates themselves manually.

This isn't far from what I do, except that I also mirror nightly the current distribution with rsync. This lets me poke and prod at a .deb, if I feel the need to, and I could easily set up a cron job that lets me know nightly what would be updated if I did an apt-get upgrade at any given moment.

Anyhow, the point is that the problem of automated updates is solved: Debian's apt is the most powerful package management tool I've used, by a long shot, and this stuff was obviously well considered during the design of dpkg and apt. How you approach your security is up to you, but the tools are in place and regularly improving. It seems signed .debs and Packages files are in the works already.

[ Parent ]

Signed debs? (4.00 / 4) (#10)
by kmself on Sun May 14, 2000 at 06:28:21 PM EST

One issue I've wanted to see addressed, but haven't, is why Debian packages aren't signed. It's the largest single weakness, and my one real complaint, against the whole Debian package system.

From the article, Jason Gunthorpe writes:

Red Hat has a single (hopefully) well-secured signing key that can only be used for packages that they produce in house. This is feasible for them because their development is concentrated in one physical location, and they don't have the constantly-changing archive like we do

Debian has a similar key kept by the Security Team, but it is infeasible to sign every official package that is created with this key, particularly since there are hundreds of new packages produced every single day. (Though we have been talking about signing full releases with this key.)

So, in the Debian situation, the next logical option is to use the maintainer's personal key for signatures. This brings up the really interesting question of 'who should sign a package'. With some 500 signing keys, the security of the whole scheme is in question. It is entirely possible to trojan an important package like libc using the most weakly secured key out of the 500.

This same problem can be applied to upstream source packages, too. If someone downloads a package, he can check the signature, but he also has to check the key.

The main point here is that just slapping a signature on packages does not necessarily make them as safe as the cryptosystem being used, or any safer than not having a signature.

The scheme I'd favor would be for a single-key signature for a full, stable release, and for the package-maintainer signature for development releases and individual packages. Yes, there are a lot of keys to track, but the number is finite, and a list of valid keys and/or a package/key crosswalk would be incorporated, or so it seems. The packaging system would then verify the signature, check that the proper signature was used, and report to the user any discrepencies. What weaknesses are there with this system?

There is obviously a problem with keeping the key list and crosswalk list current, and the list itself must be kept secure or otherwise validated.

For more information, see the Debian Weekly News article on the topic, and this list archive article (which has a good salesman joke to boot).

--
Karsten M. Self
SCO -- backgrounder on Caldera/SCO vs IBM
Support the EFF!!
There is no K5 cabal.

FreeBSD's method (4.00 / 2) (#14)
by battery841 on Mon Sep 18, 2000 at 08:10:15 PM EST

I believe that FreeBSD has a pretty nice idea.
For those who don't know, FreeBSD uses ports. Which automatically downloads tarballs, compiles them, and resolves dependencies quite nicely. If I remember right, ports checks MD5 checksums on download, before anything is installed. I'd like to see the MD5 sums on one computer (at least) and the tarballs on another. These would be VERY secure boxes obveously. But I feel that would be a nice feature.
Also, there is another cool thing I'd like to see, something down the line of Tripwire. Tripwire puts MD5 sums on files. So you'd have a tarball with MD5 sums on it. Then it'll MD5 sum all the files inside of it, so if anything is changed, it'll be picked up.

Re: FreeBSD's method (5.00 / 1) (#15)
by hbo on Tue Sep 19, 2000 at 05:08:40 AM EST

You hinted at the problem with the whole tripwire genre when you mentioned you'd like to see the hash and the download coming from seperate sites. If an attacker has the power to replace the package, they can probably also alter the hash. This is a bigger problem on the Internet than within your own site, of course. If I want to tripwire a system, I can build it from CD, compute the hashes and burn them into an ISO along with the tripwire binaries themselves, all before I ever connect the box to a network. Of course, I'm still trusting the CD based distribution.

On the Internet, I'm more or less forced to trust the distributing site. I often build ports under FreeBSD over the Internet from ftp.freebsd.org. I just trust that their security is good enough to prevent or at worst detect tampering with their packages. In this particular case, I think the trust is not misplaced. But what about your flavor-of-the-month Linux distro? (NOT flamebait. I assume the major Linux distributions are as trustworthy in this regard as Walnut Creek ..er.. BSDI).

Trust is unavoidable. I trust my landlady will not turn me out on the street tomorrow. I trust that the guy signalling for a left turn isn't going to throw it in reverse and ram me. In both cases I take certain measures to try to avoid such unlikely events (paying rent, not tailgating) but I can't guarantee the desired outcomes.

[ Parent ]

Re: FreeBSD's method (5.00 / 1) (#16)
by Matrix on Tue Sep 19, 2000 at 08:08:01 AM EST

I personally like Debian's system. One thing to keep in mind: a lot of people put Linux/FreeBSD/whatever on less powerful boxes that it can make good use of. How much longer does it take to download code and compile it than just download binaries? Might a system that has both available be the best idea, so that one can download binaries if one doesn't want to take the time for a slower machine to compile a package?


Matrix
"...Pulling together is the aim of despotism and tyranny. Free men pull in all kinds of directions. It's the only way to make progress."
- Lord Vetinari, pg 312 of the Truth, a Discworld novel by Terry Pratchett
[ Parent ]

Auto-updating and security. | 17 comments (17 topical, 0 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!