6 ms·

The "one bug was found" only goes for exploitable security vulnerabilities. There have been many other, less impactful bugs. This is still an an impressive arch

by zurn 12y ago

The "one bug was found" only goes for exploitable security vulnerabilities. There have been many other, less impactful bugs. This is still an an impressive archievement, especially because DJB chooses to juggle with chainsaws and write in C.

lawnchair_larry 12y ago
It isn't even true for that. There have been several security bugs, which he stubbornly refused to fix.
- kragen 12y ago
  There was one potential security bug (Guninski’s find), which was probably not exploitable on any installation of qmail. I don’t think there have been any other security bugs found in qmail.
  - lawnchair_larry 12y ago
    Guninski had several, and there were working exploits for them. Nobody uses the OS to set process limits like djb claimed (nor should they), so it was exploitable on any installation of qmail.
    - kragen 12y ago
      I didn't know there were two. There don't seem to be several. This seems to be the best summary of the situation: http://www.jcb-sc.com/qmail/guninski.html http://www.jcb-sc.com/qmail/guninski.html Those two definitely aren't "exploitable on any installation of qmail", as you say; they aren't exploitable on any 32-bit installation of qmail, any ILP64 installation of qmail, any installation of qmail with a reasonable data size rlimit, or any installation of qmail on a machine with less than a couple of gigabytes of RAM and swap, if I understand Guninski's post. If you're running qmail processes without data size rlimits, you're vulnerable to resource-exhaustion denial-of-service attacks in any case. There are established guides to configuring qmail that tell you to set rlimits. Burley's page I linked above says he was running with rlimits before the bugs were found. I'm pretty sure that when I ran qmail, I didn't set rlimits, though. One of the two bugs is in an unprivileged process, but coupled with a local privilege escalation bug, should be sufficient for root. The other is in a process that already runs as root, although for POP, which was a thing I didn't run when I ran qmail.

by zurn 12y ago

lawnchair_larry 12y ago

It isn't even true for that. There have been several security bugs, which he stubbornly refused to fix.

kragen 12y ago
There was one potential security bug (Guninski’s find), which was probably not exploitable on any installation of qmail. I don’t think there have been any other security bugs found in qmail.
- lawnchair_larry 12y ago
  Guninski had several, and there were working exploits for them. Nobody uses the OS to set process limits like djb claimed (nor should they), so it was exploitable on any installation of qmail.
  - kragen 12y ago
    I didn't know there were two. There don't seem to be several. This seems to be the best summary of the situation: http://www.jcb-sc.com/qmail/guninski.html http://www.jcb-sc.com/qmail/guninski.html Those two definitely aren't "exploitable on any installation of qmail", as you say; they aren't exploitable on any 32-bit installation of qmail, any ILP64 installation of qmail, any installation of qmail with a reasonable data size rlimit, or any installation of qmail on a machine with less than a couple of gigabytes of RAM and swap, if I understand Guninski's post. If you're running qmail processes without data size rlimits, you're vulnerable to resource-exhaustion denial-of-service attacks in any case. There are established guides to configuring qmail that tell you to set rlimits. Burley's page I linked above says he was running with rlimits before the bugs were found. I'm pretty sure that when I ran qmail, I didn't set rlimits, though. One of the two bugs is in an unprivileged process, but coupled with a local privilege escalation bug, should be sufficient for root. The other is in a process that already runs as root, although for POP, which was a thing I didn't run when I ran qmail.