8 ms·

FYI : If you have a NextCloud or Owncloud installation. The recommended nginx configuration is vulnerable [1] [1] https://nextcloud.com/blog/urgent-security-is

FYI : If you have a NextCloud or Owncloud installation. The recommended nginx configuration is vulnerable [1] [1] https://nextcloud.com/blog/urgent-security-issue-in-nginx-php-fpm/ https://nextcloud.com/blog/urgent-security-issue-in-nginx-ph...

ralala 7y ago
The production-fpm docker image has not yet received any updates - correct?
heavyset_go 7y ago
This is a case study in why you shouldn't expose your self-hosted services to the internet.
- kuzimoto 7y ago
  I have been thinking about this a lot lately. What is the best alternative, only accessing your services through a VPN?
  - PureParadigm 7y ago
    I've transitioned all my self-hosted services to behind a Wireguard VPN. This even includes SSH, so there are no ports exposed except the UDP port for Wireguard.
  - heavyset_go 7y ago
    VPN or SSH tunnels. I just use WireGuard these days.
  - antocv 7y ago
    I hide mine behind letsencrypt, just dont put nextcloud.yourdomain.com but put it under a path like yourdomain.com/shortPhrase/nextcloud where shortPhrase is something like noway pizde and so on. Then dont share your links publicly.
    - organsnyder 7y ago
      How does Let's Encrypt "hide" anything? Quite the contrary—the list of certs granted is publicly available (as it is for all CAs, I believe).
      - jamespo 7y ago
        Get a wildcard
      - Xylakant 7y ago
        TLS hides the path from a potential attacker that could observe traffic. Putting your nextcloud instance on a nonstandard path might help in this case, but - if I read the issue correctly - not in this cases
        labawi 7y ago
        I haven't studied the issue, but it requires to access/execute php, no? If configuration requires a path to get further than a canned reply from nginx (403, 404, static page..), then it should reduce attack surface a lot. You should not be able to get anywhere near php without the path.
        antocv 7y ago
        Exactly.
      - gsich 7y ago
        Or use a wildcard cert.
      - antocv 7y ago
        Lets Encrypt does not per se, but TLS does is what I mean with letsencrypt, thats why I said dont put a domain name for your nextcloud instance - because even if you get a wildcard cert, the domain names are public, and every lookup you do of your subdomain is visible to all ISPs, so even if you call it zyrkon.yourdomain.com someone can still attempt to make requests to it like /index.php?a Put your services, on a shared domain name, only yourdomain.com and under a sub-path, like yourdomain.com/thisISAlmostLikeaPassword/nextcloud the subpath is hidden by TLS, unless you make it public by posting it on the internet. And also if you arent careful, like using google "auto-suggest" or just using any Google products, then they will at least know about your path.
  - mfontani 7y ago
    I'm currently serving some of my "internal" services (a wiki, a coffee tracker; things like that - nothing fancy) only from a zerotier network my devices can connect to. Thanks to letsencrypt "now" (for some time, I know.. but I wanted to do this way before they allowed one to) allowing wildcard TLS certs, I host the above on a domain which doesn't have a single public IP DNS entry, yet has full proper "validated, browser approved" TLS cert. IOW, I fire up my zerotier client on my phone, open brave, put the URL in, and off I go. https, and for my eyes only. It's great!
    - tialaramex 7y ago
      Note that in any configuration where you end up asking remote DNS servers about some particular name the operator might well be selling the list of names queried and their answers, this is called "passive DNS" and is aggregated then sold on so it isn't PII by the time it's sold (purchasers can't tell who asked, only what was asked and what the answer was) Where people set wildcard DNS this means passive DNS reveals typos, as well as such "hidden" services. wwww.example.com and ddd.example.com are common typos for www for example whereas int-test.example.com is maybe interesting to black hats.
  - deleted 7y ago
    [deleted]
  - cyphar 7y ago
    The problem with a VPN is that it makes it much harder to get friends and family to use it. Not to mention if you use the link sharing feature of NextCloud, you can't just give strangers VPN access. I do use WireGuard for accessing services like SSH or NFS from the public internet, but the usability hit is a deal-breaker for my family. Client-side certificates would help solve this problem somewhat (you could whitelist only sharing-links for instance), but now you've hit usability problems again. I mitigate code execution worries by running all of my services in individual LXD containers. They're all using isolated user namespaces (unique mappings), and are firewalled away from being able to access my internal network. The data is bind-mounted from a ZFS filesystem which is backed up by the host and uploaded to BackBlaze. The containers themselves are also snapshotted by ZFS. Thus, I think the risks of exploits being able to do much damage are greatly reduced. However, there is still a worry about information disclosure. Yeah, NextCloud can only access the documents it manages -- but some of those documents are somewhat sensitive. I don't know what the ideal solution for this would be (a wholly separate NextCloud instance just for accessing the private stuff? But what if your family needs to access them?). My main worry when hosting NextCloud was that I am entirely trusting the safety of my NextCloud-stored data to an authentication flow that they wrote themselves in PHP (and has had pretty ugly flaws such as silently disabling 2FA or letting you bypass it by clicking "cancel".)
    - heavyset_go 7y ago
      > The problem with a VPN is that it makes it much harder to get friends and family to use it. Not to mention if you use the link sharing feature of NextCloud, you can't just give strangers VPN access. This is a feature. Besides, you can send friends and family a QR code to connect to your WireGuard VPN. It isn't perfect, but it beats having your personal data stolen.
      - cyphar 7y ago
        I don't see how "you cannot use the link sharing feature of NextCloud" is a feature? Seems to be the precise opposite. As for setting everyone else up on the VPN, you could probably get that to work (you'd need to mess with DNS, AllowedIPs, and iptables rules to only allow port 443 access for your family's clients). I might look into that.
- noja 7y ago
  No it's not.
  - s_gourichon 7y ago
    "Argument is an intellectual process. Contradiction is just the automatic gainsaying of anything the other person says." http://www.montypython.net/scripts/argument.php http://www.montypython.net/scripts/argument.php https://www.youtube.com/watch?v=ohDB5gbtaEQ&t=74 https://www.youtube.com/watch?v=ohDB5gbtaEQ&t=74
- nominated1 7y ago
  It’s more evidence that you should assume everything is vulnerable and layer protection. For a home network simple multi-port knocking should be enough (combined with --ctstate NEW even better). If port knocking or SPA is too cumbersome then at least consider limiting access based on GeoIP, block tor exit nodes, etc (ipset is pretty amazing). This can be applied to any service on your network btw, including Wireguard. I like knowing that a portscan of my network shows nothing open. I don’t end up on a list that gets used in the next ‘spray and pray’ attack. Disclaimer: I’m not advocating this for serious use due to replay attacks and IP spoofing via a VPS. This is for home network protection (a boring Class C non target).
  - cyphar 7y ago
    How do you port-scan for WireGuard? The handshake design is designed to not respond to packets in the opening handshake unless the peer already knows your public key.
    - nominated1 7y ago
      Right, portscanning won’t work on Wireguard. Port knocking can provide an additional layer of protection against an unknown vulnerability, even for Wireguard. Sorry for the confusion.
- UnoriginalGuy 7y ago
  Google has gone the opposite direction. I feel like throwing everything behind a VPN and pretending it is secure is a crux. Several famous break-ins over the last ten years have hypothetically been on the inside of that wall. Better to isolate services from each other limiting cross service jumping, than to build security around a single point of failure.
  - heavyset_go 7y ago
    Security is in layers, there's no reason you can't rely on both service and network isolation. Service isolation alone doesn't help when my private data is potentially exposed by this exploit.
  - oarsinsync 7y ago
    > Better to isolate services from each other limiting cross service jumping, than to build security around a single point of failure I agree that it is better, but let’s not forget that building security around a single point of failure is still an improvement, that is simultaneously both high and low friction. Bad: everything exposed to the internet Good: everything behind a VPN Best: Every application on its own micro-segment with access control up to the application layer to restrict all forms of access beyond the bare minimum of what is required. Perfect is the enemy of good. > Google has gone the opposite direction Google scale solutions are great for google scale organisations. They don’t always scale down very well.
    - samus 7y ago
      > Every application on its own micro-segment with access control up to the application layer to restrict all forms of access beyond the bare minimum of what is required. I hope for the operator team that they have good tool support to help administer all the access controls. Over time and across large organisations there are going to be a lot. The even larger challenge must be auditing all these access controls. Services change, and if a connection is not required anymore, it should be painless for its operators to get rid of the corresponding access control.
- dvfjsdhgfv 7y ago
  No, it was definitely not true in the past and is not true now. First, technically there is no much difference between a given app self-hosted by you and hosted by a company charging you for that except that in theory they should worry about these things instead of you. In practice, your experience will vary - companies happen to be as vulnerable as you, and for various reasons their reaction time might be longer. Second, bugs are found every day, and your best bet is to use automatic security updates provided by your distro. Yes, if you host anything, you need to be a bit of a security guy and a small amount of paranoia won't hurt. But to say you must not self-host for security reasons is a gross oversimplification.
  - heavyset_go 7y ago
    > But to say you must not self-host for security reasons is a gross oversimplification. This is a gross oversimplification and straw man argument. You can self-host securely.
swiley 7y ago
I wish there was a webdav server that wasn't a huge PHP thing and had decent authentication/authorization. Almost everything has SFTP built in anyway now though, it's only a matter of time before OSes other than Linux based ones integrate it into the shells and then webdav won't matter so much.
- xienze 7y ago
  Do you just want WebDAV and nothing else? There’s plenty of Docker images for that and most of them are just Apache with the relevant plugin and config.
- Lorkki 7y ago
  Seafile has been working for me as a personal Dropbox replacement, with s3ql for mass storage. It's very light in relation to Nextcloud/Owncloud (a primary criterion for me trying to cheap out on servers), supports WebDAV, role-based access and a bunch of SSO options. The biggest possible drawback I can think of is that it doesn't store files in the plain, so you can't trivially tie in SFTP or serve files from the storage directly.
  - WorkLobster 7y ago
    Re: files in the plain, the server application is bundled with a daemon that allows you to access files locally as a read-only FUSE mount, e.g.: seaf-fuse.sh start /mnt/seafile I find it pretty handy when running a web server on the same host: drop files into a folder on my local machine, and they show up in the web root in seconds!
jacquesm 7y ago
Or something that includes NextCloud or Owncloud even if you do not use them, such as Mailinabox.
jeremija 7y ago
Thanks for the link! The example in the link does not contain the set $path_info $fastcgi_path_info; line after the `fastcgi_split_path_info` directive. My old configuration used the `$fastcgi_path_info`, and the new one uses the `$path_info` variable, so I got the following error while starting nginx: nginx emerg unknown "path_info" variable Might be worth checking out the sample from the Nextcloud Admin Manual[1] [1]: https://docs.nextcloud.com/server/17/admin_manual/installation/nginx.html https://docs.nextcloud.com/server/17/admin_manual/installati...

ralala 7y ago

The production-fpm docker image has not yet received any updates - correct?

heavyset_go 7y ago

This is a case study in why you shouldn't expose your self-hosted services to the internet.

kuzimoto 7y ago
I have been thinking about this a lot lately. What is the best alternative, only accessing your services through a VPN?
- PureParadigm 7y ago
  I've transitioned all my self-hosted services to behind a Wireguard VPN. This even includes SSH, so there are no ports exposed except the UDP port for Wireguard.
- heavyset_go 7y ago
  VPN or SSH tunnels. I just use WireGuard these days.
- antocv 7y ago
  I hide mine behind letsencrypt, just dont put nextcloud.yourdomain.com but put it under a path like yourdomain.com/shortPhrase/nextcloud where shortPhrase is something like noway pizde and so on. Then dont share your links publicly.
  - organsnyder 7y ago
    How does Let's Encrypt "hide" anything? Quite the contrary—the list of certs granted is publicly available (as it is for all CAs, I believe).
    - jamespo 7y ago
      Get a wildcard
    - Xylakant 7y ago
      TLS hides the path from a potential attacker that could observe traffic. Putting your nextcloud instance on a nonstandard path might help in this case, but - if I read the issue correctly - not in this cases
      - labawi 7y ago
        I haven't studied the issue, but it requires to access/execute php, no? If configuration requires a path to get further than a canned reply from nginx (403, 404, static page..), then it should reduce attack surface a lot. You should not be able to get anywhere near php without the path.
        antocv 7y ago
        Exactly.
    - gsich 7y ago
      Or use a wildcard cert.
    - antocv 7y ago
      Lets Encrypt does not per se, but TLS does is what I mean with letsencrypt, thats why I said dont put a domain name for your nextcloud instance - because even if you get a wildcard cert, the domain names are public, and every lookup you do of your subdomain is visible to all ISPs, so even if you call it zyrkon.yourdomain.com someone can still attempt to make requests to it like /index.php?a Put your services, on a shared domain name, only yourdomain.com and under a sub-path, like yourdomain.com/thisISAlmostLikeaPassword/nextcloud the subpath is hidden by TLS, unless you make it public by posting it on the internet. And also if you arent careful, like using google "auto-suggest" or just using any Google products, then they will at least know about your path.
- mfontani 7y ago
  I'm currently serving some of my "internal" services (a wiki, a coffee tracker; things like that - nothing fancy) only from a zerotier network my devices can connect to. Thanks to letsencrypt "now" (for some time, I know.. but I wanted to do this way before they allowed one to) allowing wildcard TLS certs, I host the above on a domain which doesn't have a single public IP DNS entry, yet has full proper "validated, browser approved" TLS cert. IOW, I fire up my zerotier client on my phone, open brave, put the URL in, and off I go. https, and for my eyes only. It's great!
  - tialaramex 7y ago
    Note that in any configuration where you end up asking remote DNS servers about some particular name the operator might well be selling the list of names queried and their answers, this is called "passive DNS" and is aggregated then sold on so it isn't PII by the time it's sold (purchasers can't tell who asked, only what was asked and what the answer was) Where people set wildcard DNS this means passive DNS reveals typos, as well as such "hidden" services. wwww.example.com and ddd.example.com are common typos for www for example whereas int-test.example.com is maybe interesting to black hats.
- deleted 7y ago
  [deleted]
- cyphar 7y ago
  The problem with a VPN is that it makes it much harder to get friends and family to use it. Not to mention if you use the link sharing feature of NextCloud, you can't just give strangers VPN access. I do use WireGuard for accessing services like SSH or NFS from the public internet, but the usability hit is a deal-breaker for my family. Client-side certificates would help solve this problem somewhat (you could whitelist only sharing-links for instance), but now you've hit usability problems again. I mitigate code execution worries by running all of my services in individual LXD containers. They're all using isolated user namespaces (unique mappings), and are firewalled away from being able to access my internal network. The data is bind-mounted from a ZFS filesystem which is backed up by the host and uploaded to BackBlaze. The containers themselves are also snapshotted by ZFS. Thus, I think the risks of exploits being able to do much damage are greatly reduced. However, there is still a worry about information disclosure. Yeah, NextCloud can only access the documents it manages -- but some of those documents are somewhat sensitive. I don't know what the ideal solution for this would be (a wholly separate NextCloud instance just for accessing the private stuff? But what if your family needs to access them?). My main worry when hosting NextCloud was that I am entirely trusting the safety of my NextCloud-stored data to an authentication flow that they wrote themselves in PHP (and has had pretty ugly flaws such as silently disabling 2FA or letting you bypass it by clicking "cancel".)
  - heavyset_go 7y ago
    > The problem with a VPN is that it makes it much harder to get friends and family to use it. Not to mention if you use the link sharing feature of NextCloud, you can't just give strangers VPN access. This is a feature. Besides, you can send friends and family a QR code to connect to your WireGuard VPN. It isn't perfect, but it beats having your personal data stolen.
    - cyphar 7y ago
      I don't see how "you cannot use the link sharing feature of NextCloud" is a feature? Seems to be the precise opposite. As for setting everyone else up on the VPN, you could probably get that to work (you'd need to mess with DNS, AllowedIPs, and iptables rules to only allow port 443 access for your family's clients). I might look into that.
noja 7y ago
No it's not.
- s_gourichon 7y ago
  "Argument is an intellectual process. Contradiction is just the automatic gainsaying of anything the other person says." http://www.montypython.net/scripts/argument.php http://www.montypython.net/scripts/argument.php https://www.youtube.com/watch?v=ohDB5gbtaEQ&t=74 https://www.youtube.com/watch?v=ohDB5gbtaEQ&t=74
nominated1 7y ago
It’s more evidence that you should assume everything is vulnerable and layer protection. For a home network simple multi-port knocking should be enough (combined with --ctstate NEW even better). If port knocking or SPA is too cumbersome then at least consider limiting access based on GeoIP, block tor exit nodes, etc (ipset is pretty amazing). This can be applied to any service on your network btw, including Wireguard. I like knowing that a portscan of my network shows nothing open. I don’t end up on a list that gets used in the next ‘spray and pray’ attack. Disclaimer: I’m not advocating this for serious use due to replay attacks and IP spoofing via a VPS. This is for home network protection (a boring Class C non target).
- cyphar 7y ago
  How do you port-scan for WireGuard? The handshake design is designed to not respond to packets in the opening handshake unless the peer already knows your public key.
  - nominated1 7y ago
    Right, portscanning won’t work on Wireguard. Port knocking can provide an additional layer of protection against an unknown vulnerability, even for Wireguard. Sorry for the confusion.
UnoriginalGuy 7y ago
Google has gone the opposite direction. I feel like throwing everything behind a VPN and pretending it is secure is a crux. Several famous break-ins over the last ten years have hypothetically been on the inside of that wall. Better to isolate services from each other limiting cross service jumping, than to build security around a single point of failure.
- heavyset_go 7y ago
  Security is in layers, there's no reason you can't rely on both service and network isolation. Service isolation alone doesn't help when my private data is potentially exposed by this exploit.
- oarsinsync 7y ago
  > Better to isolate services from each other limiting cross service jumping, than to build security around a single point of failure I agree that it is better, but let’s not forget that building security around a single point of failure is still an improvement, that is simultaneously both high and low friction. Bad: everything exposed to the internet Good: everything behind a VPN Best: Every application on its own micro-segment with access control up to the application layer to restrict all forms of access beyond the bare minimum of what is required. Perfect is the enemy of good. > Google has gone the opposite direction Google scale solutions are great for google scale organisations. They don’t always scale down very well.
  - samus 7y ago
    > Every application on its own micro-segment with access control up to the application layer to restrict all forms of access beyond the bare minimum of what is required. I hope for the operator team that they have good tool support to help administer all the access controls. Over time and across large organisations there are going to be a lot. The even larger challenge must be auditing all these access controls. Services change, and if a connection is not required anymore, it should be painless for its operators to get rid of the corresponding access control.
dvfjsdhgfv 7y ago
No, it was definitely not true in the past and is not true now. First, technically there is no much difference between a given app self-hosted by you and hosted by a company charging you for that except that in theory they should worry about these things instead of you. In practice, your experience will vary - companies happen to be as vulnerable as you, and for various reasons their reaction time might be longer. Second, bugs are found every day, and your best bet is to use automatic security updates provided by your distro. Yes, if you host anything, you need to be a bit of a security guy and a small amount of paranoia won't hurt. But to say you must not self-host for security reasons is a gross oversimplification.
- heavyset_go 7y ago
  > But to say you must not self-host for security reasons is a gross oversimplification. This is a gross oversimplification and straw man argument. You can self-host securely.

swiley 7y ago

I wish there was a webdav server that wasn't a huge PHP thing and had decent authentication/authorization. Almost everything has SFTP built in anyway now though, it's only a matter of time before OSes other than Linux based ones integrate it into the shells and then webdav won't matter so much.

xienze 7y ago
Do you just want WebDAV and nothing else? There’s plenty of Docker images for that and most of them are just Apache with the relevant plugin and config.
Lorkki 7y ago
Seafile has been working for me as a personal Dropbox replacement, with s3ql for mass storage. It's very light in relation to Nextcloud/Owncloud (a primary criterion for me trying to cheap out on servers), supports WebDAV, role-based access and a bunch of SSO options. The biggest possible drawback I can think of is that it doesn't store files in the plain, so you can't trivially tie in SFTP or serve files from the storage directly.
- WorkLobster 7y ago
  Re: files in the plain, the server application is bundled with a daemon that allows you to access files locally as a read-only FUSE mount, e.g.: seaf-fuse.sh start /mnt/seafile I find it pretty handy when running a web server on the same host: drop files into a folder on my local machine, and they show up in the web root in seconds!

jacquesm 7y ago

Or something that includes NextCloud or Owncloud even if you do not use them, such as Mailinabox.

jeremija 7y ago

Thanks for the link! The example in the link does not contain the set $path_info $fastcgi_path_info; line after the `fastcgi_split_path_info` directive. My old configuration used the `$fastcgi_path_info`, and the new one uses the `$path_info` variable, so I got the following error while starting nginx: nginx emerg unknown "path_info" variable Might be worth checking out the sample from the Nextcloud Admin Manual[1] [1]: https://docs.nextcloud.com/server/17/admin_manual/installation/nginx.html https://docs.nextcloud.com/server/17/admin_manual/installati...