3 ms·

No HTTP server software can be guaranteed to be completely secure, but OpenBSD httpd is at least privsep, always runs in a chroot, and each process is pledged q

by brynet 3y ago

No HTTP server software can be guaranteed to be completely secure, but OpenBSD httpd is at least privsep, always runs in a chroot, and each process is pledged quite tightly, that means http/tls protocol speakers can't write to the filesystem, can't fork any processes, and can't execve(2). lighttpd doesn't even chroot by default.

fbdab103 3y ago
Surely the most secure would have to be a server written in a memory safe language? While you can do stupid things in any language, I would jump to Caddy (Go) or a Rust based toolkit before anything written in C.
- tyfon 3y ago
  You can do stupid things with "memory safe" languages too, and nothing protects you from misconfiguration. The bsd approach of just locking it down seems to be to be at least as secure if not more to me.
  - dwheeler 3y ago
    Trye, but 70% of vulnerabilities are memory safety problems. String handling is more of a pain in C, too. C is a terrible choice for this use case.
- bayindirh 3y ago
  I love how having a couple of new languages make older, hardened programs insecure in an instant. These security mechanisms are added and implemented for reasons and they're tested with the flame of time and non-hardened connections. I'd take a battle-tested and mature implementation over a newer one any day, even if it's written in Malbolge.
  - sweetjuly 3y ago
    There's no reason you couldn't also pledge an HTTP server written in a safe language too. One key thing to keep in mind is that exploit mitigations are largely about limiting degrees of freedom. It's quite hard to contain an attacker who has gained code execution in a process (such as due to memory corruption) due to the massive amount of control they have. On the other hand, if you're able to prevent them from gaining such a strong foothold to begin with (such as by using safer languages which don't have such issues), you're in a much better spot because now they don't even gain any control over the process.
  - deleted 3y ago
    [deleted]
  - rini17 3y ago
    They have become insecure not because of new languages but because web is no longer just serving a bunch of files. You are delivering executable text mixed with untrusted input that must not improperly interfere with other users and for that you need impeccable string handling. Just reliably segfaulting every time there's a problem won't do.
  - ekidd 3y ago
    > I love how having a couple of new languages make older, hardened programs insecure in an instant. As someone who has been dealing with Unix since the early 90s, most of those old C programs were always security nightmares. There were a few exceptions: djb's stuff, dovecot and (surprisingly) Apache. But most of the other popular C servers were absolutely riddled with buffer overflows and other security problems. The Morris worm, the entire rsh family, you name it. Sendmail was awful for a long time, too. Memory corruption errors still make up 70% of security holes in modern C and C++ code, and that's after decades of improvement. That entire set of vulnerabilities could be avoided in the 90s by using Perl 5 or Java, which were insanely popular. (PHP came with its own supply of security holes, both in the interpreter, the language design, and the awful database APIs.) We've had popular memory-safe options for decades. All Rust brings to the table is the ability to be memory safe without needing GC (which is great). But with rare exceptions, the popular C servers were always full of holes.
- LanzVonL 3y ago
  [flagged]
- hulitu 3y ago
  > Surely the most secure would have to be a server written in a memory safe language? Like rust which downloads unverified crates from the internet. /s
rini17 3y ago
How does all of that prevent leaks and exploits of _user_ data that httpd has access to?
- deleted 3y ago
  [deleted]

by brynet 3y ago

fbdab103 3y ago

Surely the most secure would have to be a server written in a memory safe language? While you can do stupid things in any language, I would jump to Caddy (Go) or a Rust based toolkit before anything written in C.

tyfon 3y ago
You can do stupid things with "memory safe" languages too, and nothing protects you from misconfiguration. The bsd approach of just locking it down seems to be to be at least as secure if not more to me.
- dwheeler 3y ago
  Trye, but 70% of vulnerabilities are memory safety problems. String handling is more of a pain in C, too. C is a terrible choice for this use case.
bayindirh 3y ago
I love how having a couple of new languages make older, hardened programs insecure in an instant. These security mechanisms are added and implemented for reasons and they're tested with the flame of time and non-hardened connections. I'd take a battle-tested and mature implementation over a newer one any day, even if it's written in Malbolge.
- sweetjuly 3y ago
  There's no reason you couldn't also pledge an HTTP server written in a safe language too. One key thing to keep in mind is that exploit mitigations are largely about limiting degrees of freedom. It's quite hard to contain an attacker who has gained code execution in a process (such as due to memory corruption) due to the massive amount of control they have. On the other hand, if you're able to prevent them from gaining such a strong foothold to begin with (such as by using safer languages which don't have such issues), you're in a much better spot because now they don't even gain any control over the process.
- deleted 3y ago
  [deleted]
- rini17 3y ago
  They have become insecure not because of new languages but because web is no longer just serving a bunch of files. You are delivering executable text mixed with untrusted input that must not improperly interfere with other users and for that you need impeccable string handling. Just reliably segfaulting every time there's a problem won't do.
- ekidd 3y ago
  > I love how having a couple of new languages make older, hardened programs insecure in an instant. As someone who has been dealing with Unix since the early 90s, most of those old C programs were always security nightmares. There were a few exceptions: djb's stuff, dovecot and (surprisingly) Apache. But most of the other popular C servers were absolutely riddled with buffer overflows and other security problems. The Morris worm, the entire rsh family, you name it. Sendmail was awful for a long time, too. Memory corruption errors still make up 70% of security holes in modern C and C++ code, and that's after decades of improvement. That entire set of vulnerabilities could be avoided in the 90s by using Perl 5 or Java, which were insanely popular. (PHP came with its own supply of security holes, both in the interpreter, the language design, and the awful database APIs.) We've had popular memory-safe options for decades. All Rust brings to the table is the ability to be memory safe without needing GC (which is great). But with rare exceptions, the popular C servers were always full of holes.
LanzVonL 3y ago
[flagged]
hulitu 3y ago
> Surely the most secure would have to be a server written in a memory safe language? Like rust which downloads unverified crates from the internet. /s

rini17 3y ago

How does all of that prevent leaks and exploits of _user_ data that httpd has access to?

deleted 3y ago
[deleted]