[ISSUE] /upload lets you pick (and delete!) arbitrary files from the host

[LucentW]

Describe the issue
As per title

what did you try ?
Steps to reproduce the behavior:

1. /upload /etc/passwd

Expected behavior
Bot shouldn't pick files coming from outside the setup download directory.

Beware, you can even do /upload tobrot to remotely break someone's instance, it'll recurse into the entire tree, upload all files and delete everything

[SpEcHiDe]

the bot should only be used in small groups, by trusted users, also, /upload requires administrator priveleges in the group, so I don't think this is an issue 😬🤔

[davtur19]

If you don't understand its importance, then you should stop programming
Close the repo or go back to all your projects and fix them ASAP, there can't be such stupid flaws in 2020

[SpEcHiDe]

i understand, but the command is triggered by a "human" and not a bot.
i require uploading some files (say in /var/log/), and hence had added this command. You are free to "fix" this in your repositories by forking, but atleast, in my opinion, #130 is not the correct solution.

also, please read this: https://t.me/c/1378533090/16624 before judging the intentions of this repository.

[davtur19]

No matter who executes the command, it is too dangerous, a program should be made with safety first of all.
For example, abusing inline bots you could make the admin do a command like this:
The admin runs an inline bot, sends the message with the /upload command (when you use an inline bot you don't know what you're going to write) and immediately the inline bot modifies it, so you don't notice what happened.
The problem is that with a stupid command you compromise the whole container and by the time you realize it it's already too late.

I don't care what you are doing with your repo, I care that you are spreading software with one (or more) backdoors to unaware users.

(Even if you didn't do it on purpose, it's technically a backdoor)

[SpEcHiDe]

Is it fine?

[LucentW]

You just removed an empty comment line and tabbed it to have it disabled by default 😅
It doesn't really stop people from ul-ing and deleting random files off the host if dangerous commands are enabled, plus, since your Dockerfile runs the bot as root into the container, doing /upload / is the same as doing rm -rf /, but it'll leak all files in the process, potentially tokens and passwords too

Probably an idea is to add some sort of "whitelisted paths" into the configuration, if you need to fetch logs off /var/log, but sure leaving that as it is, lets authorized users break the container and render it unusable in a couple commands or just plain steal info off the filesystem

[SpEcHiDe]

/exec and /eval also does the same thing, but a little more dangerous than /upload.

I am not sure how would the "fix" be..