News for hackers. Stuff that matters.
Re:15 years later: remote code execution in qmail by DominoTree on Wednesday May 20, 2020 @12:10PM (#23248563)
Serious question: Was there a legitimate reason they didn't patch this stuff when it was first discovered?
Re:15 years later: remote code execution in qmail by arbitrage on Wednesday May 20, 2020 @01:38PM (#23249591)
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.

Re:15 years later: remote code execution in qmail by kstrauser on Wednesday May 20, 2020 @01:54PM (#23249767)
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.
Re:15 years later: remote code execution in qmail by neonate on Wednesday May 20, 2020 @02:34PM (#23250175)
But that DJB doesn't exist. I can come up with much bigger losses if they don't have to exist.
Re:15 years later: remote code execution in qmail by derefr on Wednesday May 20, 2020 @07:28PM (#23253239)
I presume that a DJB-minus-ego wouldn't have had any motivation to become DJB in the first place ;)
Re:15 years later: remote code execution in qmail by kstrauser on Wednesday May 20, 2020 @09:05PM (#23253844)
Oh, I don't know about that. There are lots of brilliant computer scientists and mathematicians with reputations for also being really nice and humble people. The smartest people I know freely admit when they're at the edge of their knowledge and abilities, and are the first to tell you when they've made mistakes.
Re:15 years later: remote code execution in qmail by derefr on Wednesday May 20, 2020 @09:11PM (#23253883)
You're talking about other people's motivations. But DJB minus ego wouldn't be some other person, he'd still be DJB; just "DJB if you cut a certain part of his brain out." And I don't think that that person would have any other motivation-generating part of his brain left. His works specifically seem entirely ego-driven. DJB minus the ego probably wouldn't have had any interest in becoming an information-worker at all. (I'd like to think he'd become a janitor, like the protagonist of Flowers for Algernon. :P)
Re:15 years later: remote code execution in qmail by kstrauser on Wednesday May 20, 2020 @10:17PM (#23254229)
I concede this point. May I modify my original statement? I wish DJB took motivation from non-ego sources, so that we could have the wonderful things he’s made, but even more wonderful because they were made by someone who knew they were fallible.
Re:15 years later: remote code execution in qmail by boolcow on Wednesday May 20, 2020 @09:48PM (#23254074)
Almost everyone who has worked really hard to be great at something has an ego about it. In most cases, they really wanted to be better than (often some specific) others.

To pick some well know people, I'd say Feynman and Einstein both had massive egos. They "knew" they were smart. They also had reputations for being really nice and humble.

It would be simpler to just admit that you think DJB is a bit of a jerk. Linus Torvalds is a bit of a jerk too, in most people's estimation. Brilliant jerks, we call them.

They can make great workers and are always terrible leaders.

Re:15 years later: remote code execution in qmail by kstrauser on Wednesday May 20, 2020 @10:15PM (#23254223)
There’s a big difference between self-assessed qualifications, and ability to admit fallibility. Good scientists know they know a lot. Great scientists know that they don’t know a lot, and admitting that you might be wrong is critical for the scientific method to work.

So DJB is brilliant, but if he admitted that he could make mistakes (or even that a compiled could mis-compile his flawless code), then he might have put in failsafes like unreachable code assertions that would have meant that we wouldn’t be discussing this today.

I don’t think he’s a jerk. I don’t know enough about him; maybe he’s the nicest, kindest guy around. I do think the evidence suggests that he’s arrogant, though, and that’s not a good look on anyone.

Re:15 years later: remote code execution in qmail by dsl on Wednesday May 20, 2020 @03:29PM (#23250748)
DJB paid out $1,000 in 2009 to Matthew Dempsky for a djbdns security vulnerability.

https://marc.info/?l=djbdns&m=123613000920446&w=2

Re:15 years later: remote code execution in qmail by Quekid5 on Thursday May 21, 2020 @08:13AM (#23257460)
> 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 by davidu on Wednesday May 20, 2020 @04:47PM (#23251596)
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. :-)
Re:15 years later: remote code execution in qmail by linsomniac on Wednesday May 20, 2020 @02:57PM (#23250423)
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."
Re:15 years later: remote code execution in qmail by will4274 on Wednesday May 20, 2020 @06:02PM (#23252473)
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.
Re:15 years later: remote code execution in qmail by loeg on Wednesday May 20, 2020 @06:16PM (#23252615)
As discussed in TFA, he didn't pay out for Georgi Guninski's original discovery in 2005 nor Qualys' rediscovery + working RCE in 2020.
Re:15 years later: remote code execution in qmail by dullgiulio on Wednesday May 20, 2020 @12:22PM (#23248712)
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...)

Re:15 years later: remote code execution in qmail by kelnos on Wednesday May 20, 2020 @09:51PM (#23254091)
The funny thing about that is I find his code to be very difficult to read (even just the snippets in the linked CVE illustrate this).

And his attitude is just bonkers to me. "I'm not going to fix this exploitable security issue because I assume that people will configure their environment in a particular way." What? That's... flat-out irresponsible.

Re:15 years later: remote code execution in qmail by dependenttypes on Thursday May 21, 2020 @01:14AM (#23255035)
He does not have any responsibility against anyone. He released his software in public domain with the source included for free.
Re:15 years later: remote code execution in qmail by loup-vaillant on Thursday May 21, 2020 @05:32AM (#23256448)
When you release software for the world to use, tell everyone it's secure, even put up a bug bounty… that kinda means you are taking responsibility.
Re:15 years later: remote code execution in qmail by morelisp on Thursday May 21, 2020 @05:23AM (#23256395)
Putting aside question of if can have responsibility for freely-released work (especially when one has made a big deal of money offered in exchange for this kind of finding), at the time this bug was discovered the software was emphatically not in the public domain and difficult to distribute modified versions of despite available source.
Re:15 years later: remote code execution in qmail by DominoTree on Wednesday May 20, 2020 @12:37PM (#23248901)
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...

Re:15 years later: remote code execution in qmail by stevekemp on Wednesday May 20, 2020 @01:27PM (#23249460)
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.)

Re:15 years later: remote code execution in qmail by rurban on Wednesday May 20, 2020 @06:10PM (#23252565)
notqmail.org is for long the defacto maintained version. They had this fixed long time ago.
Re:15 years later: remote code execution in qmail by sneak on Wednesday May 20, 2020 @10:36PM (#23254300)
Re:15 years later: remote code execution in qmail by dependenttypes on Thursday May 21, 2020 @01:32AM (#23255122)
Filo is upset that he did not bother to check the code (that originally came from SUPERCOP, a benchmarking tool) he blindly included in go's xcrypto. Here is DJB's tweet: https://twitter.com/hashbreaker/status/1108637226089496577

(regardless, you should not directly encrypt a large amount of data, even nacl suggest against it https://nacl.cr.yp.to/valid.html)

In addition both Filo and Garrett have a bone to pick with DJB due to their personal political beliefs and his involvement in the Appelbaum case and I found both of them to be extremely dislikeable and unable to accept their own faults in personal discussions that I had with them in the past (regarding different issues). Considering that this was a subpost my opinion of them is even lower now.

Re:15 years later: remote code execution in qmail by mjg59 on Thursday May 21, 2020 @04:48AM (#23256203)
My opinions around DJB have very little to do with my political beliefs, but rather more to do with spending time with people who are far better at cryptography than he is without having anything approaching his ego.
Re:15 years later: remote code execution in qmail by morelisp on Thursday May 21, 2020 @05:36AM (#23256465)
> 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.

Re:15 years later: remote code execution in qmail by dependenttypes on Thursday May 21, 2020 @05:54AM (#23256574)
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 bad thing for him to send his declaration.

For anyone interested, his declaration is here: https://www.courtlistener.com/recap/gov.uscourts.cand.340308...

And here is the most objective and complete story of the Appelbaum events that I have personally seen so far https://github.com/Enegnei/JacobAppelbaumLeavesTor/blob/mast... (if anyone has anything better please do let me know)

> accused of sexual abuse by multiple victims

Including false accusations by others in the name of the so called victims. Such as the "Alice" case. (if I am not mistaken this specific accusation was published by the person being sued themselves)

Re:15 years later: remote code execution in qmail by sneak on Thursday May 21, 2020 @02:48PM (#23263108)
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.

Re:15 years later: remote code execution in qmail by dependenttypes on Thursday May 21, 2020 @03:30PM (#23263797)
> Appelbaum is and has been a scumbag

I do not know him, do you? Most accusations against him that I have seen have been either by the person being sued or some form of hearsay.

It is not too unlikely that he is a scumbag to be honest, but it is still something that I do not know.

> and, indeed, defend them in particular

I contest this claim. He did not defend Appelbaum in this instance, in his declaration even he claims that he is unaware whether Appelbaum is a rapist. The lawsuit is against Lovecruft specifically. Regardless, I do not believe that scumbags do not deserve to be defended. Everyone does, as long as the defence has reasonable points that is.

Btw, can't this post of yours be interpreted as defending Lovecruft if we follow this logic? If so I find this ironic that you try to criticize Bernstein of something that you are doing yourself.

> I also agree in public criticism of entirely legal misbehavior

You must love sites like Kiwifarms then. It is one thing to have open criticism and debate and another to have dog-piling and harassment based on roumors - the ability to defend yourself and have others defend you is one of the most important things that distinguishes the two.

> and freedom of association

Do you also believe that people should be free to refuse to deal with minorities by any chance? This is something that is implied by the freedom of association after all.

> I don’t respect people who defend scumbags socially

Again, the pot calling the kettle black. I do not get this logic to be honest, I will explain why with an example. Let's take a scambag, Jeff Bezos for example, and I start saying that he is a murderer out of nowhere. Is nobody allowed to defend him or ask for evidence just because he is a scambag?

Re:15 years later: remote code execution in qmail by morelisp on Thursday May 21, 2020 @05:32AM (#23256445)
> even nacl suggest against it

You're defending djb's decision by pointing to another of his projects, which in turn cites another email from djb. I'm not saying you're wrong¸ but it's not exactly a reviewed position.

Re:15 years later: remote code execution in qmail by dependenttypes on Thursday May 21, 2020 @05:40AM (#23256493)
I meant it in another way. If he had taken DJB's advice this would not be an issue, so DJB can't be blamed for it. Sorry for the misunderstanding.

That being said, he seems to agree with this. After all he followed said advice in his tool age.

Re:15 years later: remote code execution in qmail by sneak on Thursday May 21, 2020 @01:46AM (#23255197)
Your criticism of the messenger of further evidence of djb's longstanding refusal to deal straightforwardly with security reports is not on topic, IMO.

Not everything is a simple dichotomy.

Re:15 years later: remote code execution in qmail by dependenttypes on Thursday May 21, 2020 @01:55AM (#23255243)
(regarding qmail) It was a security bug back in 2005. It stopped being a security bug when DJB mentioned on the official page about the memory limits.

Regarding the salsa20 implementation: I just mentioned in my previous message why this was not a bug and the only reason that people were upset over it was due to Filo's incompetence.

As for evidence of DJB dealing straightforwardly with security reports: https://news.ycombinator.com/item?id=23250748

I think that https://old.reddit.com/r/crypto/comments/72w42c/statement_re... would be a better example of DJB not properly handling security reports.

Re:15 years later: remote code execution in qmail by dullgiulio on Thursday May 21, 2020 @06:33AM (#23256809)
salsa20 was added in 2012, the warning file was added into the repository in 2016 the earliest (it is not clear when--which is vary bad for security and also shows the move was not advertised.)

Incompetence is a strong word on the wrong target...

Re:15 years later: remote code execution in qmail by dependenttypes on Thursday May 21, 2020 @07:11AM (#23257005)
> the warning file was added into the repository in 2016 the earliest

There is no official public repository. It gets released in tarballs.

This does indeed make him seem slightly less incompetent though.

> which is vary bad for security

It is a framework for benchmarking cryptographic algorithms.

Re:15 years later: remote code execution in qmail by vinay_ys on Wednesday May 20, 2020 @04:41PM (#23251522)
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.
Re:15 years later: remote code execution in qmail by cadence- on Wednesday May 20, 2020 @06:45PM (#23252877)
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.
Re:15 years later: remote code execution in qmail by reaperducer on Wednesday May 20, 2020 @07:37PM (#23253306)
A lot of it would get you banned from HN and similar fora today.
Re:15 years later: remote code execution in qmail by cadence- on Wednesday May 20, 2020 @06:51PM (#23252938)
Here is my favourite that I remember to this day: https://seclists.org/bugtraq/1998/Nov/117
Re:15 years later: remote code execution in qmail by Snelius on Wednesday May 20, 2020 @10:43PM (#23254339)
Hah, "How many people relaxed after installing tcpd -DPARANOID, instead of pestering their vendors for a real fix?" Sounds similar here ;)
Re:15 years later: remote code execution in qmail by Quekid5 on Thursday May 21, 2020 @07:50AM (#23257282)
Yeah, the lack of self-reflection is pretty palpable.
Re:15 years later: remote code execution in qmail by koheripbal on Wednesday May 20, 2020 @04:13PM (#23251227)
I don't understand. Most people with a big ego would not want a critical vulnerability associated with them. Can you elaborate?
Re:15 years later: remote code execution in qmail by kbenson on Wednesday May 20, 2020 @05:47PM (#23252270)
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

Re:15 years later: remote code execution in qmail by dependenttypes on Thursday May 21, 2020 @01:18AM (#23255057)
He did reward some other bounties that he made, I can only think the ones from his cryptographic algorithms at the moment though.

Edit: See https://news.ycombinator.com/item?id=23250748

Re:15 years later: remote code execution in qmail by rurban on Wednesday May 20, 2020 @06:14PM (#23252599)
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.

Re:15 years later: remote code execution in qmail by Chlorus on Wednesday May 20, 2020 @11:53PM (#23254633)
> One should not use so much memory for a mail server, way too risky.

Is there a table or formula I can consult that will give this particular dumb person(myself) a handy guide for what amounts of addressable memory will introduce security risks for particular applications? Apparently more than 32-bits is obviously[0] a problem for email; what about databases? Should I feel bad I use more than 64GB of memory in my DB installations? Am I being irresponsible? What about web servers? How much risk does each additional bit of memory add?

My final question is, why does pretty much every other software maintainer not have a problem fixing the memory allocation themselves, obviating the need for external tools to fix these issues? I guess they're going the extra mile!

[0] So obvious a problem that sendmail, postfix, and exim don't require me to apply workarounds for it for some reason. Very irresponsible of them, if you ask me.

Re:15 years later: remote code execution in qmail by kbenson on Wednesday May 20, 2020 @07:26PM (#23253227)
> Problem is, these switches were not default, people didnt use it because they are dumb

Pushing complexity from a very small group (in this case, one person) who knows the system intimately to many orders of magnitude more people that are meant to have a functional knowledge of how it operates but not necessarily be intimate with it is a losing proposition, and not any tenet of how I would consider developing secure software.

If the software is only supposed to be run under process limits, and over a specific process limit all bets are off security wise, then the program should probably check and report problems with large process limits when it starts. Or, as you posit, dying if built for 64 bit, since its assumptions don't necessarily hold.

Re:15 years later: remote code execution in qmail by kelnos on Wednesday May 20, 2020 @09:54PM (#23254108)
My opinion on this is that if you're going to claim that you write the most secure software in the world, it should be secure by default. It shouldn't require you to modify the configuration in a particular way, or start it in a particular way, in order to be secure. The more details you need to know in order to secure something, more less likely you'll tick off all those boxes.

To me, this is just DJB's ego not allowing him to admit that he made mistakes.

Re:15 years later: remote code execution in qmail by loeg on Wednesday May 20, 2020 @04:29PM (#23251389)
His ego has transcended objective reality and he claimed (in 2005, and continues to claim in 2020) it isn't a vulnerability.
Re:15 years later: remote code execution in qmail by mcguire on Wednesday May 20, 2020 @07:08PM (#23253072)
He asserted that it was unexploitable, and thus not a vulnerability. Fixing the code would have implied that it might have been a vulnerability, and he might have been wrong. Can't have that.