[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Revival of the signed debs discussion

Anthony Towns <aj@azure.humbug.org.au> writes:

> On Tue, Dec 02, 2003 at 02:02:19PM -0600, Steve Langasek wrote:
> > You change the contents of the compromised Packages file, so that 
> > Package: bash
> > is accompanied by
> > Filename: pool/main/b/bash/vulnerable-ident-server_1.0-1_i386.deb
> > which contains a perfectly valid .deb file, signed by a DD, that has
> > nothing whatsoever to do with bash.
> > AFAIK, apt does not sanity check the relationship between package names
> > and filenames (and it's not obvious that this should be part of its
> > responsibilities), and dpkg only gets a list of .debs to install once
> > they've been downloaded.
> Problem is that apt runs:

Not realy a problem, a benefit in this case.

> 	# dpkg -i vulnerable-ident-server_1.0-1_i386.deb
> 	# dpkg --configure bash
> the latter will generally give you an error, and for remote exploits,
> just unpacking the vulnerable software isn't enough. It's probably fine
> for local exploits, but you'd have to be on your toes.

You get an error. Its a bit late in the process as it is now but for
me red flags would rise, sirens start screaming, the internet
connection starts a 60 second hardware cut countdown.... :)

> Getting apt to downgrade a package you've already got installed is more
> straightforward; although "apt-get dist-upgrade; apt-get dist-upgrade"
> will keep trying to download the same deb then.

Yeah, as shown version mismatches don't show up suspiciously. One has
to read the output carefully to detect those. Fat chance when doing a
dist-upgrade of 300 debs.

That is what you ment, a older package claiming to be newer, right?

> Getting apt to upgrade a package you've already got installed to something
> newer that's vulnerable isn't detectable, but will usually need a newer
> libc6, which is a good warning sign.

If you upgrade you probably want a newer version. Making sure you
don't install a vulnerable version (be it a faked or real package
doesn't much matter) is your own job. Faking the newest version
to be an even newer, not yet existing, version might throw people off
thinking a DSA has already been fixed or prevent future fixes from
getting installed though.

I wrote a little script that checks what apt things its installing
against what the control files of the debs say. I will test it with
some more fakes and then file it in the BTS.


Reply to: