OpenBSD Journal

y Another Sendmail bug, Patch 014, 027

Contributed by jose on from the this-really-sucks! dept.

Piotr Kapczuk was the first to write to us about yet another Sendmail bug:
"Look at http://www.sendmail.org/patchps.html "
Todd Miller just sent out an announcement describing how this is fixed in 3.3, -current (which is now post 3.3), and the stable trees for 3.2 and 3.1. Patch 014 for 3.2-stable, patch 027 for 3.1-stable, and its fixed in OpenBSD-current (and OpenBSD 3.3) by updating to Sendmail 8.12.9. From Todd's advisory,
The sendmail in OpenBSD-current (and OpenBSD 3.3) has been updated to version 8.12.9 which includes a fix for this problem. The 3.1 and 3.2 -stable branches have had a patch applied that fixes the buffer overflow. However, because the -stable branches have the specific vulnerability patched (as opposed to the full 8.12.9 distribution), sendmail on -stable will report the old sendmail version.
Many thanks to Todd Miller, Miod, and Brad for information.

(Comments are closed)

Comments

  1. By Anonymous Coward () on

    "As shipped, OpenBSD runs a sendmail that binds only to localhost, making this a localhost-only hole in the default configuration. [...]
    It is worth noting that the ProPolice stack protector (http://www.trl.ibm.com/projects/security/ssp/)
    that will ship with OpenBSD 3.3 would have protected a system from an attacker trying to exploit this bug."

    Comments

    1. By Anonymous Coward () on

      and todd keeps on writing:

      When the sendmail bug came out we inported sendmail 8.12.9 and re-tagged the changed bits. That means that sendmail 8.12.9 is in OPENBSD_3_3_BASE, not just the 3.3 stable branch. Because the CDR master for 3.3 had not yet been sent to the plant (it was delivered there today) we are able to ship 3.3 with 8.12.9.

  2. By Ryvar () on

    I know about the DJB-Theo friction, so replacing Sendmail with Qmail is out of the question - but what about Postfix?

    Is it too much to ask that Sendmail in OpenBSD be ripped out wholesale by default and replaced with Postfix? Or maybe just leave Sendmail as a seperate .tgz during the install and let people install what they wish manually?

    This sendmail stuff is starting to get slightly ridiculous - if anyone is really really bored, how about figuring out what percentage of the patches since 2.7 have been Sendmail-related? Anyone want to put money on 5% or over?

    No, I could NOT do better than the OpenBSD team when it comes to do what they do, but one would think the default app selection could be a little more history-conscious, yes?

    I'm sorry to rant, but I'm starting to get a bit bothered by Sendmail dragging down the appearance of an OS I happen to be quite an unashamed fan of - and I know for a fact that I'm not the only person who feels this way. Not by a long shot.

    Comments

    1. By AcidOS () acidos@bandwidth-junkies.net on http://acidos.bandwidth-junkies.net/

      So assume sendmail is ripped out of OBSD and replaced by Postfix as a default. Assume the trend of people moving from sendmail to postfix continues as it does. How long until postfix replaces sendmail as the most commonly used UNIX MTA? Do you think then that interest will still stay on exploiting sendmail? No, it will move to postfix. Then you'll be patching postfix every other week.

      By default, in OBSD, sendmail is only bound to localhost. Unless you have changed this, only people logged into your system can exploit this. This is either means that a) the people you have on there aren't to be trusted and you can use various UNIX techniques to keep them from doing this kind of thing, or b) you aren't keeping up with your other patches, and people have broken into your box and are now exploiting this.

      Yes, patching is a hassle. That is why most of us get paid money to do it. While choice in program may mean more or less patching, in the end there will be just as many exploits, if not more, than the other program. Some OBSD releases have more patches than others, it is just a fact of life. If there was a way to create something that never needed to be patched, do you think Theo and the gang would still be in business?

      Hopefully with ProPolice, these buffer overflows won't be as big of an issue anymore. I actually worry that it will make people lax in patching though. Well, moreso than they already are.

      Comments

      1. By Anonymous Coward () on

        people have been trying to exploit postfix since it's been released. the fact is, postfix is a more securely written application, just as is qmail.

        how many companies do you think are running postfix now? it's significantly high enough that it'd be worth it for people to try to find security problems in postfix. the fact is, the security problems that plague sendmail just aren't there in postfix.

        while i won't say postfix has absolutely zero security problems, or that it never has or will, postfix was written with security in mind. sendmail was not, and has been somewhat hacked into the code. (no pun intended)

        look at bind. it wasn't written with security in mind and has had tons of problems. bind 9 was rewritten from scratch because of this, and has had a relatively good track record.

      2. By mathew () invalid@munged.arpa on mailto:invalid@munged.arpa

        Postfix won't necessarily end up being nailed as hard as Sendmail. As it's probably already one of the most commonly used MTAs on the Internet, it's already doing rather well indeed where security is concerned. The number of security vulnerabilities found in a program is not proportional to how much it's used, it depends on a great many more different factors than how many machines there are running it.

    2. By Anonymous Coward () on

      You're not alone.

      I really wish Postfix had stuck with a standard license, then this probably wouldn't even be an issue [maybe same for qmail]. For a default BSD install though, sadly sendmail and BIND are looking like the functional yet arbitrary options.

      Alternatives exist, but either seem to have licenses which fail, or don't have all of the necessary functionality one likely requires.

      Maybe work on improving the alternatives which have BSD/MIT/PD licenses - and then wager for their inclusion.

      On the other hand, OpenBSD does adhere to pretty Unixy standards, and as much as they're hated by most - sendmail and BIND are standards in the Unix world. Kinda like vi, only vi doesn't have the bloat and hideous track record, it merely shares some of the usability frustrations. :)

    3. By Anonymous Coward () on

      I counted.

      OpenBSD 2.1 - 2.5 have no sendmail-related patches.

      OpenBSD 2.6:

      010: SECURITY FIX: Dec 4, 1999
      Sendmail had a race in aliases file handling, which this patch fixes.
      A source code patch exists, which remedies this problem.

      OpenBSD 2.7:

      029: RELIABILITY FIX: Oct 9, 2000
      There is a non-exploitable buffer overflow in sendmail's test mode.
      A source code patch exists which remedies this problem.

      OpenBSD 2.8:

      031: SECURITY FIX: August 21, 2001
      A security hole exists in
      sendmail(8) that may allow an attacker on the local host to gain root privileges by specifying out-of-bounds debug parameters.
      A source code patch exists which remedies the problem

      028: SECURITY FIX: May 29, 2001
      The signal handlers in sendmail(8) contain code that is unsafe in the context of a signal handler. This leads to potentially serious race conditions. At the moment this is a theoretical attack only and can only be exploited on the local host (if at all).
      A source code patch exists which remedies the problem by updating sendmail to version 8.11.4.

      OpenBSD 2.9 has patches for #31 and #38 of OpenBSD 2.8.

      OpenBSD 3.0:

      034: SECURITY FIX: November 6, 2002
      An attacker can bypass the restrictions imposed by sendmail's restricted shell, smrsh(8), and execute arbitrary commands with the privileges of his own account.
      A source code patch exists which remedies the problem.

      OpenBSD 3.1:

      027: SECURITY FIX: March 31, 2003
      A buffer overflow in the address parsing in sendmail(8) may allow an attacker to gain root privileges.
      A source code patch exists which remedies the problem.

      022: SECURITY FIX: March 3, 2003
      A buffer overflow in the envelope comments processing in sendmail(8) may allow an attacker to gain root privileges.
      A source code patch exists which remedies the problem.

      OpenBSD 3.1 also has a patch for #34 of OpenBSD 3.0.

      OpenBSD 3.2 has patches for #22 and #27 of OpenBSD 3.1 and #34 of OpenBSD 3.0.

      So, in total we have seven bugs: one non-exploitable, four local root, and two remote root. Together they generated thirteen patches over about six and a half years. That's about one bug a year. If we count only bugs since 2.7 (which is what you asked for), then we get six bugs: one non-exploitable, three local root, and two remote root, together generating twelve patches over about three and a half years. That's about three and a half bugs per year.

      I'd say that sendmail has already used up its quota of vulnerabilities for the year, but that's not how software development works.

      I happen to think that sendmail is a death trap, so I don't use it. But that's my own personal decision; I also think that the OpenBSD team should keep sendmail in the default install and let those of us who don't like it switch on our own. Remember that OpenBSD is supposed to be a classic Unix system, but better; if you want to change everything, you may as well switch to Plan 9. Sendmail is part of a traditional Unix system. It is, simply put, The Way Things Are Supposed To Be. I don't want to break tradition and expectations on this. Maybe if there were another mailer that used sendmail.cf files it would be okay, but as it is you have only one choice if you want everyone who walks up and tries to administrate an OpenBSD system to understand.

      I am also unaware of a more secure mailer with an acceptable license. Both qmail and Postfix are unacceptable here.

      Comments

      1. By Anonymous Coward () on

        That means that the claim:
        "Only one remote hole in the default install, in more than 7 years!"
        is in fact false (untrue)!

        Surprise, bullshit to attract users.

        Comments

        1. By Anonymous Coward () on

          Yea, the step from 5 to 7 years was also a bit fast - 2 years has not passed.

        2. By Gimlet () on

          Hey, tell me where I can download your own, unbreakable OS and I'll dump OpenBSD.

          *crickets chirping in background*

          Thought so. Go back to your cave, troll.

          Comments

          1. By Anonymous Coward () on

            Why the hell put lies on the web-page?
            If you cann't trust the information on the web-page can you trust the OS - I donn't think so?

    4. By Anonymous Coward () on

      Do we really need to ship with a full featured MTA? Why can't sendmail be moved out into a high quality port. We already have a mechanism for easy switching of MTAs, so is it too much to have to get the package for your MTA of choice and install that?

      Moving sendmail into a port doesn't mean it has to be any less integrated with the system.

      Comments

      1. By tedu () on

        sendmail is used to deliver mail to localhost users too. it's needed to make cron work.

    5. By Anonymous Coward () on

      so? you can not exploit this on OpenBSD.

  3. By Anonymous Coward () on

    If I am running a snapshot, what are my options?
    o download latest source. patch and compile?
    o wait for the next snapshot to be posted?
    o disable sendmail, if it isn't necessary, and a new snapshot is not yet available?


    Comments

    1. By Anonymous Coward () on

      I realize that snapshots don't expect quite as much from a user as running -current from CVS, but it essentially works the same. If you need to patch, then yes you will need to download the relevant source to match your needs, patch, compile and see if it works.

      Waiting until the next snapshot to be posted would also likely work (this is the lazy method that I am particularly fond of as a heavy snapshots user).

      And yes, disabling also works if you don't want, or can't [for some reason] make use of the -current source.

      Sounds like you outlined your own options rather well. Just so I'm clear, were those questions intended to be rhetorical?

      Comments

      1. By Anonymous Coward () on

        Just sanity checking, looking for the obvious missed solution. Looks good.

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.]