Security issue

[thegcat]

I have found a security issue, is there a way to disclose this so that a mitigation can directly be offered, or should I just make a Pull Request?

[ZPascal]

Hi @thegcat, can you please describe the security issue here? I will prepare a fix for it. Is it a theoretical security issue, or can it be actively exploited?

[thegcat]

The ports definitions in the cache and database services make those ports/services available global address of the host machine. In the case of the database this might be mitigated if the password was changed, in the case of the cache it makes the cache world-readable and world-writable. As the sessions are stored in the cache this allows an attacker to take over any session on the pretix this runs.

The ports definitions should be completely removed. For internal communication (the pretix service needs access to the database and cache services) there is no need for ports definitions.

[ZPascal]

Hi @thegcat, I understand your points.

The repository includes a Pretix docker-compose configuration for local development.

Are you aware that the Docker-Compose setup is only supported for a local development/ testing setup? For the development/ test setup, it is a valid case to obtain access to the database instances.

[thegcat]

I do, and I'm not sure everyone does. Also going to the trouble of getting an SSL cert and a cron system set up seems like a lot for local development.

I agree that access to the databases might be warranted for development purposes, but even for testing I would limit it to the local testing machine, i.e. limit the open ports to the host's localhost instead of open on the host's world interface.

All in all even for a development setup this seems like too big of a footgun to me, and I don't think I'd be comfortable leaving it in this state just with a "for development only" disclaimer, as a) I wouldn't be sure no-one would use it in production, b) anyone using it for development understood that the databases are world-accessible. If those are points you are fine with we can indeed stop the discussion here and close this issue :-)

[ZPascal]

I agree that access to the databases might be warranted for development purposes, but even for testing I would limit it to the local testing machine, i.e. limit the open ports to the host's localhost instead of open on the host's world interface.

Yes, I've already adapted the used interface and merged the corresponding PR.

[ZPascal]

Also going to the trouble of getting an SSL cert and a cron system set up seems like a lot for local development.

@thegcat I've created the corresponding certificates a few minutes ago to test the changes. If you need support, feel free to open an issue.

[thegcat]

Thank you for taking care of this.