Security issues with ID and Hash about telegram-bot-api HOT 5 OPEN

Environment variables and their value can't be accessed by other non-privileged users, so they are nowhere insecure in a multi-user systems.

Reading parameter values from a config file is an option, but there is no universal config file format which is widely acceptable as the best choice. Choose of a specific format will disappoint supporters of all other formats.

from telegram-bot-api.

I'm definitely no expert, but you'd be the first i've seen to make such a declarative statement about the security of environment variables.  You'd need to add some caveats to be safe, such as regarding /proc filesystem permissions and security of all child processes that inherit the variables.  These will vary between systems too, and fall to users getting the sysadmins to update/patch any misconfigs.  It's typically way less of a headache to just use a config file, which is all within the user's control, than wonder about the inner workings of /proc and inheritance of variables to child processes, getting sysadmins involved, etc.

As far as the format of a config file goes, we're only talking 2 entries here to begin with, since everything else could be specified on the command line.  We can make a new config file format for all I care as long as it's documented and works.  Whoever complains about the format of config files is silly and must have a leisurely life!  Even if every command line option is eventually able to be specified in a config file, it's only what, about 20 entries?

I suppose I could look to other python code that reads from config files to see how it's done, and can get started that way.  However, since my telegram-bot-api is only running on my system, this isn't a priority for me either.  Was more for the community since I figure many out there run such in the cloud or other shared systems, etc.

from telegram-bot-api.

I'm definitely no expert, but you'd be the first i've seen to make such a declarative statement about the security of environment variables.

There are no issues with environment variables, which makes them inherently less secure than config files. For example, you can check https://stackoverflow.com/questions/12461484/is-it-secure-to-store-passwords-as-environment-variables-rather-than-as-plain-t and see that there is no way to misuse environment variables when they are set only for the Bot API server.

/proc filesystem permissions

There are no issues with /proc permissions, otherwise users wouldn't be isolated from each other at all.

security of all child processes that inherit the variables

One should define the environment variables only for the Bot API process. This can be easily done for the specific systemd service, or directly when the process starts with TELEGRAM_API_ID=... TELEGRAM_API_HASH=... telegram-bot-api .... The systemd service can be the config file you want.

These will vary between systems too, and fall to users getting the sysadmins to update/patch any misconfigs.

Environment variables are supported on all systems and sysadmins aren't involved in their change. You don't need to be an administrator to create a processes with specific environment.

many out there run such in the cloud or other shared systems

Most clouds are virtualized and aren't just a multiuser system, so even passing the parameters as process arguments is safe there. Do you have an example of a publicly available cloud, which allows its users to see processes launched by other users?

from telegram-bot-api.

It's not something I have the time to spend much more on, but I'll contribute with the following.  It's not so much about knowing the specific real ways that have happened where such variables are leaked or accessed by others without authorization.  Although a cursory search returns things like CVE-2019-14271 which is just privilege escalation it appears.  Still, even with root access, an encrypted creds file would not immediately be accessible, like with the environment variables of every running process, and would need further work and digging to obtain the decrypted creds and is therefore not the low-hanging fruit that attackers would be first exploiting.  CVE-2018-19571 also showed up as having to do with exposing variables by exploiting merge requests.

Anyway, those are some of the lesser reasons.  The more pertinent reasons, to me at least, is that env vars are available to any other processes within the same user's context.  Really, any malicious code that the user might run in the future could then compromise the telegram API secrets.  So it's these unknowns that are more worrisome than anything known currently or that has been documented.  This is maybe why, in general, this practice is frowned upon.  Plus, I think as an official code product of Telegram, along with your own ToS which prohibit users from sharing their API secrets, it would be prudent to adopt the use of a config file and deprecate the command line options and environment variable support.  Also, I don't think adding this functionality presents much of a burden on the team; many others have already written code to read from config files and such could literally be copied from some other project with minimal effort, yes?

Adieu

from telegram-bot-api.

An intruder with root access can just extract credentials from memory of the running process. This isn't harder in any way for an attacker managed to escalate privileges.

env vars are available to any other processes within the same user's context

Yes, and any config file accessible to the Bot API server on start will also be available to any other process. Non-encrypted config files are in no way more secure than environment variables. Initially you stated "this obviously isn't meant to be run on a multi-user system", which makes sense, but protecting user from self is impossible and is irrelevant from a security standpoint.

prohibit users from sharing their API secrets

Sharing of API secrets is publishing them in clear text or explicitly sharing with other parties. It is clearly possible to extract them from any built Telegram app and this have nothing to do with security.

https://systemd.io/CREDENTIALS/ states

Traditionally, data of this nature has often been provided to services via environment variables (which is problematic because by default they are inherited down the process tree, have size limitations, and issues with binary data) or simple, unencrypted files on disk.

You can clearly see that none of the mentioned environment variable issues is relevant for the Bot API server, and therefore environment variables are no different from unencrypted config files in terms of security. You can also write a very simple script which will run Telegram Bot API server using credentials provided by systemd and passes them to the Bot API server via environment variables without any security compromises.

from telegram-bot-api.