[Solved] Renaming Binary/Executable While Running

sefacs89 · 2019-10-10 06:52:34

Hello everyone at the forums

today i "discover" something new and i didnt like it

i do the following

i fire up the /usr/bin/glxgears &

at the same time i execute the command sudo mv /usr/bin/glxgears /usr/bin/glxgears.back

the process continue to run and the glxgears reports the output

is there any way to prevent it to happenning

i mean the renaming of an executable/binary while this one is running ?

thank you very much

Last edited by sefacs89 (2019-10-10 18:39:48)

seth · 2019-10-10 07:14:52

You mean you want "sudo mv /usr/bin/glxgears /usr/bin/glxgears.back" to fail because there's a process that was somewhen launched reading /usr/bin/glxgears?
No. And why would you want this to begin with? (sounds like an x-y problem)

What you can certainly do is to check the process list on whether any cmdline starts with "/usr/bin/glxgears" and then simply not act, but again: why would you want this to begin with?

charlie · 2019-10-10 07:42:21

I guess you could have some sort of ghost process where a malware creates a program, launches it and deletes the file so as to make it impossible to trace back on the disk. Not sure how much this is an issue though.

In the meantime, I don't see the advantage of being able to do this. Creating many temporary programs/scripts to launch and delete them as soon as possible to save memory?

Last edited by charlie (2019-10-10 07:50:14)

sefacs89 · 2019-10-10 07:59:05

seth wrote:

You mean you want "sudo mv /usr/bin/glxgears /usr/bin/glxgears.back" to fail because there's a process that was somewhen launched reading /usr/bin/glxgears?
No. And why would you want this to begin with? (sounds like an x-y problem)
What you can certainly do is to check the process list on whether any cmdline starts with "/usr/bin/glxgears" and then simply not act, but again: why would you want this to begin with?

i do the moves on the fly

issuing the glxgears to run and while running i do succesfully the renaming

which in Windows OS i cant do the same

as i figured out its copy the binary/executable in memory and de-attach itself from the executable logical hdd path

just a security concern

charlie wrote:

I guess you could have some sort of ghost process where a malware creates a program, launches it and deletes the file so as to make it impossible to trace back on the disk. Not sure how much this is an issue though.
In the meantime, I don't see the advantage of being able to do this. Creating many temporary programs/scripts to launch and delete them as soon as possible to save memory?

i have clamav running with only the official repo antivirus database definitions

Last edited by sefacs89 (2019-10-10 08:00:06)

seth · 2019-10-10 08:06:15

That doesn't work (trivially) because of copies in /proc/$PID/{exe,fd/*} and certainly not for moved files.
It is, in a way, using scripts (but not for the interpreter) - essentially by reading the script from stdin.

@sefacs89
This is not a security feature in windows, but a major architectural flaw and a general PITA. You can explicitly flock files on POSIX systems, but that's usually a sign of bad software design.

sefacs89 · 2019-10-10 13:37:25

seth wrote:

That doesn't work (trivially) because of copies in /proc/$PID/{exe,fd/*} and certainly not for moved files.
It is, in a way, using scripts (but not for the interpreter) - essentially by reading the script from stdin.
@sefacs89
This is not a security feature in windows, but a major architectural flaw and a general PITA. You can explicitly flock files on POSIX systems, but that's usually a sign of bad software design.

so this is a normal behavior of linux architecture in order to determine for example after a restart if something has been touched ?

thanks

seth · 2019-10-10 13:40:25

I'm sorry but you'll have to rephrase that question - it is unclear to me what you meant to ask.

Trilby · 2019-10-10 14:31:48

Note that /proc/${PID}/exe is not a "copy" of the binary, but rather a symlink to the original binary.

The content of the binary, however, is loaded into memory to run. From that point on, what's on disk is irrelevant. In fact, whether or not there is even a disk is irrelevant.

seth · 2019-10-10 14:39:55

Note that /proc/${PID}/exe is not a "copy" of the binary, but rather a symlink to the original binary.

Yesno.
"symlink" is imo in my great and unmatched wisdom just as misleading because of procfs (you can delete the file, the "symlink" would technically become stale, but you can still perfectly access the deleted file in procfs) - it behaves more like a hardlink/copy.

Trilby · 2019-10-10 16:01:09

