7 ms·

Postfix has had 9 CVEs in 20 years, a few of them quite bad. [0] qmail has had 1 CVE in 20 years, a local DoS. [1] I trust djb to write correct code more than

by sigil 7y ago

Postfix has had 9 CVEs in 20 years, a few of them quite bad. [0] qmail has had 1 CVE in 20 years, a local DoS. [1] I trust djb to write correct code more than almost any other human on the planet. That includes all the non-crypto code found in qmail, daemontools, dnscache, ucspi-tcp, etc. If you’ve read it, you know how almost supernaturally careful and minimal it is. Your points about mere mortals writing C are well taken though! [0] https://www.cvedetails.com/vulnerability-list.php?vendor_id=8450&product_id=14794 https://www.cvedetails.com/vulnerability-list.php?vendor_id=... [1] https://www.cvedetails.com/vulnerability-list.php?vendor_id=16391 https://www.cvedetails.com/vulnerability-list.php?vendor_id=...

linsomniac 7y ago
Can you revise that "9" number, because looking at it I feel like some of those are inappropriately filed against postfix. I find it hard to pin a "postfixadmin" CVE on postfix, are we going to blame vmailmgr bugs on qmail? :-) The BSDDB one I'm on the fence about. "postfix_groups.pl" is marked as disputed. Another seems to be clearly a Debian package issue. CVE-2011-0411 is interesting because, IIRC, qmail had no SSL/TLS abilities, and the hacks you had to put into place to enable it were abominations and likely opened up issues of their own.
- sigil 7y ago
  Fine, let’s call it 7, since postfixadmin & the debian postinst script can’t be attributed to postfix proper. I’m not sure this qualitatively changes the argument. CVE-2011-1720 and CVE-2008-2936 are examples of postfix vulns no one has found, or reasonably expects to find, in djb code.
  - pilif 7y ago
    > CVE-2011-1720 and CVE-2008-2936 are examples of postfix vulns no one has found, or reasonably expects to find, in djb code. CVE-2011-1720 is related to SMTP authentication which qmail doesn't support out-of-the box. So. Yes you're right: You don't find that vulnerability in qmail because qmail doesn't have that feature. Can you run an SMTP server without authentication these days? Not if you have users using you as a relay. So I guess you have to custom patch qmail and now you're back to not running djb code in the first place. CVE-2008-2936 I grant you. Though once we are at doing hardlinks to symlinks, we might hit other edge-cases too, some might even affect qmail in some way.
    - geocar 7y ago
      Road warriors with Thunderbird may need SMTP authentication, but most people do relaying with just IP authentication just fine.
      - pilif 7y ago
        Aside of the fact that I doubt your "most people" assertion here, it's beside the point that I was trying to make which is that a CVE affecting a feature of Postfix that qmail doesn't have to begin with is not a fair mark against postfix. Because if you disable a feature you don't use, you won't be affected by the vulnerability. If you use smtp authentication, you're not running djb's code and all advantages of djb's code are moot. If you don't use smtp authentication then that CVE is inconsequential and you can't count it as a black mark against Postfix with regards to the security of your specific setup.
        geocar 7y ago
        > it's beside the point that I was trying to make which is that a CVE affecting a feature of Postfix that qmail doesn't have to begin with is not a fair mark against postfix. I disagree. It is a fair mark against postfix if (as I claim) most users really don't need it. Here's my reasoning to that point: I think most email end-users either use their ISPs mail settings (who know who they are and don't need authentication), or webmail (which doesn't use SMTP for relaying anyway), or outlook (which doesn't need SMTP at all). Fastmail is becoming more popular and it doesn't need SMTP either. The end-users who remain are either business users (who could use a VPN which is better than SMTP AUTH in every way), and nutters with vanity domains. If that's contended, and note I do believe there are probably end users who are actually still manually entering SMTP AUTH settings into email clients, but I would struggle to believe they're the majority and would need evidence. Meanwhile on the enterprise, pretty much every machine in every enterprise environment I've ever worked in has been set up for local relay. Again, if you think they're all using SMTP AUTH I'd need to see evidence. > If you use smtp authentication, you're not running djb's code and all advantages of djb's code are moot Do you actually believe that if you apt-get install postfix that you don't have any of the advantages of postfix's development processes? I'm not sure I can engage with that. It's like saying running linux invalidates "all advantages of djb's code" simply because you're (sometimes) not running his code (e.g. when you're in a syscall). Madness runs down that way. For what it's worth, most of the qmail smtpd patches I've seen to add SMTP AUTH (including the one I wrote nearly twenty years ago) are sensible, integrate well with the rest of qmail. You might not get djb's warrantee, but I can't believe you gain nothing by starting from a solid foundation.
