[SECURITY] Major security flaw due to hardcoded JWT secret!

[1RandomDev]

• App version: 2.3.1

---

Bug description:
I noticed that the secret for generating JWTs when logging in is hardcoded in the .env file. This key is publicly known and the same for every instance and therefor entirely bypasses password authentication. You can use every token generated by every flame instance to log into every other instance!

Solution:
This issue can be easily solved by setting the SECRET environment variable to a long random string, but unfortunately this is mentioned nowhere in the README. Additionally there should NEVER be a default secret key, it should be required to be set by the user or be randomly generated on each start if not set. In this case even if the user fails to configure it properly a new key will be generated on each start invalidating existing sessions.

Proof:
You can easily try this out by logging out of your dashboard, open the local storage editor in your browsers dev tools and add the following entry:
Key: token
Value: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhcHAiOiJmbGFtZSIsImlhdCI6MTcyNDc3MDUyNiwiZXhwIjoxNzU2MzI4MTI2fQ.lQ-qxon9MrSrU_-6sdIApO8fURVRq0kUpwLUIkqAnFE
This should log you in to every flame dashboard that's out there regardless of the set password.

[simono41]

I tried the security vulnerability in my own instance and can only confirm it.

This issue should definitely be fixed, but I believe that this project is no longer maintained.

I will turn off public access to my flame environment until the problem is solved.

[sylflo]

If anyone is interested I made a simple fix here https://github.com/sylflo/flame/pull/2/files

Also I added a bunch of stuff in the .dockerignore here https://github.com/sylflo/flame/pull/1/files

There is a docker image publicly available at docker.io/sylflo/flame

[1RandomDev]

That's a good hot fix for now, for the long run it would probably be the most user friendly solution, especially since the app already needs a persistent volume anyway, to generate a random key at the first start and save it in the config.json or another secrets file.

[spiicytuna]

@1RandomDev - Does this suffice as a user friendly way to solve the issue for those who aren't into hot fixes?

spiicytuna@b351950

[1RandomDev]

So you're generating a secret if none is set and saving it to a persistent file, that's how this usually should be handled.

[spiicytuna]

Yes that's how it's normally done... just wanted that said out loud (a) to make sure I wasn't missing anything and (b) to have it in the thread since many people were rightfully very worried. I applied this change to images I created on my fork if anyone wants to use a more secure flame w/o having to take additional steps to secure.

[1RandomDev]

In general I would advise against exposing a service like that to an untrusted network anyway, especially if the docker socket is passed to the inside of the container which can potentially be used to gain access to the host system. However I still think it's dangerous having an option for "protecting" a service that does nothing at all in terms of security.