Hacker News Reader

Comment by dozzie | Hacker News Reader

Ah yes, the one that djb denied to somebody who found a resource exhaustion hole, from what I remember.

> 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.

Sounds like the no true scottsman fallacy to me.

That's adorably quaint. I wonder if djb still believes that's the case?

qmail-smtpd is a very small binary that is run per connection received through tcpserver.

There is no good reason to give it even a gigabyte of ram, let alone many multiple gigs.

I would say the notion that small binaries working together (the unix way) would still allow him to believe to be the case.

Nobody "gives" set amounts of memory to their processes at all, so this thinking is backwards to begin with. The vulnerability is legitimate.

I seem to remember that the installation directions included something to limit memory size, and trying to install without reading the directions would fail well before opening a listener port.

systemd by default limits programs to a certain amount of memory (this bit me in the ass while working on getting OpenStack running on Ubuntu 16.04, and MySQL would get killed because of memory usage).

Various other systems also limit with things like /etc/login.conf on FreeBSD. There is also /etc/security/limits.conf on Linux for non-systemd stuff.

Limits for memory usage/open files/things of that nature are natural. You don't want one runaway process to cause the rest of your system to OOM.

http://www.guninski.com/qmailcrash.html

http://www.guninski.com/where_do_you_want_billg_to_go_today_...

There is actually a section on the web site that addresses that one.

Reply on news.ycombinator.com