[HN Gopher] Developers fix multitude of vulnerabilities in Apach...
___________________________________________________________________
Developers fix multitude of vulnerabilities in Apache HTTP Server
Author : feross
Score : 128 points
Date : 2021-09-24 17:17 UTC (5 hours ago)
(HTM) web link (portswigger.net)
(TXT) w3m dump (portswigger.net)
| ezekiel68 wrote:
| It turns out that "multitude", in this case, is 5. (Still glad
| they got patched, of course)
| JulianMorrison wrote:
| Hrair
| hinkley wrote:
| 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".
| torstenvl wrote:
| A very good number, some people say great, I don't know,
| maybe even one of the very best! That's what people are
| saying.
| junon wrote:
| 5 vulnerabilities at once is a lot.
| bityard wrote:
| You missed a very good dad joke.
| TekMol wrote:
| On Debian 10, "apt update && apt upgrade" says all packages are
| up to date.
|
| Did the fixes not land in Debian yet?
| dtech wrote:
| Debian back-ports patches. I guess they'll need some time
| although they are usually informed in advance
| wccrawford wrote:
| >All five flaws are resolved with HTTP Server 2.4.49.
|
| The WSL version of Ubuntu is reporting 2.4.41 for me still. I
| don't know about the real version.
| xxpor wrote:
| WSL ubuntu uses the same repos as regular ubuntu so they
| should be in sync
| beermonster wrote:
| Quite often there are many vulnerabilities with no 'fixed-in'
| version (as it's not yet fixed) and this can be for some time.
|
| https://security-tracker.debian.org/tracker/status/release/s...
| is one place to look through in the past I think there was a
| better link I used to use to find all vulnerable packages which
| were awaiting a fix - but I can't seem to find it now.
| dspillett wrote:
| Could be the case. Could also be that the bugs were never in
| Debian if they were introduced recently as Debian stable is
| relatively conservative about package updates other than for
| security purposes.
| forbiddenlake wrote:
| You can check the status of vulnerabilities like this with a
| quick Google of "Debian" plus the CVE. Example for this one is
| https://security-tracker.debian.org/tracker/CVE-2021-33193 .
| When a patch is released, the package may not say 2.4.49, but
| that page will have the exact version number with the fix.
| TekMol wrote:
| This page confused me. It seems to have bugs for _Android_?
|
| Example:
|
| https://security-tracker.debian.org/tracker/CVE-2021-30521
|
| "Heap buffer overflow in Autofill in Google Chrome on Android
| prior to 91.0.4472.77 allowed a remote attacker to perform
| out of bounds memory access via a crafted HTML page."
| meibo wrote:
| While bugs like that aren't "confirmed" to affect desktop
| versions of software, the underlying bug is still in the
| Desktop codebase and needs to be treated as a security
| issue.
| kimi wrote:
| Anybody still using Apache?
| omoikane wrote:
| Apache is at 26%, behind nginx's 36%, according to Netcraft:
|
| https://news.netcraft.com/archives/category/web-server-surve...
| cestith wrote:
| 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 real
| thing.
|
| Shared hosting is still huge for small sites, and the major
| control panels for that (cPanel, Plesk, DirectAdmin, vDeck)
| still support Apache as the primary web server.
| onli wrote:
| That's not debt. Those are working configurations on a fully
| supported web server with active development. There is zero
| reason to change them.
| blakewatson wrote:
| This. There's nothing wrong with using mature technology
| that is still being developed. LAMP is still a perfectly
| fine choice if it's what you want to use.
| trulyme wrote:
| And Apache supports .htaccess files which are great for
| hosting (nginx doesn't, afaik).
| rcoder wrote:
| 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.
|
| Furthermore, these modules could themselves expose language-
| specific APIs; ergo `mod_perl` and its ilk, which provide a
| bunch of useful building blocks for a full-stack webapp but are
| entirely specific to Apache's module API (vs. something more
| standard like FCGI, WSGI, etc.)
|
| I've worked at some shops with heavy investments in Apache-
| based application servers and the cost of moving away from
| HTTPD modules and towards a more standalone, Apache-free
| implementation was generally quite high. Usually you need some
| other forcing function (rewrite in a new language, microservice
| decomposition, etc.) to justify the investment.
| francislavoie wrote:
| 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
| mholt wrote:
| > 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.
| [deleted]
| nobody9999 wrote:
| >Anybody still using Apache?
|
| A similar number of folks as are using nginx[0]
|
| [0] https://w3techs.com/technologies/overview/web_server
| 0x000000001 wrote:
| Considering that it has a lot of features Nginx makes you pay
| for, yes
| brendanclune wrote:
| It appears so [1]. It's surprising how far behind most non-tech
| industries are when it comes to legacy software (not sure I'd
| call Apache "legacy", but still). I'd also be interested to see
| the stats for IT/developer positions in tech vs. non-tech
| fields. My intuition suggests that there are a lot more Apache
| sysadmins than you'd think.
|
| [1] https://w3techs.com/technologies/overview/web_server
| jmnicolas wrote:
| What's wrong with Apache? (honest question)
| beamatronic wrote:
| I was looking for a pre-hardened httpd just for serving
| static html files, is there one?
| ldoughty wrote:
| Probably not the answer you want to hear... But I push that
| stuff to AWS S3 website and put a CDN in front for SSL...
| that's my solution for "easy secure static site" when I
| don't want to invest more than an hour or so a year on the
| infrastructure... But obviously that's not for everyone.
|
| Edit: specific to your request, I would probably set up a
| container pointing to the latest apache build, and write a
| script to pull the latest image then roll over the
| container... Don't need to wait for your OS of choice to
| have the fixed versions... Your never more than a day
| behind
| juangacovas wrote:
| lighttpd is still a thing (I use it for very critical
| stuff)
| lhoff wrote:
| Maybe Gatling fits your needs
|
| https://www.fefe.de/gatling/
| notRobot wrote:
| https://github.com/emikulic/darkhttpd
|
| darkhttpd is an option
| LinuxBender wrote:
| Nothing really. Historically Apache HTTPD was slower than the
| newer web servers like NGinx when Apache HTTPD 2.2 was the
| mainline version. This is no longer the case with Apache 2.4
| using the latest APR libraries. 2.4 has been out for a very
| long time, but some Linux distros were slow to uptake it.
| da_chicken wrote:
| Just like some of them were slow to take on 2.2 over 2.0,
| and 2.0 over 1.2.
|
| Web servers have historically been pretty conservative as
| far as software goes.
| trey-jones wrote:
| 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 for most applications.
|
| There are other reasons to use nginx, and there are other
| reasons to use Apache. Both are fine, and I hear
| https://caddyserver.com/ is coming in hot!
| mholt wrote:
| Yeah; and unlike nginx and Apache, Caddy has a higher
| degree of memory safety, so it's impervious to a whole
| class of vulnerabilities.
| SahAssar wrote:
| Might be nice to disclose your involvement when
| commenting on caddy-related threads.
| mholt wrote:
| > I'm the author of the Caddy web server.
| SahAssar wrote:
| 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.
| throw_m239339 wrote:
| > Yeah; and unlike nginx and Apache, Caddy has a higher
| degree of memory safety, so it's impervious to a whole
| class of vulnerabilities.
|
| At the expense of the memory footprint because developed
| with Go. Hi Caddy creator!
| eric_h wrote:
| > At the expense of the memory footprint because
| developed with Go. Hi Caddy creator!
|
| Makes sense to me that something built in a language with
| more memory safety than C would use more memory, but is
| it really significant in practice? I use go every day and
| memory usage has not been a significant issue for many
| applications.
| [deleted]
| klaussilveira wrote:
| Definitely not the right place, but thank you for
| creating Caddy. :)
| mholt wrote:
| Thanks, you're welcome!
| jart wrote:
| 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
| xorcist wrote:
| 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.
| trulyme wrote:
| Nginx configs do look more readable, but they have a lot
| of gotchas themselves. Quite surprising actually.
| killingtime74 wrote:
| Caddy also does the whole Let's Encrypt thing for you for
| SSL
| yourad_io wrote:
| There's a plugin for nginx that works well:
|
| $ apt-get install python3-certbot-nginx
|
| $ sudo certbot --nginx -d example.com -d www.example.com
|
| https://www.nginx.com/blog/using-free-ssltls-
| certificates-fr...
|
| On the other hand, caddy seems to auto renew them as well
| - one less cron job:
|
| > Automatic HTTPS provisions TLS certificates for all
| your sites and keeps them renewed.
|
| https://caddyserver.com/docs/automatic-https
|
| Neat, but still not sold.
| codegeek wrote:
| This reminds me of the classic "Anybody still using PHP"
| question.
| bcrosby95 wrote:
| We still use Apache. It's never been a bottleneck for us so we
| haven't had a reason to switch.
| iBotPeaches wrote:
| 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 available and problem resolved.
|
| [1]
| https://github.com/apache/httpd/commit/8720881b0634383145e87...
| sam_lowry_ wrote:
| Those who can't program, go to security research.
| junon wrote:
| Do you know what security research entails?
| edoceo wrote:
| Full vulnerability list:
| https://httpd.apache.org/security/vulnerabilities_24.html
| [deleted]
| habibur wrote:
| Sometimes I think custom writing your own http server might not
| be a bad idea after all.
|
| Lots of security holes in your custom write? Yes! But the hacker
| needs to be dedicated to exploiting your one server specifically
| to find it.
|
| In exchange you are safe from of all those : vulnerabilities in
| the wild => script kiddies => mass exploitation => your are now
| hacked type of situations.
| tsimionescu wrote:
| I don't see how this could be true for an HTTP server. If we
| were discussing some custom protocol, sure. But with HTTP, you
| are far more likely to repeat well-known mistakes and
| vulnerabilities that have long-since been eliminated from the
| popular HTTP servers.
| Zababa wrote:
| That's an interesting point. I would love to see someone
| testing this assumption.
| hangonhn wrote:
| This is a great idea where people can submit their own web
| servers that have some basic functionalities and are on the
| side would be users who gets points/karma for exploiting them
| under some threshold like 3 hours. Maybe something like
| DevCon's Capture-the-Flag but online.
| valbaca wrote:
| I encourage you to test this theory at your earliest
| convenience.
| jjoonathan wrote:
| Security through obscurity is great for preventing low-effort
| attacks at low-scale, yes.
|
| The market for security skills tends to be more interested in
| protecting targets that can draw high-effort attacks, or low-
| effort attacks at scale, so there's good reason for the
| "security through obscurity = bad" meme. You won't get in
| trouble by incorrectly assuming "security through obscurity =
| bad," but you can definitely get in trouble by incorrectly
| generalizing "security through obscurity = good enough." It
| makes sense to err in the direction of least damage.
| rastafang wrote:
| > 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
| indigodaddy wrote:
| 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.
| lanstin wrote:
| 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.
| bob1029 wrote:
| Relying on obfuscation as _part_ of your security posture is a
| fantastic idea IMO. Just be prepared for what happens if a
| human figures out your specific puzzle box.
|
| We like exposing our private B2B web services in such a way
| that an attacker would be led to think the web server is
| totally fucked up or otherwise mis-configured if they don't
| understand the proprietary protocol. It's not that they could
| never understand it, but it would take a significant, targeted
| effort to even begin attacking our system in a direct fashion.
| Even if they figure out the obfuscation, they are still going
| to have to fight through a moat of PBKDF2 & hardware tokens.
|
| To me, obfuscation is all about minimizing the impact of
| automated, mass, 0-day assaults. Some person will always be
| able to walk back something another person built. You can
| mitigate legions of scripts by cleverly dropping TCP
| connections when a resource isn't requested in just the right
| way.
|
| Another fun option is to build a honey pot around your web
| service which has the ability to ferret naughty TCP pipes off
| to the hacker matrix where you then simulate all manner of PII-
| rich data sources for them to worry about (instead of your
| actual business).
| Enhex wrote:
| writing your own on top of established networking lib will have
| much less code thus smaller attack surface.
| DonHopkins wrote:
| It's called Apache HTTP server because it's A Patchy HTTP Server.
|
| https://www.mail-archive.com/fedora-list@redhat.com/msg06924...
|
| >On Jul 16, 2008, Les Mikesell wrote:
|
| >> Alexandre Oliva wrote:
|
| >> Apache wasn't the original name.
|
| >It was and it wasn't. It was indeed a bunch of patches on top of
| the (also younger) NCSA http server. That's where "a patchy http
| server" came from. But that was '90s already, some ten years
| after GNU started.
| FreezingKeeper wrote:
| Every day someone is born who has never seen The Flintstones
| RobotCaleb wrote:
| Everyday someone is born who hasn't seen everything, or
| anything.
| aargh_aargh wrote:
| https://xkcd.com/1053/
___________________________________________________________________
(page generated 2021-09-24 23:00 UTC)