4 ms·

Does that mean it's now reliable when putting it in a public-facing place? An orga that shall not be named used nextcloud for various important things and had i

by Aachen 6y ago

Does that mean it's now reliable when putting it in a public-facing place? An orga that shall not be named used nextcloud for various important things and had it connected to the Internet, which for modern open source software is usually okay. But then a friend found that you can take the whole system down from a 56k modem (pre-auth) and it had to be recommended the Orga keep it internal, which was an issue because they iirc also used it for file sharing with externals. As far as I know it's very rare that someone bothers with exploiting denial of service bugs, but given how trivial (triggerable by hand) this was, it's still a bit risky. The bug was of course reported to them but closed as wontfix dontcare because there were too many other ways of taking it down already. Php was blamed iirc (which really isn't the culprit).

40four 6y ago
I'm really not sure why you are asking this question? Nextcloud is used by thousands of enterprise level & small private users on public facing servers. Can you be more clear about what you mean by "a friend found that you can take that whole system down from a 56k modem"? I have no idea what you mean by that. You mention denial of service. Are you claiming a Nextcloud instance can be DoS'ed by a single computer with a 56k internet connection? Respectfully, that is quite a sensational claim/ stance to take.
- Aachen 6y ago
  Yeah I'm being a bit more vague than I'd like, I should have taken the effort of going to my pc (am on phone) where I have a password manager to login to the account under my real name. I don't want to connect this one too much. Without posting the specific exploit, the issue is with the server-side sleep() in the login system. If you spawn enough threads, which you could easily do in the given time from even a 56k modem, it will for some reason crash the whole thing. Tested with a couple friends and all the instances had to be restarted manually, none of them (running on different web servers) withstood it. It's not clear why as the sleep should simply run through and then unblock the threads; for some reason that's not what happens. Again, this was reported and they don't care. If you want more info, this should be enough to reproduce it without much effort and/or ask them about it (not sure if they made the ticket public, initial report probably was presumably private due to the pre-auth/unconditional nature).
  - 40four 6y ago
    Fair enough, no need to give any up any identifying information :) That doesn't sound good. I guess as a personal user I'm not too worried about being DoSed, but that would certainly be more of a concern for a large organization evaluating the software. If that is the case, then I certainly have an 'eyebrow raised'.

by Aachen 6y ago

40four 6y ago

I'm really not sure why you are asking this question? Nextcloud is used by thousands of enterprise level & small private users on public facing servers. Can you be more clear about what you mean by "a friend found that you can take that whole system down from a 56k modem"? I have no idea what you mean by that. You mention denial of service. Are you claiming a Nextcloud instance can be DoS'ed by a single computer with a 56k internet connection? Respectfully, that is quite a sensational claim/ stance to take.

Aachen 6y ago
Yeah I'm being a bit more vague than I'd like, I should have taken the effort of going to my pc (am on phone) where I have a password manager to login to the account under my real name. I don't want to connect this one too much. Without posting the specific exploit, the issue is with the server-side sleep() in the login system. If you spawn enough threads, which you could easily do in the given time from even a 56k modem, it will for some reason crash the whole thing. Tested with a couple friends and all the instances had to be restarted manually, none of them (running on different web servers) withstood it. It's not clear why as the sleep should simply run through and then unblock the threads; for some reason that's not what happens. Again, this was reported and they don't care. If you want more info, this should be enough to reproduce it without much effort and/or ask them about it (not sure if they made the ticket public, initial report probably was presumably private due to the pre-auth/unconditional nature).
- 40four 6y ago
  Fair enough, no need to give any up any identifying information :) That doesn't sound good. I guess as a personal user I'm not too worried about being DoSed, but that would certainly be more of a concern for a large organization evaluating the software. If that is the case, then I certainly have an 'eyebrow raised'.