It’s you can modify the settings file you sure as hell can put the malware anywhere you want
True. (But in case it amuses you or others reading along:) But a code settings file still carries it’s own special risk, as an executable file, in a predictable place, that gets run regularly.
An executable settings file is particularly nice for the attacker, as it’s a great place to ensure that any injected code gets executed without much effort.
In particular, if an attacker can force a reboot, they know the settings file will get read reasonably early during the start-up process.
So a settings file that’s written in code can be useful for an attacker who can write to the disk (like through a poorly secured upload prompt), but doesn’t have full shell access yet.
They will typically upload a reverse shell, and use a line added to settings to ensure the reverse shell gets executed and starts listening for connections.
Edit (because it may also amuse anyone reading along): The same attack can be accomplished with a JSON or YAML settings file, but it relies on the JSON or YAML interpreter having a known critical security flaw. Thankfully most of them don’t usually have one, most of the time, if they’re kept up to date.
Given the warning about capitalization, the best possible case is that they’re using ast.literal_eval() rather than throwing untrusted input into eval().
Err, I guess they might be comparing strings to ‘True’ and are choosing to be really strict about capitalization for some reason.
In this instance, I think there was some suggestion to write code in mostly lower case, including all user variables, or at least inCamelCaseLikeThis with a leading lower case letter, and so to make True and False stand out, they’ve got to be capitalised.
I mean. They could have been TRUE and FALSE. Would that have been preferable? Or how about a slightly more Pythonic style: __true__ and __false__
i would go with lowercase and just have it be a reserved word like the other ones. but I’m not super picky, i generally like to stick to what people are used to, and i can understand the reasoning behind the choice.
Is the backend Python and the frontend JavaScript? Because then that would happen and just be normal, because Boolean true is
Truein python.Probably, but if you’re interpreting user inputs as raw code, you’ve got much much worse problems going on, lol.
[...]®ister=import os; os.system("sudo rm -rf /"); return TrueHey, that’s my username too. Or it was going to be, while the site was still up.
What a coincidence!
I guess I’ll wait for the site to come back, and see if it’s still available…
It’s the settiings file… It’s probably supposed to only be written by the system admin.
A good place to put persistent malware. That’s why when using docker images always mount as ro if at all possible.
It’s you can modify the settings file you sure as hell can put the malware anywhere you want
True. (But in case it amuses you or others reading along:) But a code settings file still carries it’s own special risk, as an executable file, in a predictable place, that gets run regularly.
An executable settings file is particularly nice for the attacker, as it’s a great place to ensure that any injected code gets executed without much effort.
In particular, if an attacker can force a reboot, they know the settings file will get read reasonably early during the start-up process.
So a settings file that’s written in code can be useful for an attacker who can write to the disk (like through a poorly secured upload prompt), but doesn’t have full shell access yet.
They will typically upload a reverse shell, and use a line added to settings to ensure the reverse shell gets executed and starts listening for connections.
Edit (because it may also amuse anyone reading along): The same attack can be accomplished with a JSON or YAML settings file, but it relies on the JSON or YAML interpreter having a known critical security flaw. Thankfully most of them don’t usually have one, most of the time, if they’re kept up to date.
Every environment has plenty of good places to put persistent malware. Even if you run your docker images as ro.
Given the warning about capitalization, the best possible case is that they’re using ast.literal_eval() rather than throwing untrusted input into
eval().Err, I guess they might be comparing strings to ‘True’ and are choosing to be really strict about capitalization for some reason.
Yeah. Maybe .to_lower() is really expensive in their environment, lol.
It’s not User input, it’s config file
I curse the sadist who decided True should be uppercase in Python
guido, why did you make python so weird?
In this instance, I think there was some suggestion to write code in mostly lower case, including all user variables, or at least inCamelCaseLikeThis with a leading lower case letter, and so to make True and False stand out, they’ve got to be capitalised.
I mean. They could have been TRUE and FALSE. Would that have been preferable? Or how about a slightly more Pythonic style: __true__ and __false__
i would go with lowercase and just have it be a reserved word like the other ones. but I’m not super picky, i generally like to stick to what people are used to, and i can understand the reasoning behind the choice.
Searching for the phrase, documentation matches for Taiga so maybe you’re right!
deleted by creator