3 ms·

"Finally, we also discovered two minor vulnerabilities in qmail-verify (a third-party qmail patch that is included in, for example, Debian's qmail package): CVE

"Finally, we also discovered two minor vulnerabilities in qmail-verify (a third-party qmail patch that is included in, for example, Debian's qmail package): CVE-2020-3811 (a mail-address verification bypass), and CVE-2020-3812 (a local information disclosure)." The vulnerabilities were introduced in a third party patch, not source code that was authored or advocated by djb. "As recommended by Daniel J. Bernstein, qmail can be protected against all three 2005 CVEs by placing a low, configurable memory limit (a "softlimit") in the startup scripts of all qmail services." Seems much simpler than patching, let alone trusting someone else's patches. Interesting that they developed their exploit against Debian's default configuration. qmail from its source at https://cr.yp.to/qmail.html https://cr.yp.to/qmail.html comes with no such default configuration.

mcguire 6y ago
"About our new discovery, Daniel J. Bernstein issues the following statement: ""https://cr.yp.to/qmail/guarantee.html https://cr.yp.to/qmail/guarantee.html has for many years mentioned qmail's assumption that allocated array lengths fit comfortably into 32 bits. I run each qmail service under softlimit -m12345678, and I recommend the same for other installations.""
loup-vaillant 6y ago
> The vulnerabilities were introduced in a third party patch Which patch are you talking about? I don't see anything about a patch in the CVE. > Seems much simpler than patching, let alone trusting someone else's patches. We can patch the issue for good (and with a simple patch, apparently), or we can rely on users not to mess with seemingly unrelated init scripts. Do you trust third party users more than a (likely heavily scrutinised) small third party patch?
- pwdisswordfish2 6y ago
  qmail-verify. It is an "update" of the third party "realrcptto" patch by another third party. It says "third party patch" right there in the sentence I quoted. There is no qmail-verify in original qmail. As to the second question, I trust softlimit from daemontools and that is what I use. https://cr.yp.to/daemontools/softlimit.html https://cr.yp.to/daemontools/softlimit.html Not sure what "messing with seemingly unrelated init scripts" means. Can you be more specific?
  - loup-vaillant 6y ago
    I could trust softlimit all right, but my point was that I wouldn't trust users to wield it correctly.
    - pwdisswordfish2 6y ago
      softlimit is not difficult to use, certainly no more difficult than patch. programs like tinydns-conf for example autmatically generate a run script containing softlimit with a recommended -m setting. maybe qmail needs something similar.
      - pwdisswordfish2 6y ago
        Correction: With tinydns, it's a -d setting, not an -m setting
      - loup-vaillant 6y ago
        I was talking about patching upstream, okay? It's not like the patch would have to be individually applied to each installation by its own admin. Patch upstream once, and poof, all users worldwide are safe as soon as they update.
        pwdisswordfish2 6y ago
        Perhaps "Seems much simpler than patching" was an ambiguous statement. I was only referring to the perspective I take as an admin for one user: me. I already use softlimit on a daily basis so it is simpler for me than patching. To me, it seems like a cleaner solution. The two complete mitigations presented were a choice between (a) using softlimit and the -m setting used by qmail's author versus (b) applying a third party patch to fix problems caused by another third party patch (qmail-verify, which was an "upadte" of yet another third party patch) and third party configuration settings (Debian). I thought that was noteworthy.

mcguire 6y ago

"About our new discovery, Daniel J. Bernstein issues the following statement: ""https://cr.yp.to/qmail/guarantee.html https://cr.yp.to/qmail/guarantee.html has for many years mentioned qmail's assumption that allocated array lengths fit comfortably into 32 bits. I run each qmail service under softlimit -m12345678, and I recommend the same for other installations.""

loup-vaillant 6y ago

> The vulnerabilities were introduced in a third party patch Which patch are you talking about? I don't see anything about a patch in the CVE. > Seems much simpler than patching, let alone trusting someone else's patches. We can patch the issue for good (and with a simple patch, apparently), or we can rely on users not to mess with seemingly unrelated init scripts. Do you trust third party users more than a (likely heavily scrutinised) small third party patch?

pwdisswordfish2 6y ago
qmail-verify. It is an "update" of the third party "realrcptto" patch by another third party. It says "third party patch" right there in the sentence I quoted. There is no qmail-verify in original qmail. As to the second question, I trust softlimit from daemontools and that is what I use. https://cr.yp.to/daemontools/softlimit.html https://cr.yp.to/daemontools/softlimit.html Not sure what "messing with seemingly unrelated init scripts" means. Can you be more specific?
- loup-vaillant 6y ago
  I could trust softlimit all right, but my point was that I wouldn't trust users to wield it correctly.
  - pwdisswordfish2 6y ago
    softlimit is not difficult to use, certainly no more difficult than patch. programs like tinydns-conf for example autmatically generate a run script containing softlimit with a recommended -m setting. maybe qmail needs something similar.
    - pwdisswordfish2 6y ago
      Correction: With tinydns, it's a -d setting, not an -m setting
    - loup-vaillant 6y ago
      I was talking about patching upstream, okay? It's not like the patch would have to be individually applied to each installation by its own admin. Patch upstream once, and poof, all users worldwide are safe as soon as they update.
      - pwdisswordfish2 6y ago
        Perhaps "Seems much simpler than patching" was an ambiguous statement. I was only referring to the perspective I take as an admin for one user: me. I already use softlimit on a daily basis so it is simpler for me than patching. To me, it seems like a cleaner solution. The two complete mitigations presented were a choice between (a) using softlimit and the -m setting used by qmail's author versus (b) applying a third party patch to fix problems caused by another third party patch (qmail-verify, which was an "upadte" of yet another third party patch) and third party configuration settings (Debian). I thought that was noteworthy.