Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

15 years later: remote code execution in qmail

qualys.com

Post reply on HN
Print view View original

151–160 of 164 posts

Re: 15 years later: remote code execution in qmail

#151

Post by Quekid5 »

dsl wrote: post #39
arbitrage wrote: post #23

Earlier quoted context omitted.

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 e…

DJB paid out $1,000 in 2009 to Matthew Dempsky for a djbdns security vulnerability. https://marc.info/?l=djbdns&m=123613000920446&w=2

> The next release of djbdns will be backed by a new security guarantee.

I was a bit curious about this wording which seems quite weasel-wordy at first glance, so these are the snapshots of the page that have been saved by Archive here https://archive.vn/https://cr.yp.to/djbdns/guarantee.html

I did a rough diff of the two first saved snapshots (which span 2009), and got this:

    @@ -6,7 +6,7 @@
     
     The djbdns security guarantee
     
    -I offer $500 to the first person to publicly report a verifiable security hole in the latest version of djbdns.
    +I offer $1000 to the first person to publicly report a verifiable security hole in the latest version of djbdns.
     
    @@ -14,17 +14,25 @@
    -Bugs outside of djbdns, such as OS bugs or browser bugs, do not qualify. The vulnerability of DNS to forgery does not qualify. Denial-of-service attacks do not qualify. (An attacker can easily take down the Domain Name System, or selected parts of it; this is not news.)
    +Examples of problems that do not qualify:
    +
    +
    +
    +    Bugs outside of djbdns, such as OS bugs or browser bugs. (People could seize control of BIND 9.1 through an OpenSSL buffer overflow, but that was a bug in OpenSSL, not in BIND.)
    +
    +    The vulnerability of DNS to forgery. (BIND's port reuse makes blind forgery much less expensive, but this is a quantitative difference, not a qualitative difference. The DNS architecture needs cryptographic protection.)
    +
    +    Denial-of-service attacks. (BIND 9's fragility makes denial of service completely trivial; but an attacker can easily take down the Domain Name System without using any of BIND's bugs. The DNS architecture needs to be decentralized.)
I don't think this looks unreasonable in terms of actual consequences/definitions, but it is interesting how much effort and verbiage he spends on pointing out the flaws of other DNS servers.

Re: 15 years later: remote code execution in qmail

#152

Post by titzer »

dependenttypes wrote: post #136
titzer wrote: post #130

Earlier quoted context omitted.

This specific type of vulnerability and the tens of thousands of similar ones like it would absolutely have been prevented by a safe programming language.

This specific type of vulnerability would not be an issue in a safe C implementation for example, just like it would be an issue in an unsafe rust implementation.

There have been research projects that have attempted to make a standards compliant "safe C" a number of different times. You either end up with a 3x execution time overhead, only support a subset, or break programs that do unsafe type punning. As a result, this is not viable.

Re: 15 years later: remote code execution in qmail

#153

Post by tjalfi »

upofadown wrote: post #21

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.

It's been years (2009) since I administered a mail server but I think this is also true of Sendmail.

Re: 15 years later: remote code execution in qmail

#154

Post by mmm_grayons »

smokecab wrote: post #67
mmm_grayons wrote: post #30

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.

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.

This isn't "out-of-fasion prejudice". This is a bug not being fixed for over a decade, which is clear evidence that it's not being adequately maintained. I've got nothing against qmail in principle, but it clearly hasn't received the attention it needs.

Re: 15 years later: remote code execution in qmail

#155

Post by mmm_grayons »

Snelius wrote: post #105
smokecab wrote: post #67

Earlier quoted context omitted.

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.

"But we need to rewrite it with Rust!!" Crazy..

I said nothing about rust, and the alternative I proposed (postfix) is written in C.

Re: 15 years later: remote code execution in qmail

#156

Post by jstimpfle »

derefr wrote: post #83
kevincox wrote: post #37

Earlier quoted context omitted.

Yeah, that footgun should really have a more explicit name. __dear_compiler_i_promise_that_this_statement_is_unreachable_and_you_may_optimize_based_on_my_good_word_upon_penalty_of_undefined_behaviour()

I mean, what other semantics would anyone expect it to have—presuming they think for a moment about why it exists as its own thing in the first place?

Ok so what's the answer if you apply the question to __builtin_trap()?

Re: 15 years later: remote code execution in qmail

#157

Post by Dylan16807 »

dependenttypes wrote: post #149
Dylan16807 wrote: post #148

Earlier quoted context omitted.

"safe C" and "unsafe Rust" sound like variant languages to me.

How is "safe C" a variant language when it is within what the standard allows?

The unsafeness of C is pretty widespread and fundamental. Whatever code you end up with is either going to be incompatible with normal compilers, or it's going to be so full of library calls that you can barely recognize it as C anymore.

Unless you count sandboxing the entire program, and allowing errors inside the sandbox as long as they don't escape. Then C-to-WASM would be a safe C compiler, I guess.

Re: 15 years later: remote code execution in qmail

#158

Post by zrm »

xorcist wrote: post #134
peterwwillis wrote: post #113

Earlier quoted context omitted.

Postfix has 9 CVEs. Qmail has 1. It would seem the numbers don't agree with you.

Postfix has much more functionality out of the box so the comparison isn't really fair. Both are examples of extremely well designed software written with care by security minded persons.

> Postfix has much more functionality out of the box so the comparison isn't really fair.

But that's kind of the point. 20 years worth of feature accumulation is 20 years worth of additional attack surface, which is a liability if all you need is what qmail does.

Re: 15 years later: remote code execution in qmail

#159

Post by peterwwillis »

erik_seaberg wrote: post #133
dependenttypes wrote: post #122

Earlier quoted context omitted.

It is about safe and unsafe implementations rather than safe and unsafe languages.

Can we name any programmers who are actually capable of a safe implementation using an unsafe language? DJB failed, Knuth's code has bugs, how can I expect you or I to succeed?

That's a good point, but on the other hand, who wrote the languages? Is it possible for a human to write a language which another human can use and create no bugs?

In either case - unsafe language and safe implementation, safe language and unsafe implementation - there is the possibility for bugs, and definitely security ones. Just because you can't cause integer overflow doesn't mean you can't exfiltrate petabytes of data.

I think the major security consideration should be a comprehensive review of the entire system. Regardless of the language or implementation, a regular architectural and non-functional review of all the components in a systematic way is going to provide more security gains than any other single thing. Maybe we should be focusing less on the tools we use and more on improving that workflow.

Re: 15 years later: remote code execution in qmail

#160

Post by sneak »

dependenttypes wrote: post #145
morelisp wrote: post #143

Earlier quoted context omitted.

> a bone to pick with DJB due to their personal political beliefs "Political beliefs" is a weird way to say DJB has stepped up to defend at least three people accused of sexual abuse by multiple victims.

I actually had https://blog.cr.yp.to/20160607-dueprocess.html in mind when mentioning political beliefs, but even then I think that this still falls under the "political belief" label - the belief that anyone accused of rape should not have any form of defence. Anyway, the person who is being sued was part of a harassment campaign against multiple people, including Bernstein himself, so I can't see why it would be a…

People can be onboard 100% with his argument for due process (I am) and simultaneously 100% against his association with Jake Appelbaum, whose (perhaps subcriminal) misbehavior was widely reported in private in our industry prior to the bevy of as-yet-unproven rape accusations.

Appelbaum is and has been a scumbag regardless of the fact of whether or not he has been adjudicated a rapist in a court of law.

People who associate with scumbags (and, indeed, defend them in particular) aren’t great, and can and should be subject to criticism for their choices regarding scumbags.

Fortunately, it isn’t a simple dichotomy. I agree with due process for imprisoning people. I also agree in public criticism of entirely legal misbehavior and freedom of association. I don’t respect people who defend scumbags socially (defending subcriminal scumbags from prison is another matter), and djb is certainly that.

Post reply on HN