OpenBSD Journal

Signed OpenBSD security advisories?

Contributed by jose on from the verifiable-advisories dept.

Nexus writes: "Does anybody have an idea on the question why the OpenBSD security advisories are not PGP/GnuPG signed?

FreeBSD and Debian, to name two examples, send out their advisories signed via PGP (GnuPG) making it easy to verify the message is really coming from the Security Officer.

It shouldn't be hard to send out a fake advisory pointing to a malicious patch somewhere on an FTP. True, while real OpenBSD users always check the errata page before installing patches, this doesn't seem to be in line with the proactive approach that makes OpenBSD OpenBSD. Also true, people falling for this trick may probably not be the persons who could be saved from this by using GnuPG (probably they don't use it anyway) but I mean... just as a precaution. We OpenBSD folks like security. And thus we should like verifying such important things as advisories for authenticity and integrity.

Furthermore, wouldn't it be wise to add MD5 checksums to the patches on the FTP server and mention these in the advisory?

It's not totally clear to me why OpenBSD doesn't do this."

(Comments are closed)


Comments
  1. By gwyllion () on

    There's no BSD licensed PGP implementation. I think the OpenBSD developers would prefer a OpenSSL S/MIME based implementation, but nobody has writen this.

    Comments
    1. By Anonymous Coward () on

      Is it a rule that the OpenBSD project only uses BSD licensed tools to do its work? I thought it was just that the "OpenBSD distribution" included nothing with a more restrictive license than the BSD license. (e.g. isn't GCC used to compile things in OpenBSD?)
      Regards

      Comments
      1. By gwyllion () on

        As few GPL licensed tools in the base tree as possible (no new tools and a continious effort to replace existings GPL programs with BSDL ones). GPG will also stay in ports, I guess.

        Comments
        1. By Anonymous Coward () on

          But GnuPG wouldn't have to me in the base system (nor in the ports) just for signing something. :-?

          Comments
          1. By Anonymous Coward () on

            Yes, the parent post missed the point.

      2. By mirabile () mirabile@bsdcow.net on http://mirbsd.de/

        You would use something in base over something
        in ports. And there's the rule in OpenBSD that
        no more GPL'd (or more-restrictive-than-BSD at
        least) code be added any more (gcc 3.x was the
        exception to the rule I think).

    2. By mirabile () mirabile@bsdcow.net on http://mirbsd.de/

      Well, GPG just plainly sucks (pgp 2.6.3ia and
      pgp 2.6.3in are alternatives, totally free for
      private individuals, and for anyone outside of
      countries with the IDEA patent).

      But what's so difficult about using S/MIME?
      I've even written a (signing) plugin for pine.

      https://mirbsd.bsdadvocacy.org:8890/active/cvsweb.cgi/ports/mail/pine/files/pine.smime.init
      is called instead of pine, and you fool pine into thinking that
      https://mirbsd.bsdadvocacy.org:8890/active/cvsweb.cgi/ports/mail/pine/files/pine.smime
      is sendmail.

      Verifying is just as easy (openssl smime -verify)
      once you have /etc/ssl/certs/ set up.

      Comments
      1. By Han () on

        It's mirabile.

        You can safely ignore anything he says about anything that involves GPL'ed code. He went berserk over somebody mentioning --longopts.
        Ask why he doesn't like it :)

  2. By Anonymous Coward () on

    Soon as I see an advisory I update by cvs not by downloading patches. Means I get any other incremental fixes not mentioned as errata too. Signed advisories is still a good idea though :)

    Comments
    1. By Anonymous Coward () on

      > "Signed advisories is still a good idea"

      I can't think of any reasons why signed advisories are a good idea. Care to share some ideas why they are relevant?

      Comments
      1. By dantams () on

        Because they would include an MD5 hash of the patches, thereby making it verifiable that you have downloaded a legit patch. DNS poisoning means you can't trust that the site that comes up when you enter openbsd.org in you browser is the real OpenBSD site. A public key distributed on the OpenBSD CD-ROM would make it possible to verify the advisory.

        Comments
        1. By pravus () on

          someone compromises the server with the private key, uses the compromised private key to sign invalid patches, and now what? now you have a big mess that's recorded for eternity on a CD-ROM. nice.

          and re-read my earlier post about MD5 hashes. nowhere in your statement did you mention signing the MD5 sums.

          Comments
          1. By Anonymous Coward () on

            I would give Theo enough credit to have a private key not stored on media that can be compromised.

            Removing a machine from a network will stop it being compromised by any but a burgler.

            Comments
            1. By pravus () on

              any media can be compromised. physical security is just as important as everything else.

          2. By dantams () on

            Only a moron would keep the private key on the server.

            As if there was a solution that was 100% secure. At least it is a lot more secure than now.

            If the advisory is signed and the advisory includes the MD5 sums, are the MD5 sums not signed??

    2. By Martin Schröder () martin@oneiros.de on http://www.oneiros.de

      And what makes you sure that the CVS server your client is talking to is the right one? Have you actually verified that the ssh keys are the official ones? How?

      Comments
      1. By mirabile () mirabile@bsdcow.net on http://mirbsd.de/

        Well... I've asked for this several times within
        the last two years or so, even opened a PR.

        It was closed with "this won't happen, sorry."

        MirBSD ships with a skeleton known_hosts file
        which contains what I know about most of the
        OpenBSD ssh keys - but without knowing if the
        values are actually correct, that's only for
        these of my infrastructure.

  3. By Anonymous Coward () on

    You only need a minimal tool that can VERIFY a OpenPGP formatted message.

    If it is of serious interest I will consider writing one. (NO key management, no encryption, no symmetric encryption, just verify, minimal cipher suite)

    Comments
    1. By djm () on

      Build it, BSD license it and demonstrate an ongoing committment and I will probably use it. Though I'd like something that can sign too - RSA, ascii signatures only

  4. By lcteo () on

    Perhaps what's needed is a small, lightweight patch verification tool that can be installed in, say, /bin. Since it's small enough, it can be audited thoroughly by the OpenBSD team. And of course, it'll be BSD-licensed. We could call it patch_verify or something.

    There's no point re-creating a BSD-equivalent of a heavyweight app like GnuPG again just to do simple tasks.

  5. By Anonymous Coward () on

    > "Does anybody have an idea on the question why the OpenBSD security advisories are not PGP/GnuPG signed?"

    The fact the change now lives in the CVS repository is all the signature you need.

    > "FreeBSD and Debian, to name two examples, send out their advisories signed via PGP (GnuPG) making it easy to verify the message is really coming from the Security Officer."

    Verifying him is irrelevant. He/She is not the problem nor the solution to the problem.

    > "It shouldn't be hard to send out a fake advisory pointing to a malicious patch somewhere on an FTP."

    No, it is not hard.

    > "True, while real OpenBSD users always check the errata page before installing patches, this doesn't seem to be in line with the proactive approach that makes OpenBSD OpenBSD."

    Signing a waste-of-time is being proactive? If so, OpenBSD has definately violated its goals.

    >"Also true, people falling for this trick may probably not be the persons who could be saved from this by using GnuPG (probably they don't use it anyway) but I mean... just as a precaution."

    "Just a precaution" to those who know better? Pointless. Irrelevant. A waste of time.

    > "We OpenBSD folks like security. And thus we should like verifying such important things as advisories for authenticity and integrity."

    Integrity of the patch is important, not a message that mentions a patch exists.

    > "Furthermore, wouldn't it be wise to add MD5 checksums to the patches on the FTP server and mention these in the advisory?"

    A fake advisory and a real advisory look the same. I don't see the reason why it should be done.

    Comments
    1. By pravus () on

      i couldn't agree more. it seems as though people get so caught up in implementing security-based solutions that they never actually consider the bigger picture. it's just like people who slap huge advertisments of PGP-signed this-or-that to the end of their e-mail messages for non-important stuff like mailing lists. it's a waste of time, bandwidth, cpu cycles, and storage space.

      also, i'd like to point out that MD5 sums for anything on a server gets you *nothing* security-wise. if someone is able to crack a machine, what's to stop them from changing all of the MD5 sums to match the infected material? you'd download it, verify it, and happily install trojaned material on your machines. MD5 sums mean nothing. learn it, believe it, move on.

      let's face it. there is no magic bullet when it comes to security. everyone who thinks that using this program or that language is simply lieing to themself. security is a process that must continually evolve with the ever-changing environment of computing.

      Comments
      1. By dantams () on

        also, i'd like to point out that MD5 sums for anything on a server gets you *nothing* security-wise. if someone is able to crack a machine, what's to stop them from changing all of the MD5 sums to match the infected material? you'd download it, verify it, and happily install trojaned material on your machines. MD5 sums mean nothing. learn it, believe it, move on.
        Can't you see that signed MD5 sums would solve all that?

        Comments
        1. By pravus () on

          and can't you see that i've basically stated that i agree with the notion that signing is useless? hence no signing of MD5 sums... hence MD5 sums are useless?

          Comments
          1. By krh () on

            ISTR a trojan horse once being caught in some IRC client because the foolish attacker had forgotten to change the MD5 sum.

            It won't stop anyone with brains, of course, but it's a little better than nothing.

            Comments
            1. By Anonymous Coward () on

              No.

              MD5's are usefull for verifying that you've downloaded a file correctly, and nothing more.
              You can't rely on the stupidity of attackers.

              Comments
              1. By Anonymous Coward () on

                word.

    2. By Charles Hill () on

      Verifying him is irrelevant. He/She is not the problem nor the solution to the problem.

      Not necessarily true. If the message itself contains the MD5 sums, then the sums are signed and you can check against THOSE.

      This way, when you download a patch you can compare agains MD5 sums that haven't been tampered with.

      By signing the advisory, you are placing trust in a controlled location -- the security person. You're trusting that they take reasonable care with their private key.

      Thus, a signed advisory with MD5 sums in the advisory GREATLY REDUCES the probability of faked messages, patches, etc.

      Is it 100% fool proof? No, but it goes a long way in the right direction.

      Comments
      1. By dantams () on

        That's right.

  6. By Chris Humphries () chris@unixfu.net on http://unixfu.net/

    signed security advisories are pointless.

    the advisory in the email should be in sync with the cvs repository and website about errata. if there is a difference, then only 2 things are possible.
    1) if the email is different from the site or not on the site, then it is not to be trusted.
    2) if they are the same, then it is to be trusted. if you still do not trust the advisory, then there are bigger problems, such as cvs.openbsd.org comprimised again.

    signed emails are all about trust. do you trust the system that is in place or not. there is no halfway trust. either you trust how openbsd does things now, or you do not... and having signed advisory emails will not fix that.

    Comments
    1. By Anonymous Coward () on

      What do you mean by "compromised again"?

  7. By Marc Espie () espie@openbsd.org on mailto:espie@openbsd.org

    You mean, you don't read patches before applying them ? Even considering security patches are pretty much minimal and solve the problem they say they should.

    Oh boy. Signed advisories won't solve your problem.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]