6 ms·

Do we know if they have applied for the $500 bug bounty from DJB?

by jl6 6y ago

kick 6y ago
My guess is that he'd never accept it. He originally didn't allow people to distribute qmail with changes; this is squarely a Debian issue.
- tedunangst 6y ago
  What did Debian change to introduce this vulnerability?
  - dsr_ 6y ago
    Nothing, per se. But they don't set up softlimits or message size limits by default, both of which you should definitely do... it's just that the values you put in are specific to your situation.
    - tom_mellior 6y ago
      If you have DJB's ego yelling at you that the default configuration is safe, why would you bother setting limits to fix it?
      - jacquesm 6y ago
        Because you care more about the users than about DJB's ego.
        haroldp 6y ago
        Then you should be running Postfix.
      - dependenttypes 6y ago
        DJB has been telling people to run it with the memory limits since 2005.
- im3w1l 6y ago
  If he takes that stance than it will cast doubt on everything else he has done. If there is a footgun on the wall, by the end it must go off, and chaining "non-exploitable" bugs together is routine stuff for hackers.
  - liveoneggs 6y ago
    the grown-ups moved to postfix a long time ago
  - gowld 6y ago
    It's been 20 years; I don't think he's concerned.
    - deleted 6y ago
      [deleted]
    - im3w1l 6y ago
      Ahhh I see now that "qmail last had an official release in the late 90's". That changes everything, obviously.
      - loup-vaillant 6y ago
        In case it wasn't sarcasm: I would say it does not. What would, would be a note on the website explicitly mentioning that Qmail is unmaintained, and people should either take over maintenance or use something else. Seeing no such disclaimer at https://cr.yp.to/qmail.html https://cr.yp.to/qmail.html means DJB is (possibly unintentionally) still vouching for it. Right now in 2020.
- allover 6y ago
  When you say "this is squarely a Debian issue", do you mean "in his opinion", or that you agree?
friday99 6y ago
Yeah, it was denied. About our new discovery, Daniel J. Bernstein issues the following statement: "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." And from his "guarantee" In May 2005, Georgi Guninski claimed that some potential 64-bit portability problems allowed a ``remote exploit in qmail-smtpd.'' This claim is denied. Nobody gives gigabytes of memory to each qmail-smtpd process, so there is no problem with qmail's assumption that allocated array lengths fit comfortably into 32 bits. Under mitigations they list: 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. Alternatively: qmail can be protected against the RCE (Remote Code Execution) by configuring the file "control/databytes", which contains the maximum size of a mail message (this file does not exist by default, and qmail is therefore remotely exploitable in its default configuration). Unfortunately, this does not protect qmail against the LPE (Local Privilege Escalation), because the file "control/databytes" is used exclusively by qmail-smtpd. Alternatively: - an updated version of qmail-verify will be available at https://free.acrconsulting.co.uk/email/qmail-verify.html https://free.acrconsulting.co.uk/email/qmail-verify.html after the Coordinated Release Date; - the developers of notqmail (https://notqmail.org/ https://notqmail.org/) have written their own patches for the three 2005 CVEs and have started to systematically fix all integer overflows and signedness errors in qmail.
- allover 6y ago
  So the app is vulnerable by default, yet the author is claiming this doesn't matter, because he instructs how to run it in a safe way? Correct, or am I oversimplifying/missing something?
  - edoceo 6y ago
    Maybe add a reference to how ElasticSearch (or some other new-pop tech) catches heck for the same?

Do we know if they have applied for the $500 bug bounty from DJB?

by jl6 6y ago

Do we know if they have applied for the $500 bug bounty from DJB?

kick 6y ago

My guess is that he'd never accept it. He originally didn't allow people to distribute qmail with changes; this is squarely a Debian issue.

tedunangst 6y ago
What did Debian change to introduce this vulnerability?
- dsr_ 6y ago
  Nothing, per se. But they don't set up softlimits or message size limits by default, both of which you should definitely do... it's just that the values you put in are specific to your situation.
  - tom_mellior 6y ago
    If you have DJB's ego yelling at you that the default configuration is safe, why would you bother setting limits to fix it?
    - jacquesm 6y ago
      Because you care more about the users than about DJB's ego.
      - haroldp 6y ago
        Then you should be running Postfix.
    - dependenttypes 6y ago
      DJB has been telling people to run it with the memory limits since 2005.
im3w1l 6y ago
If he takes that stance than it will cast doubt on everything else he has done. If there is a footgun on the wall, by the end it must go off, and chaining "non-exploitable" bugs together is routine stuff for hackers.
- liveoneggs 6y ago
  the grown-ups moved to postfix a long time ago
- gowld 6y ago
  It's been 20 years; I don't think he's concerned.
  - deleted 6y ago
    [deleted]
  - im3w1l 6y ago
    Ahhh I see now that "qmail last had an official release in the late 90's". That changes everything, obviously.
    - loup-vaillant 6y ago
      In case it wasn't sarcasm: I would say it does not. What would, would be a note on the website explicitly mentioning that Qmail is unmaintained, and people should either take over maintenance or use something else. Seeing no such disclaimer at https://cr.yp.to/qmail.html https://cr.yp.to/qmail.html means DJB is (possibly unintentionally) still vouching for it. Right now in 2020.
allover 6y ago
When you say "this is squarely a Debian issue", do you mean "in his opinion", or that you agree?

friday99 6y ago

Yeah, it was denied. About our new discovery, Daniel J. Bernstein issues the following statement: "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." And from his "guarantee" In May 2005, Georgi Guninski claimed that some potential 64-bit portability problems allowed a ``remote exploit in qmail-smtpd.'' This claim is denied. Nobody gives gigabytes of memory to each qmail-smtpd process, so there is no problem with qmail's assumption that allocated array lengths fit comfortably into 32 bits. Under mitigations they list: 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. Alternatively: qmail can be protected against the RCE (Remote Code Execution) by configuring the file "control/databytes", which contains the maximum size of a mail message (this file does not exist by default, and qmail is therefore remotely exploitable in its default configuration). Unfortunately, this does not protect qmail against the LPE (Local Privilege Escalation), because the file "control/databytes" is used exclusively by qmail-smtpd. Alternatively: - an updated version of qmail-verify will be available at https://free.acrconsulting.co.uk/email/qmail-verify.html https://free.acrconsulting.co.uk/email/qmail-verify.html after the Coordinated Release Date; - the developers of notqmail (https://notqmail.org/ https://notqmail.org/) have written their own patches for the three 2005 CVEs and have started to systematically fix all integer overflows and signedness errors in qmail.

allover 6y ago
So the app is vulnerable by default, yet the author is claiming this doesn't matter, because he instructs how to run it in a safe way? Correct, or am I oversimplifying/missing something?
- edoceo 6y ago
  Maybe add a reference to how ElasticSearch (or some other new-pop tech) catches heck for the same?