3 ms·

> 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

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

fimbulvetr 9y ago
Sounds like the no true scottsman fallacy to me.
kstrauser 9y ago
That's adorably quaint. I wonder if djb still believes that's the case?
- X-Istence 9y ago
  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.
  - lawnchair_larry 9y ago
    Nobody "gives" set amounts of memory to their processes at all, so this thinking is backwards to begin with. The vulnerability is legitimate.
    - yuubi 9y ago
      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.
    - X-Istence 9y ago
      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.
jwilk 9y ago
http://www.guninski.com/qmailcrash.html http://www.guninski.com/qmailcrash.html http://www.guninski.com/where_do_you_want_billg_to_go_today_4.html http://www.guninski.com/where_do_you_want_billg_to_go_today_...

fimbulvetr 9y ago

Sounds like the no true scottsman fallacy to me.

kstrauser 9y ago

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

X-Istence 9y ago
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.
- lawnchair_larry 9y ago
  Nobody "gives" set amounts of memory to their processes at all, so this thinking is backwards to begin with. The vulnerability is legitimate.
  - yuubi 9y ago
    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.
  - X-Istence 9y ago
    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.

jwilk 9y ago

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