Huh ... yup. I just confirmed the above seems to be true. Yet `stat` seem to "lie" saying that /proc/*/exe are symlinks.

sefacs89 · 2019-10-10 16:12:15

Trilby wrote:

Note that /proc/${PID}/exe is not a "copy" of the binary, but rather a symlink to the original binary.
The content of the binary, however, is loaded into memory to run. From that point on, what's on disk is irrelevant. In fact, whether or not there is even a disk is irrelevant.

yea that is my understanding

this behaviour is a little risky

is there any way to fix it ?

or it will shown up upon a reboot or trying to execute the executable/binary file?

thanks

Trilby · 2019-10-10 16:35:07

sefacs89 wrote:

this behaviour is a little risky

Which behavior do you think is risky? And why on earth do you think it's risky? What's the risk you are concerned about?

sefacs89 wrote:

is there any way to fix it ?

Fix what?

You can turn your computer off and leave it off. That'd certainly do it. For anyting else, you're going to have to be a lot more specific.

sefacs89 wrote:

or it will shown up upon a reboot or trying to execute the executable/binary file?

What?? Nothing is presevered in memory through a reboot. And each time an on-disk program is launched, the content of that on-disk binary is used (loaded to memory, and - apparently - hardlinked into /proc).

sefacs89 · 2019-10-10 16:43:11

Trilby wrote:

sefacs89 wrote:
this behaviour is a little risky
Which behavior do you think is risky? And why on earth do you think it's risky? What's the risk you are concerned about?
sefacs89 wrote:
is there any way to fix it ?
Fix what?
You can turn your computer off and leave it off. That'd certainly do it. For anyting else, you're going to have to be a lot more specific.
sefacs89 wrote:
or it will shown up upon a reboot or trying to execute the executable/binary file?
What?? Nothing is presevered in memory through a reboot. And each time an on-disk program is launched, the content of that on-disk binary is used (loaded to memory, and - apparently - hardlinked into /proc).

Scenario:

you leave your computer without a password for just a seconds
and you are running a custom exetable/binary file made for a work named :A
and someone else just doing a rename of an executable/binary under /usr/bin/ by issuing the command sudo mv /usr/bin/A /usr/bin/A.back here we use

for some reason the program freezes and you need to restart it
you fire up the console and just type A and you get an error
(assuming enviroment variables has not been touched)

that is the issue i am worry about of course with a password everything change

just a scenario

thanks

Trilby · 2019-10-10 17:38:11

Ok, but absolutely nothing in that scenario has anything to do with symlinks, proc filesystem, or any other topic in this thread.

If you leave your computer unlocked and unattended, someone could rename the program you had been working on whether or not it was running at that moment and when you returned "A" would no longer run.

So the security issue has nothing to do with "while running" it's just an issue with someone getting access to your computer to rename things.

sefacs89 · 2019-10-10 17:54:36

Trilby wrote:

Ok, but absolutely nothing in that scenario has anything to do with symlinks, proc filesystem, or any other topic in this thread.
If you leave your computer unlocked and unattended, someone could rename the program you had been working on whether or not it was running at that moment and when you returned "A" would no longer run.
So the security issue has nothing to do with "while running" it's just an issue with someone getting access to your computer to rename things.

thanks for your clarification indeed "while running i do the rename and then boom " that was the logic of the thread

as a pre-caution and warning to the forums

of course password protect is a matter of fact a +

but i was wondering after all if there is any command or setting to prevent the renaming of executables in the /usr/bin folder or specifically in /bin folder

thanks

Trilby · 2019-10-10 18:14:07

sefacs89 wrote:

any command or setting to prevent the renaming of executables in the /usr/bin folder or specifically in /bin folder

They already cannot be renamed except by root. If you are leaving your computer unlocked and unattended that is not good but would not allow this renaming. If you are already leaving your computer unlocked, unattended, and with an active available root shell session then that is disasterous, and renaming something under /usr/bin is really the least of your concerns.

Last edited by Trilby (2019-10-10 18:14:29)

sefacs89 · 2019-10-10 18:39:26

Trilby wrote:

sefacs89 wrote:
any command or setting to prevent the renaming of executables in the /usr/bin folder or specifically in /bin folder
They already cannot be renamed except by root. If you are leaving your computer unlocked and unattended that is not good but would not allow this renaming. If you are already leaving your computer unlocked, unattended, and with an active available root shell session then that is disasterous, and renaming something under /usr/bin is really the least of your concerns.

Thanks i have already password on my computer

problem/question solved

Arch Linux

#1 2019-10-10 06:52:34

[Solved] Renaming Binary/Executable While Running

#2 2019-10-10 07:14:52

Re: [Solved] Renaming Binary/Executable While Running

#3 2019-10-10 07:42:21

Re: [Solved] Renaming Binary/Executable While Running

#4 2019-10-10 07:59:05

Re: [Solved] Renaming Binary/Executable While Running

#5 2019-10-10 08:06:15

Re: [Solved] Renaming Binary/Executable While Running

#6 2019-10-10 13:37:25

Re: [Solved] Renaming Binary/Executable While Running

#7 2019-10-10 13:40:25

Re: [Solved] Renaming Binary/Executable While Running

#8 2019-10-10 14:31:48

Re: [Solved] Renaming Binary/Executable While Running

#9 2019-10-10 14:39:55

Re: [Solved] Renaming Binary/Executable While Running

#10 2019-10-10 16:01:09

Re: [Solved] Renaming Binary/Executable While Running

#11 2019-10-10 16:12:15

Re: [Solved] Renaming Binary/Executable While Running

#12 2019-10-10 16:35:07

Re: [Solved] Renaming Binary/Executable While Running

#13 2019-10-10 16:43:11

Re: [Solved] Renaming Binary/Executable While Running

#14 2019-10-10 17:38:11

Re: [Solved] Renaming Binary/Executable While Running

#15 2019-10-10 17:54:36

Re: [Solved] Renaming Binary/Executable While Running

#16 2019-10-10 18:14:07

Re: [Solved] Renaming Binary/Executable While Running

#17 2019-10-10 18:39:26

Re: [Solved] Renaming Binary/Executable While Running

Board footer