mDNS service to share apt caches?
Written by on in Tuxedo.

Working on the Research in Action follow-up I had a thought.

Is there a package I can install on a (Debian-based) machine which would automatically advertise to all machines on the network (via mDNS or the like) that I have (signed) repository sources and .debs available?

The idea being that an "Internet Bus" would update normally when at the central station, downloading the signed repository states and packages, and then would broadcast the presence of its updates as it toured the countryside. Clients looking for the mDNS service would be able to query for the set of repository images and .debs and download those which would be needed for them to update their current software images.

You'd need something whereby clients could request that a given package not on the bus be added to the set of packages normally cached/picked up. That would likely include all of the X and similar packages, since the bus wouldn't be likely to have them. Of course, if there's a client on the bus, it would likely have those packages anyway.

In non-bus mode, the same services should allow you to automatically reduce upstream bandwidth by having whatever machine first updates its packages share those packages/updates with all others on your network.

Does it exist?

Comments

  1. Aigars Mahinovs

    Aigars Mahinovs on 11/19/2009 1:06 p.m. #

    Doubt that, because unless you are very careful, there is an easy attack vector - replay attack, basically you provide a version of the package where you know a security bug exists while at the same time prohibiting the target from getting an update from upstream.

    And as you don't have a full mirror, you cann't even detect that the provided version is in fact months old and not fresh.

  2. Mike C. Fletcher

    Mike C. Fletcher on 11/19/2009 2:21 p.m. #

    Hmm, "as you don't have a full mirror, you can't even detect that the provided version is in fact months old" seems like a difference of assumption.

    You've got a signed image of the repository updates, the certificate of which would almost certainly include the date and/or revision ID for the repository. You wouldn't install an earlier version than the one you have, I would think. The certificate-signed image would include the signed certificates for the packages described (or at least the version IDs and sha/md5 hashes thereof).

    You do have a theoretical attack where there are three versions of the repository (all signed), N, N+1 and N+2, where N+1 introduced a security failure and N+2 fixed it. An attacker could see the update in N+2, devise an attack to compromise machines with N+1, then drive around the countryside offering the (valid, signed) N+1 and then immediately compromising the machines when their users install the updates.

    Iff the attacker gets there before any machine that has updated to N+2, then they can own the machine. N+1 could, of course, also be installed innocently, being a valid update. An attacker seeing N+2's fix could just drive around looking for N+1's to compromise, with the offer of the N+1 packages just being an opportunistic way of getting users to update to the affected level.

    Simply blocking the user's access to updates after they receive N+1 would have the same effect... as it would with current distribution methods (DDOS the debian/ubuntu repository hosts). That is, the fact that the offline machines have to rely on drive-by hosts means that they have a wider window-of-attack where an N or N+1 might be installed, and thus might be vulnerable longer, but compared to the window of attack if they are sitting at M, L, K, I, etceteras, waiting for someone to explicitly come by and provide updates... it seems likely they'd be better off if every passing laptop was chatting about the updates they've seen and disseminating the latest versions ASAP.

  3. Adrian von Bidder

    Adrian von Bidder on 11/20/2009 3:24 a.m. #

    apt-zeroconf goes into that direction, it's between dead and being resurrected and probably not functional.

    Latest info I've found is on http://castrojo.wordpress.com/2009/06/27/resurrecting-apt-zeroconf/

  4. Daniel Coupet

    Daniel Coupet on 11/26/2009 6:44 p.m. #

    I can't think of anything functional that exists like that. It sounds pretty complicated. As the comment before me said, zeroconf attempted to but failed.

Comments are closed.

Pingbacks

Pingbacks are closed.