Debian Planet










Welcome to Debian Planet

Search

All your woody are (not quite, but very very very soon) belong to us.
Main Menu

  • Home

  • Topics

  • Web Links

  • Your Account

  • Submit News

  • Stats

  • Top 10

  • Debian

    These are important Debian sites one should not be without!

  • Official Debian site

  • Package search

  • Mailing list archives

  • Bug reports

  • Debian on CD

  • Unofficial woody CD ISOs

  • Unofficial APT sources

  • Developers' Corner

    Other great Debian news sources:

  • Debian Weekly News

  • Kernel Cousin Debian

    (Debian mailing lists digested)
  • Community Groups

    Need help? You're not alone on this planet.

  • debianHELP

    (User support site)

  • Debian International

  • DebianForum.de

    (Deutsch)

  • EsDebian

    (español)

  • DebianWorld

    (français)

  • MaximumDebian

    (Italiano)

  • DebianUsers

    (Korean)

  • Debian-BR

    (Português)

  • IRC

    The place to get help on a Debian problem (after reading docs) or to just chat and chill is #debian on irc.debian.org.

    Many of the Debian Planet staff live there so pop by and say hello.

    Wanna write?

    Got that latest or greatest scoop? Perhaps you have some important news for the Debian community? Submit a news item!

    Or perhaps you've written a rather ground breaking insight into some aspect of Debian and you feel compelled to share it with others? Knock up a longer editorial article and send it to the editors.

    Sponsorship

    DP is sponsored by Xinit Systems and kieser.net.

    Domains paid for and hosted by uklinux.net.

    Buy your Debian merchandise at DebianShop.com.

    Who's Online

    There are currently, 41 guest(s) and 1 member(s) that are online.

    You are Anonymous user. You can register for free by clicking here.

      
    Security with apt
    Contributed by wyrmbait on Monday, April 08 @ 15:28:39 BST

    Security
    While reading this article over at Slashdot.org about the potential insecurity of creating a Single Point of Ownership, I couldn't help notice the similarities between the offending program and our beloved apt. How secure is the protocol that apt uses? How resistant to attack are the Debian package servers? Is there any code signing done when a package is downloaded?

    I know I could get the answer to most of these from the source code, but I suspect the answers already, and would bring the question to the attention of more involved parties. Despite the fact that there are myriad package mirrors, many people (myself included) simply point apt to the main server, and, in any case, a package subverted in an attack on a main server could quickly propagate to the mirrors if it went undetected.

    IMHO, this is an issue that has been overlooked for some time is the context of open source, since the code is always there for inspection. The situation of automated updates does change things, though, and might require a re-examination of how much we trust pre-compiled code.

    Am I just being alarmist, or is this something that will have to be addressed in the development of Debian?

     
    Related Links

  • More about Security
  • News by rob

    Most read story about Security:
    Security with apt

    Last news about Security:

    Printer Friendly Page  Send this Story to a Friend
  • "Security with apt" | Login/Create Account | 33 comments
    Threshold


    The comments are owned by the poster. We aren't responsible for their content.

    Re: Security with apt (Score: 2, Insighful)
    by Anonymous on Monday, April 08 @ 15:42:11 BST

    Previously discussed here... http://debianplanet.org/article.php?sid=538

    This should be receiving more attention. Packages should be signed and checked at every step from maintainer to install.

    [ Reply ]


    Re: Security with apt (Score: 3, Informative)
    by Integral on Monday, April 08 @ 16:06:12 BST
    (User Info)

    In a single sentence:

    It's not secure, we know how to fix it, it won't be fixed for woody because it needs changes to core tools and infrastructure.

    (I don't know when it will be fixed because I don't have the authority to fix it myself -- the dpkg, apt, and ftpmaster people need to talk a bit about that. Maybe the new DPL can get the ball rolling, I don't know...)

    Daniel

    [ Reply ]


    apt is still different (Score: 2, Insighful)
    by Anonymous on Monday, April 08 @ 20:40:21 BST

    While apt may be insecure, it is certainly different from the above-mentioned offending program. That above-mentioned program is push: a user's computer is updated automatically without any intervention by the user. Thus, any infiltration would quickly propogate to the different peers.

    With apt, however, most people do not update packages automatically. Updating requires user intervention, any infiltration of the Debian servers would not cause a quick unasked-for update of every Debian machine. Even if a person updates packages automatically with cron, this only happens once a day.

    Any infiltration would not immediately affect millions of computers; an infiltration could even be fixed, or the servers temporarily taken down within a few hours, thus minimizing the damage. None of this is the case with Brilliant Digital, because updates are automatic to peers and there is no centralized control that can remove any infiltrated servers.

    [ Reply ]


    It's as secure as the Release.gpg file (Score: 2, Interesting)
    by hazelsct (hazelscq@mit.edu) on Monday, April 08 @ 22:17:54 BST
    (User Info) http://lyre.mit.edu/~powell/

    The Release file (e.g. debian/dists/potato/Release) contains MD5 checksums for all of the corresponding Packages files for each arch and section, which in turn contain MD5s for all of the listed .debs. And with the Release.gpg signature on that one file, the whole distribution is secure from the central server into our machines.

    Of course, this does not answer the question of security before the central server, e.g. security of incoming.debian.org, of the generation of Release and Release.gpg, of maintainers' keys, or trustworthiness of the maintainers ourselves. We go a good way toward the latter with the identification requirements for new maintainers, and the web of trust, but there is still potential for abuse with sufficient motivation.

    But this Release -> Packages -> .debs MD5 linkage allows us to address all of these "Why aren't our packages signed?" questions (they're quite common) with just a single Debian release signature on a single file.

    In other words, this particular security beef is a solved problem, you can all relax and go home now.

    [ Reply ]


    And what about the maintainers? (Score: 1, Insighful)
    by Anonymous on Monday, April 08 @ 23:14:08 BST

    How can one check if the maintainer isn't adding a trojan ect. to his package?

    With the growing number of Debian developers, it's actually just a matter of time, someone abuses his dupload rights.

    Don't misunderstand me - I dont mistrust debian. I love debian - but there has always been time for the first time.

    domi.

    [ Reply ]


    Don't get me started... (Score: 0)
    by Anonymous on Tuesday, April 09 @ 07:56:07 BST

    IMNSHO, all packages should be registered in an LDAP directory and signed with x.509 certificates. A given package could be signed by multiple parties, so package maintainers, distro. leaders, ISV's, and SIG's could offer their endorsements. You could develop a much more nuanced view of "What kinds of packages would I trust?" than "Is it stable or not?" ... *sigh* Distributed distribution development...

    [ Reply ]


    signing packages with keys from website and/or .iso (Score: 1)
    by kipple on Tuesday, April 09 @ 12:21:36 BST
    (User Info)

    IMHO the security for the packages should be extended by using crypto and public key signing:

    1. the public key should be available on the website AND in every debian distro, so if the .iso are compromised we could always rely on the public key on the website, and vice versa;

    2. apt- should automatically check the sig for the packages using the pre-installed key and compare it with the key obtained from the website

    3. in this way if the website and/or any of the mirror are compromised, the debian community will notice it in very little time

    4. this could also lead to a better organization of packages, marking them as 'approved by debian'. I know it could lead to discussion about 'why was my package rejected?', but still will centralize things

    ..those are just ideas, the methods could be discussed. I just would like to know if this makes sense or not

    greetings

    [ Reply ]


    Re: Security with apt (Score: 2, Informative)
    by Robot101 (robot1<zero>1@debian.org) on Friday, April 19 @ 02:50:42 BST
    (User Info)

    Apologies for the length. I had a lot to say.

    The Packages files contain MD5sums for every single .deb that they reference. apt does not install a deb which after downloading, doesn't match the MD5 in the Packages file. apt will also persistently try to redownload and reinstall a package which purports to be the same version as one in the Packages file, but has a different checksum.

    The Packages and Packages.gz files are themselves checksummed. Every suite (stable/testing/unstable, the first of which happens to be a release, the other two aren't yet =) has a Release file which checksums the Packages.gz file for every architecture in each section under it. There are also checksums for each Packages file's Release file, which doesn't contain checksums itself, but metadata about the Package file.

    The top-level Release files have a detatched signature, Release.gpg. For testing and unstable, unreleased suites, these are automatically signed by the key belonging to ziyi, the program on the master server that makes the Release files. This is the best you can hope for in these suites - the Package.gz files are regenerated daily. Stable releases are signed by a release key which belongs to and is signed by at least the release manager. The keys are available from our ftp master server.

    Thus every package in Debian is signed, but equally as importantly, the *releases* are signed. A signature inside a .deb doesn't cover you from attack. Consider a security advisory on a package. Debian releases an update for it, and adds it to stable and it's Package files. Your malicious local mirror admin edits his Packages file and removes the updated deb, and reinstates the old one. In the apt-get upgrade run the hapless user is satisfied he's getting all the security updates to Debian, whereas actually his mirror has been tampered with and some security updates upheld. The mirror admin watches to see who is using this old vulnerable package, and proceeds to exploit them.

    Even if the package itself had been signed, this attack would not have been foiled because the release that was available was not that which came from Debian, even if the old vulnerable package did at some point in the past. This is a significant point which the debsigs project does not address at all, in their attempts to add 'on board' signatures to debs like rpms have. Besides technical and implementation issues, this is what has stopped the widespread adoption of this project, coupled with the fact that there is already a signature model that does not suffer this vulnerability, the Release -> Packages -> deb MD5sum chain.

    What is lacking is a widespread way to verify these Release.gpg signatures. This has in fact already been adressed in a script by Anthony 'aj' Towns, the woody release manager, but I can't locate it. It is probably available somewhere in the debian-devel archives, where this discussion has taken place ad nauseam.

    It is also salient to point out that all the debs uploaded to the ftp master server are signed by either the developer who built and uploaded them, and these signatures are in the .changes file which lists the upload. These files are not retained publically, but they are mailed out to the debian-devel-changes list which is archived. The purpose of these files is to allow only developers in the keyring to submit files to the archive, and you could possibly implement some further checking using them, but it seems fruitless in light of the above information, unless you are installing packages outside of a release. Often packages that are built and distributed outside of Debian (including those by developers) are shipped with the signed .changes file lying around, so this could help if you want to verify these.

    Source packages are subject to similar signatures in .dsc files, wh

    Read the rest of this comment...

    [ Reply ]


    Based on: PHP-Nuke

    All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © 2000 by Debian Planet

    You can syndicate our news using the file backend.php.