4 ms·

This is a known attack for quite sometime. The Apache Web Server, which I love/hate, has for years never really been 100% secure because of issues with how the

This is a known attack for quite sometime. The Apache Web Server, which I love/hate, has for years never really been 100% secure because of issues with how the Linux kernel handles FollowSymLinks and SymLinksIfOwnersMatch. You can purchase special distributions of Linux that are patched against this vulnerability, and also I believe this gentleman [1] has released an OS patch that sort of fixes the issue. Anyway I switched to Caddy [2] even though I deeply love Apache and it has an amazing history behind it. [1] https://twitter.com/hanno https://twitter.com/hanno [2] https://caddyserver.com/ https://caddyserver.com/

xrisk 7y ago
Caddy is brilliant. Configuration is so simple and easy compared to Apache / Nginx.
- tdhz77 7y ago
  Have you tried Traefik ?
  - tepidandroid 7y ago
    Different use-cases.
  - cargoshipit 7y ago
    Are you serious? Their kubernetes setup guide is longer than War and Peace https://docs.traefik.io/v1.4/user-guide/kubernetes/ https://docs.traefik.io/v1.4/user-guide/kubernetes/
    - tdhz77 7y ago
      Not sure what that has to do with anything.
- mholt 7y ago
  Thank you!! These comments made my day. Feel free to open an issue on GitHub if you have any ideas for how to improve it even more, since the sky's the limit for Caddy 2. https://github.com/mholt/caddy/issues https://github.com/mholt/caddy/issues
jetpks 7y ago
The vulnerability is solved pretty easily by doing your ownership checks _after_ you've opened (but not served) the file. At least, that's how I did it [1]. Despite our pleas and submitted patches, Apache wasn't interested in fixing it upstream. [1] https://github.com/bluehost/apache-symlink-patch https://github.com/bluehost/apache-symlink-patch
- cyphar 7y ago
  Small correction -- you'd want to O_PATH, then verify, and then do a real open (by doing a re-open through /proc/self/fd). Sometimes, tricking you into opening a file is sufficient to cause problems.

xrisk 7y ago

Caddy is brilliant. Configuration is so simple and easy compared to Apache / Nginx.

tdhz77 7y ago
Have you tried Traefik ?
- tepidandroid 7y ago
  Different use-cases.
- cargoshipit 7y ago
  Are you serious? Their kubernetes setup guide is longer than War and Peace https://docs.traefik.io/v1.4/user-guide/kubernetes/ https://docs.traefik.io/v1.4/user-guide/kubernetes/
  - tdhz77 7y ago
    Not sure what that has to do with anything.
mholt 7y ago
Thank you!! These comments made my day. Feel free to open an issue on GitHub if you have any ideas for how to improve it even more, since the sky's the limit for Caddy 2. https://github.com/mholt/caddy/issues https://github.com/mholt/caddy/issues

jetpks 7y ago

The vulnerability is solved pretty easily by doing your ownership checks _after_ you've opened (but not served) the file. At least, that's how I did it [1]. Despite our pleas and submitted patches, Apache wasn't interested in fixing it upstream. [1] https://github.com/bluehost/apache-symlink-patch https://github.com/bluehost/apache-symlink-patch

cyphar 7y ago
Small correction -- you'd want to O_PATH, then verify, and then do a real open (by doing a re-open through /proc/self/fd). Sometimes, tricking you into opening a file is sufficient to cause problems.