yellow_postit 7y ago
Just a count of CVE, while interesting, I think misses calibrating by how much attention each has gotten. Given its popularity I'd assume much more security research and testing on postfix.
pilif 7y ago
The moment you start patching qmail you're not running qmail any more. None of the CVE numbers are meaningful to your custom-patched qmail. qmail was good when you could use it in its default configuration. Unfortunately, very few sites could (much less still can). Which brings us to the question of who you trust more: The maintainers of a full-featured MTA who have maintained their software for 20 years or some person's patches to scratch their itch before moving on and never touching it again?

by sigil 7y ago

linsomniac 7y ago

Can you revise that "9" number, because looking at it I feel like some of those are inappropriately filed against postfix. I find it hard to pin a "postfixadmin" CVE on postfix, are we going to blame vmailmgr bugs on qmail? :-) The BSDDB one I'm on the fence about. "postfix_groups.pl" is marked as disputed. Another seems to be clearly a Debian package issue. CVE-2011-0411 is interesting because, IIRC, qmail had no SSL/TLS abilities, and the hacks you had to put into place to enable it were abominations and likely opened up issues of their own.

sigil 7y ago
Fine, let’s call it 7, since postfixadmin & the debian postinst script can’t be attributed to postfix proper. I’m not sure this qualitatively changes the argument. CVE-2011-1720 and CVE-2008-2936 are examples of postfix vulns no one has found, or reasonably expects to find, in djb code.
- pilif 7y ago
  > CVE-2011-1720 and CVE-2008-2936 are examples of postfix vulns no one has found, or reasonably expects to find, in djb code. CVE-2011-1720 is related to SMTP authentication which qmail doesn't support out-of-the box. So. Yes you're right: You don't find that vulnerability in qmail because qmail doesn't have that feature. Can you run an SMTP server without authentication these days? Not if you have users using you as a relay. So I guess you have to custom patch qmail and now you're back to not running djb code in the first place. CVE-2008-2936 I grant you. Though once we are at doing hardlinks to symlinks, we might hit other edge-cases too, some might even affect qmail in some way.
  - geocar 7y ago
    Road warriors with Thunderbird may need SMTP authentication, but most people do relaying with just IP authentication just fine.
    - pilif 7y ago
      Aside of the fact that I doubt your "most people" assertion here, it's beside the point that I was trying to make which is that a CVE affecting a feature of Postfix that qmail doesn't have to begin with is not a fair mark against postfix. Because if you disable a feature you don't use, you won't be affected by the vulnerability. If you use smtp authentication, you're not running djb's code and all advantages of djb's code are moot. If you don't use smtp authentication then that CVE is inconsequential and you can't count it as a black mark against Postfix with regards to the security of your specific setup.
      - geocar 7y ago
        > it's beside the point that I was trying to make which is that a CVE affecting a feature of Postfix that qmail doesn't have to begin with is not a fair mark against postfix. I disagree. It is a fair mark against postfix if (as I claim) most users really don't need it. Here's my reasoning to that point: I think most email end-users either use their ISPs mail settings (who know who they are and don't need authentication), or webmail (which doesn't use SMTP for relaying anyway), or outlook (which doesn't need SMTP at all). Fastmail is becoming more popular and it doesn't need SMTP either. The end-users who remain are either business users (who could use a VPN which is better than SMTP AUTH in every way), and nutters with vanity domains. If that's contended, and note I do believe there are probably end users who are actually still manually entering SMTP AUTH settings into email clients, but I would struggle to believe they're the majority and would need evidence. Meanwhile on the enterprise, pretty much every machine in every enterprise environment I've ever worked in has been set up for local relay. Again, if you think they're all using SMTP AUTH I'd need to see evidence. > If you use smtp authentication, you're not running djb's code and all advantages of djb's code are moot Do you actually believe that if you apt-get install postfix that you don't have any of the advantages of postfix's development processes? I'm not sure I can engage with that. It's like saying running linux invalidates "all advantages of djb's code" simply because you're (sometimes) not running his code (e.g. when you're in a syscall). Madness runs down that way. For what it's worth, most of the qmail smtpd patches I've seen to add SMTP AUTH (including the one I wrote nearly twenty years ago) are sensible, integrate well with the rest of qmail. You might not get djb's warrantee, but I can't believe you gain nothing by starting from a solid foundation.

yellow_postit 7y ago

Just a count of CVE, while interesting, I think misses calibrating by how much attention each has gotten. Given its popularity I'd assume much more security research and testing on postfix.

pilif 7y ago

The moment you start patching qmail you're not running qmail any more. None of the CVE numbers are meaningful to your custom-patched qmail. qmail was good when you could use it in its default configuration. Unfortunately, very few sites could (much less still can). Which brings us to the question of who you trust more: The maintainers of a full-featured MTA who have maintained their software for 20 years or some person's patches to scratch their itch before moving on and never touching it again?