[HN Gopher] 15 years later: remote code execution in qmail
___________________________________________________________________
15 years later: remote code execution in qmail
Author : fanf2
Score : 197 points
Date : 2020-05-20 14:28 UTC (8 hours ago)
(HTM) web link (www.qualys.com)
(TXT) w3m dump (www.qualys.com)
| mftest wrote:
| Does anybody still use qmail in Production. I see on DJB's
| website that it is used in 700K sites but I doubt that
| assumption. Also the code has not been updated in almost a
| decade. How or why do sysadmins decide to go with qmail in 2020
| jl6 wrote:
| Do we know if they have applied for the $500 bug bounty from DJB?
| kick wrote:
| 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.
| allover wrote:
| When you say "this is squarely a Debian issue", do you mean
| "in his opinion", or that you agree?
| tedunangst wrote:
| What did Debian change to introduce this vulnerability?
| dsr_ wrote:
| 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 wrote:
| 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 wrote:
| Because you care more about the users than about DJB's
| ego.
| haroldp wrote:
| Then you should be running Postfix.
| im3w1l wrote:
| 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 wrote:
| the grown-ups moved to postfix a long time ago
| gowld wrote:
| It's been 20 years; I don't think he's concerned.
| [deleted]
| im3w1l wrote:
| Ahhh I see now that "qmail last had an official release
| in the late 90's". That changes everything, obviously.
| friday99 wrote:
| 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 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.
| allover wrote:
| 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 wrote:
| Maybe add a reference to how ElasticSearch (or some other
| new-pop tech) catches heck for the same?
| edoceo wrote:
| I'll reply to myself because I cannot edit now.
|
| I meant: my parent comment (@allover) was missing a
| reference to how ES is insecure by default, this
| community gives them heck (rightly so) and that this
| comparison (qmail v. ES) could have been added (ie: was
| missing) from his post.
|
| For a result of: this is a qmail bug that could/should be
| fixed AND ES should fix theirs too.
|
| I'm for sure (I thought obviously) not excusing either
| qmail or ES from being insecure by default or for their
| "fix" to be: "you're doing it wrong".
|
| I don't think my karma will ever recover from this (Tiger
| King joke)
| allover wrote:
| I think you're being downvoted because other things being
| insecure is not relevant or an excuse.
| icedchai wrote:
| qmail last had an official release in the late 90's.
| everything else is third-party forks / patches. Back in the
| day, I upgraded many systems from sendmail to qmail.
| However, that was a very long time ago... It's been over 15
| years since I've done something like that.
|
| Nowadays, the author should be telling people to install
| postfix.
| gowld wrote:
| The app is vulnerable if it runs in an unsafe environment
| that allows qmail to access more than 4GB (an absurdly
| large value when qmail was published in 1997 -- it would
| cost $5000 plus a rare, expensive machine to hold it).
|
| djb's view is that the environment is the responsibility of
| the admin, not the program's responsibility to enforce sane
| defaults. This is of course debatable.
|
| If the admin uses a recommended environment (low memory
| limit), there is no exploitability.
| allover wrote:
| So it's not secure by default.
| loeg wrote:
| Correct.
| jedberg wrote:
| DJB makes great code, but it always leaves a sour taste to use
| his code, because he has such a big ego and refuses to admit when
| he makes a mistake. He can't admit that it's possible to be the
| best but still make mistakes.
|
| I really hate supporting that.
| linsomniac wrote:
| I once was talking to one of the household-name DNS guys and
| asked what he thought about djbdns and he said something along
| the lines of: "It's unfortunate that he's so abrasive, because
| he has some really great ideas that nobody will listen to
| because of it."
|
| I've more recently come a little bit to terms with this whole
| abrasive thing being a brain chemistry artifact, and not just
| being an asshole for assholes sake. Because it seems to
| disproportionately impact those of us in the technical field.
| Not to excuse it, but to understand it.
| SmallPeePeeMan wrote:
| > Not to excuse it, but to understand it.
|
| Indeed. I don't have to abide such people, and neither do
| you. Now if he had found a cure for cancer, would we have
| more tolerance?
| ergothus wrote:
| I'm not a psychologist so I should probably shut up, but I'll
| continue:
|
| It seems like it does hit the tech field more often, yet
| overwhelmingly I see leading people in tech get softer, more
| empathetic, and more open to outside ideas the longer they
| work and the more experience they gain.
|
| Perhaps this is selection bias (the people I see are the
| "popular" ones, so of course they are the ones with more
| social awareness), or perhaps there is no hard and fast
| "genius requires ego". Note: I'm aware you didn't say that it
| did, you only mentioned that abrasive-ness seems
| disproportionately frequent in the tech field.
|
| I'm all for improving our understanding and ways of
| communication - I've definitely known people in the "asshole"
| category that were surprised and bothered to discover that
| was how they came across - but I'm not interested in
| normalizing abuse as a necessary cost. Which, again, you
| didn't say nor imply, but the concepts are related to what
| you've brought up, so I mention it here because the topic is
| interesting, not as a counterpoint.
| gowld wrote:
| LPT: take a shortcuts to success by listening to djb and
| plagiarzing his ideas.
| foota wrote:
| I would bet a lot of upvotes on this come from people misreading
| this as Gmail as I did :)
| gerdesj wrote:
| No. I ran several Qmails for many years on Mandrake with
| daemontools to supervise. All compiled from source. Lovely.
| "Life with Qmail" is a classic.
|
| I needed some additional flexibility and switched to Exim for
| my MTA of choice instead but have fond memories of Qmail.
| pwdisswordfish2 wrote:
| "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 comes with no such default
| configuration.
| upofadown wrote:
| The surprising thing here for me was that you can send qmail a
| 4GB email message and it will not immediately reject it in the
| default configuration.
| gowld wrote:
| 4GB was impossible when qmail was last updated.
| antirez wrote:
| That's quite interesting because the bug was there and was quite
| clear, and was not fixed by one of the most brilliant security
| persons out there (DJB). Maybe here the attitude really was the
| wrong one, considering how security oriented qmail was since the
| start, because the simplest possible fix does not seem to demand
| any other dimension, like complexity or performances.
| pfortuny wrote:
| Oh, dear. Another "will never happen" issue which, after not so
| long (in the history of mankind) takes place. And this one would
| not have been so complicated to fix (just enforce a limit as the
| author suggests). /* this line is unreachable
| */ printf("You have reached unreachable code\n");
|
| 10 years later, it gets printed...
| bluejekyll wrote:
| Why not exit/panic at that point? Seems like the right thing
| for any "unreachable" code.
| im3w1l wrote:
| Didn't think of it? If I saw a line like that I'd be grateful
| that it printed at all.
| asveikau wrote:
| I could see an argument (similar to for assert()) to omit
| such a check in most production builds. Maybe you could
| enable it for a small amount of hosts, so that if it does
| happen with any frequency, somebody sees it somewhere.
|
| But not every "unthinkable" case being reached represents a
| security problem as it does in this case. So in the general
| case of how to approach such assert-type checks, an abort
| might take down the process when not necessary, turning it
| into a DoS.
|
| Edit: I am not sure if my friend the downvoter realizes I am
| not trying to justify legit security bugs, just talking
| abstractly about varying approaches to handling asserts for
| unforeseen or "allegedly impossible" circumstances.
| tedunangst wrote:
| If we could tell a priori which unreachable cases were
| reachable it wouldn't be such a problem.
|
| Asserting only in debug builds is rather ineffective
| because the unthinkable input isn't in your testsuite. If
| it were, then it wouldn't have been unthinkable.
| asveikau wrote:
| > Asserting only in debug builds
|
| Right, but I am also suggesting another approach: if you
| have a large fleet of machines or a client app with a lot
| of usage, you can enable it in a small percentage of runs
| and if it hits in the wild you still have a chance of
| learning about it, without tearing down the process for
| all users. I have seen that strategy be effective.
|
| Very hard to know which behavior is appropriate in
| advance though. An assert that turns out to represent a
| benign circumstance that is already handled, multiplied
| by large numbers of machines, can be pretty annoying.
| kstrauser wrote:
| I didn't downvote you and I interpreted your comment the
| way you said you meant it. I do happen to disagree, though.
|
| For a project in a space that's notoriously vulnerability
| prone - I mean, when it was released it was competing with
| Sendmail - it seems very reasonably cautious to pepper the
| code with panic handlers in "impossible" places. They won't
| slow the code down any because they should never be
| evaluated, but give nice, noisy explosions when unexpected
| things happen. There's no downside to doing this.
| chasil wrote:
| Solaris also notably bundles 32-bit binaries for most
| everything in /bin with 64-bit distributions, and that
| begins to look like a wise choice.
|
| I recently observed that SmartOS does the same.
| Eridrus wrote:
| Ego.
| kevincox wrote:
| If you are really sure put __builtin_unreachable()
| jstimpfle wrote:
| Shoot I have done that in the past but it seems I
| actually wanted __builtin_trap().
| kevincox wrote:
| Yeah, that footgun should really have a more explicit
| name.
|
| __dear_compiler_i_promise_that_this_statement_is_unreacha
| ble_and_you_may_optimize_based_on_my_good_word_upon_penal
| ty_of_undefined_behaviour()
| pvarangot wrote:
| I'm pretty sure he didn't have that on most of the
| platforms he was targeting with his portable C code, it's
| not even there on some of them now.
| jstimpfle wrote:
| what you do is you define a macro in a common header.
| Like UNREACHABLE().
| badrabbit wrote:
| Because it will never happen I guess. From my experience,
| it's because of this bad habbit of expecting the program to
| crash and provide a backtrace,the print is there for
| debugging. But you're right,it's not the sane way of doing
| it.
| DominoTree wrote:
| Serious question: Was there a legitimate reason they didn't patch
| this stuff when it was first discovered?
| dullgiulio wrote:
| 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...)
| DominoTree wrote:
| I just found this on Wikipedia where he raised his bug bounty
| and at the same time cited these "unexploitable" bugs
|
| https://en.wikipedia.org/wiki/Qmail#Security_reward_and_Geor.
| ..
| koheripbal wrote:
| I don't understand. Most people with a big ego would not want
| a critical vulnerability associated with them. Can you
| elaborate?
| kbenson wrote:
| he had such confidence in his software and abilities that
| he thought it was actually secure, and there were no bugs,
| and posted a bounty for any exploit that could be found.
| Patching it means acknowledging it's an exploit, and that
| his code was not without bugs.
|
| Given that his principles of writing secure software
| (included in the Qmail guarantee[1]) includes this: "7.
| Write bug-free code." that might be a bit hard for him to
| swallow.
|
| 1: https://cr.yp.to/qmail/guarantee.html
| rurban wrote:
| Well, he used it with memory limits command line
| switches, so it could never be exploited. So he was
| technically correct. One should not use so much memory
| for a mail server, way too risky.
|
| Problem is, these switches were not default, people didnt
| use it because they are dumb, and DJB never cared to
| properly maintain it. like limiting memory per default,
| 32bit only builds or such.
| loeg wrote:
| His ego has transcended objective reality and he claimed
| (in 2005, and continues to claim in 2020) it isn't a
| vulnerability.
| stevekemp wrote:
| qmail was essentially unmaintained for a long time, people
| were distributing patches to it, but there were no upstream
| releases.
|
| (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.)
| rurban wrote:
| notqmail.org is for long the defacto maintained version.
| They had this fixed long time ago.
| vinay_ys wrote:
| http://cr.yp.to/talks/2007.11.02/slides.pdf I don't see ego
| in these slides. I see a brilliant programmer acknowledging
| his mistakes and learning from them. I really enjoyed running
| qmail in early 2000s and following djb's crypto work later.
| He is brilliant indeed.
| cadence- wrote:
| You should read some of his public.... ekhm...
| "discussions" with Wietse Venema on various security forums
| in the 90's. It was very entertaining, but also clearly
| showcasing djb's huge ego.
| cadence- wrote:
| Here is my favourite that I remember to this day:
| https://seclists.org/bugtraq/1998/Nov/117
| arbitrage wrote:
| The original qMail author, Dan Berstein (DJB) was so convinced
| of the infallibility of his code that he put up a monetary
| reward for any exploits. This context came about because DJB,
| as a professor of Computer Science, maintained that it is
| completely within the realm of reality to write unbuggy, yet
| complicated and highly functional code.
|
| DJB welched on every claim at that bounty, and refused to pay
| out. He is an egotistical over-selfconfident person. He wrote
| good code back in the day, but he lost the forest for the
| trees.
| dsl wrote:
| DJB paid out $1,000 in 2009 to Matthew Dempsky for a djbdns
| security vulnerability.
|
| https://marc.info/?l=djbdns&m=123613000920446&w=2
| davidu wrote:
| I used to work with Matthew. He's next level smart, and
| very modest. We are very lucky he is a good hacker and not
| an evil hacker. :-)
| kstrauser wrote:
| You're being downvoted, but from what I can tell you're
| right. DJB is undoubtedly a brilliant computer scientist, but
| it seems he'd be very quick to tell you that. I see this as a
| loss to our profession because I think that DJB-minus-ego
| could make even more awesome things.
| neonate wrote:
| But that DJB doesn't exist. I can come up with much bigger
| losses if they don't have to exist.
| linsomniac wrote:
| So wide-spread is his ego, that it reminds me of this quote
| from Donnie J. Barnes (of RedHat): "I went on IRC once. I was
| mistaken for Dan Bernstein. I still have nightmares."
| will4274 wrote:
| Can you give an example of a claim he "welched" on? Google
| isn't pointing me to anything except the fact that email is
| unencrypted which I tend to agree is out of scope.
| loeg wrote:
| As discussed in TFA, he didn't pay out for Georgi
| Guninski's original discovery in 2005 nor Qualys'
| rediscovery + working RCE in 2020.
| mmm_grayons wrote:
| This is why you don't run software that fossilized back in the
| nineties. Qmail was solid code but hasn't received the support
| and on-going development it needed. Use postfix instead for a
| secure MTA.
| smokecab wrote:
| Your prejudice against out-of-fashion software is unfounded.
| Qmail had a bug because qmail had a bug, not because it hasn't
| been rewritten in the past week. The major web browsers, for
| example, are all under very active development, yet new RCE (!)
| bugs are regularly introduced into them.
___________________________________________________________________
(page generated 2020-05-20 23:00 UTC)