11–20 of 164 posts
Do we know if they have applied for the $500 bug bounty from DJB?
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.
Do we know if they have applied for the $500 bug bounty from DJB?
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."
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 after the Coordinated Release Date;
- the developers of notqmail (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.
Serious question: Was there a legitimate reason they didn't patch this stuff when it was first discovered?
It's not "they", it's Daniel J. Bernstein. That's the reason :) (If you don't know: he is a top cryptographer that can amazingly correct code. However, he also has a very big ego...)
https://en.wikipedia.org/wiki/Qmail#Security_reward_and_Geor...
Do we know if they have applied for the $500 bug bounty from DJB?
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…
Correct, or am I oversimplifying/missing something?
Earlier quoted context omitted.
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.
What did Debian change to introduce this vulnerability?
Do we know if they have applied for the $500 bug bounty from DJB?
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.
Earlier quoted context omitted.
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…
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?
Earlier quoted context omitted.
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.
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.
Serious question: Was there a legitimate reason they didn't patch this stuff when it was first discovered?
It's not "they", it's Daniel J. Bernstein. That's the reason :) (If you don't know: he is a top cryptographer that can amazingly correct code. However, he also has a very big ego...)
(Similar story with djbdns/tinydns.)
"Recently" he released his code with new licenses, so that people could finally start distributing updated versions, rather than the previous approach where lots of people were sharing conflicting patches for various features (e.g. IPv6 support for AAAA records in tinydns.)