Cloudron Forum

Thanks @girish Us, the people that install softwares through Cloudron (Cloudron catalog + Community apps) worry only about 2 things: That each app is updated regularly Stability & Performance Who packages and maintains it, doesn't matter much. If a community maintainer does a good job, great. We would gladly donate to support his/her work. 3 scenarios exist: If the Cloudron team planned on adding couple Apps in the Catalog (which a community maintainer was faster to release on the Community list), and now the App isn't added on the list because somebody was faster. Yes, some maintainers do a great job. But not all are up to the gold standard that the Cloudron team has. Most of those people have regular jobs, so they can't dedicate the additional time. If a Community maintainer, stops maintaining an App. And if the Cloudron team picks to add the same App on the Catalog. All those hundreds/thousands of people that initially used the Community version, would need an streamlined switch to the Cloudron version. Ideally without a full migration. This is where it would be very useful if some day in the future the Cloudron team could create an option in the Community App dashboard, to just click to change the .json URL - so that the App continues to get the next updates from the Cloudron source. A Community maintainer want's to help the community and the Cloudron team by first maintaining an App himself, but with the purpose in the future to delegate the same App to the Cloudron team, so that he can redirect his focus on preparing new Apps.

Hello @umnz For context please read https://forum.cloudron.io/topic/14969/enabling-grist-enterprise-does-not-work and https://forum.cloudron.io/topic/14941/grist-is-now-available

@mononym it's actuall really easy to install this using the LAMP app, just follow these simple steps from @gengar : https://forum.cloudron.io/post/115931 You literally copy paste each of the 6 blocks of code one by one and then it's done.

@ekevu123 great report. Fixed in https://git.cloudron.io/platform/box/-/commit/c7b2e4d95e3ca00924d3ad11781303b479d787d8

This is fixed now. An error message saying File too large is displayed.

It's perfect. Thank you, @james !

@dark thanks for your report. I looked into them. For transparency, here is our assessment. All the reported issues require the attacker to already have an admin token / compromised admin password. All the issues below are not reproducible as a (compromised) normal user. Also. the issues were reproduced on the demo instance, which of course has the admin username/password displayed in public. We found the report to be thorough and with clear explanation on how to reproduce the problems. From our side, we ack the bugs and have made the following fixes: Problem: Full SSRF via applinks. This is about adding an internal IPs as an applink. Our analysis: Linking to internal apps is a legitimate feature. An applink is fundamentally a bookmark and there's nothing wrong with pointing it at 192.168.1.50 or an internal app. Applinks REST response only returns label and icon not contents of a site. You can't really infiltrate EC2 metadata etc and neither can you make non GET requests. Our fix: We have added a fix now to block server internal IPs like localhost and docker internal network. Problem: SQL injection via dynamic column names. This is about being able to send arbitrary field names in the REST APIs. Our analysis: Indeed, our query builders, should only use field names which are in the db and are part of an allow list. Our fix: We have added allow list to all our model code Problem: 2FA/TOTP BYPASS via skipTotpCheck: true Our analysis: I think this is because the demo instance does not allow you to set a TOTP. It doesn't show an error currently when this happens and leads the user to believe an OTP was set. For the demo server, we can't allow users to set a TOTP because it will make it unsuable for others. Our fix: We will show an error like we show in other places. But also, the password login routes have already been removed in Cloudron 10 (which is yet to be released). That route exists as a backward compat for the CLI. Cloudron only supports OIDC device auth for the CLI from Cloudron 10. Problem: Stored XSS via branding footer Our analysis: right. This issue has been present since ages and our demo instance always has someone putting some alert() or some stupid HTML in there periodically... Our fix: We give in to the non-stop reports about this... We use dompurify now. Thanks for the report again. Very clear and solid notes. I also took the chance to update https://www.cloudron.io/security.html and https://www.cloudron.io/.well-known/security.txt

Fixed in the latest package.

Vendor: System manufacturer Product: System Product Name Linux: 5.15.0-179-generic Ubuntu: jammy 22.04 Cloudron: 9.2.0 Execution environment: none none Processor: Intel(R) Xeon(R) CPU E3-1225 v6 @ 3.30GHz x 4 RAM: 32807988KB Disk: /dev/nvme0n1p2 697G [OK] Root disk usage is OK (22%) [OK] Memory usage is OK (46%) [OK] Clock is NTP-synchronized [OK] node version is correct [OK] IPv6 is enabled in kernel. Public IPv6 address detected [OK] docker is running [OK] docker version is correct [OK] MySQL is running [OK] netplan is good [OK] DNS is resolving via systemd-resolved [OK] unbound is running [OK] IPv4 HTTPS to api.cloudron.io/api/v1/helper/public_ip [OK] IPv6 HTTPS to api.cloudron.io/api/v1/helper/public_ip [OK] IPv4 HTTPS to auth.docker.io/token [OK] IPv6 HTTPS to auth.docker.io/token [OK] IPv4 HTTPS to acme-v02.api.letsencrypt.org [OK] IPv6 HTTPS to acme-v02.api.letsencrypt.org [OK] nginx is running [OK] dashboard cert is valid [OK] dashboard is reachable via loopback [OK] No pending database migrations [OK] Service 'mysql' is running and healthy [OK] Service 'postgresql' is running and healthy [OK] Service 'mongodb' is running and healthy [OK] Service 'mail' is running and healthy [OK] Service 'graphite' is running and healthy [OK] Service 'sftp' is running and healthy [OK] box v9.2.0 is running [OK] Dashboard is reachable via IPv4 (https://my.rotovegas.nz) [OK] Dashboard is reachable via IPv6 (https://my.rotovegas.nz) [SKIP] Domain expiry check — whois did not return an expiry date for rotovegas.nz ======== Summary ======== PASS: 30 WARN: 0 FAIL: 0 SKIP: 1 Working version : Invoice Ninja 5.13.22