Live data from Hacker News

Developers fix multitude of vulnerabilities in Apache HTTP Server

portswigger.net

51–60 of 115 posts

Re: Developers fix multitude of vulnerabilities in Apache HTTP Server

#51

This was an interesting security patch that marked the first time in my memory that updating Apache led to an immediate regression. A few hours after taking this upgrade many systems experienced such strange timeout errors. Connections were low and couldn't pinpoint the misleading behavior that looked like a slowloris attack, with no connections. Half a day later with no resolution in research a new patch [1] was ava…

Those who can't program, go to security research.

Do you know what security research entails?

Re: Developers fix multitude of vulnerabilities in Apache HTTP Server

#52
post #47

It turns out that "multitude", in this case, is 5. (Still glad they got patched, of course)

Multitude: a very great number 5 is a very good number but I don’t know if I’d go so far as to call it “great”.

5 vulnerabilities at once is a lot.

Re: Developers fix multitude of vulnerabilities in Apache HTTP Server

#53
post #33
post #4

Anybody still using Apache?

Note: several folks have pointed out that I was totally wrong about Caddy. Sorry! I should look at it again before I spout off any more opinions about it. Unlike nginx or Caddy^H^H^H^H^H, the Apache design and community encouraged writing modules (roughly akin to "middleware" in the modern server-side web stack) that hooked directly into the web server, rather than just using it as a static host + L7 proxy. Furthermo…

I don't understand the claims you're making. Caddy is very pluggable, you can write a request handler middleware very easily: https://caddyserver.com/docs/extending-caddy

Re: Developers fix multitude of vulnerabilities in Apache HTTP Server

#54
post #33
post #4

Anybody still using Apache?

Note: several folks have pointed out that I was totally wrong about Caddy. Sorry! I should look at it again before I spout off any more opinions about it. Unlike nginx or Caddy^H^H^H^H^H, the Apache design and community encouraged writing modules (roughly akin to "middleware" in the modern server-side web stack) that hooked directly into the web server, rather than just using it as a static host + L7 proxy. Furthermo…

> Unlike nginx or Caddy, the Apache design and community encouraged writing modules (roughly akin to "middleware" in the modern server-side web stack) that hooked directly into the web server, rather than just using it as a static host + L7 proxy.

Huh? I must be misunderstanding, because everything in Caddy is a module, even its HTTP server, and all its middleware handlers are equally modules that you can plug in as much as any other module you could write and publish.

Some Caddy modules also expose dynamic scripting / language interpretation capabilities as well. Caddy is used for well more than just static files and HTTP reverse proxying.

Re: Developers fix multitude of vulnerabilities in Apache HTTP Server

#55

Earlier quoted context omitted.

What's wrong with Apache? (honest question)

About a decade ago nginx stormed onto the scene with event based multi-processing, and even though mpm-event became a thing not too long after that, Apache retained mpm-prefork and then mpm-worker as defaults for a very long time, and lost a lot of market share. A lot of people still retain the notion that nginx is "just faster" or "just better" which is not necessarily the case. Apache with mpm-event is just fine fo…

redbean is a pure fork() web server and according to ab it is much faster than nginx. I feel like we've come full circle with history. Apache started off with fork() since it offers the strongest security versus other i/o models. The problem is that code bloat makes fork() go slower so as Apache ballooned over the years there was this race to the bottom in terms of i/o models, caused by tragedy of the commons. https://youtu.be/1ZTRb-2DZGs?t=761

Re: Developers fix multitude of vulnerabilities in Apache HTTP Server

#56
post #30

Earlier quoted context omitted.

About a decade ago nginx stormed onto the scene with event based multi-processing, and even though mpm-event became a thing not too long after that, Apache retained mpm-prefork and then mpm-worker as defaults for a very long time, and lost a lot of market share. A lot of people still retain the notion that nginx is "just faster" or "just better" which is not necessarily the case. Apache with mpm-event is just fine fo…

Yeah; and unlike nginx and Apache, Caddy has a higher degree of memory safety, so it's impervious to a whole class of vulnerabilities.

Definitely not the right place, but thank you for creating Caddy. :)

Re: Developers fix multitude of vulnerabilities in Apache HTTP Server

#57

Earlier quoted context omitted.

What's wrong with Apache? (honest question)

About a decade ago nginx stormed onto the scene with event based multi-processing, and even though mpm-event became a thing not too long after that, Apache retained mpm-prefork and then mpm-worker as defaults for a very long time, and lost a lot of market share. A lot of people still retain the notion that nginx is "just faster" or "just better" which is not necessarily the case. Apache with mpm-event is just fine fo…

To be fair, the event worker in Apache and nginx are roughly the same age, 2004.

Smaller web servers have been event based since they first showed up, it is the natural way to build them. There was no epoll() available, but a select() loop is pretty much the same thing. The super useful thttpd had been around a long time at that time.

What caused people to start using non-forking web servers for regular public web applications was probably that PHP finally got a stable FastCGI mode going about ten years ago. Because, honestly, most of the web is PHP and it was even more dominant back them.

And when people posted their web server configs in forums at that time, nginx configs were much more readable and concise. The easier config format is what caused its popularity to soar, not that it used a particular syscall half a decade earlier.

Re: Developers fix multitude of vulnerabilities in Apache HTTP Server

#58
post #50

Earlier quoted context omitted.

Might be nice to disclose your involvement when commenting on caddy-related threads.

> I'm the author of the Caddy web server.

I'm guessing you mean the about section of your profile. I'm just saying that it's nice to make that more visible when you have that sort of involvement in the topic and it is not obvious.

Re: Developers fix multitude of vulnerabilities in Apache HTTP Server

#59

Earlier quoted context omitted.

> In exchange you are safe from of all those : vulnerabilities in the wild => script kiddies => mass exploitation => your are hacked type of situations. Not sure about that... You might commit some of the same mistakes that they did

Exactly what I was thinking. You’re more likely just to have a wide open and highly/easily penetrable/vulnerable server up for grabs at that point.

Presumably you'll have less features. I wrote a web server (in the 90s, so forgivable?), and I only implemented GET and query string for the API data, and nothing fancy, no cache headers, no redirects, no multipart, no gzip, no content-encoding negotiation, etc. Some of the APIs it hosted were ultimately hacked (thru encryption of the encrypted query string via plain DES, and the key was determined), but, so far as I know, it was not itself ever compromised.

Re: Developers fix multitude of vulnerabilities in Apache HTTP Server

#60
post #14
post #4

Anybody still using Apache?

Lots of companies that have been around a while and haven't replaced legacy applications still run those behind the web server they were designed to run behind. Moving to another server seems simple until you actually try to do that with a handful of 15-year-old sites with proxy rules, rewrites, custom headers, and such in one server's central config file and a bunch of per-directory access files. Technical debt is a…

And Apache supports .htaccess files which are great for hosting (nginx doesn't, afaik).
Post reply on HN