I think modifying ~/.bashrc and other alike files should require the password of the user or root privilege.

seekstar

New Member
Credits
74
Otherwise, the scipts could be easily modified by malicious software, such as this one:

Bash:
#!/bin/bash
echo -e 'echo -n "[sudo] password for $(whoami): "\nread -s pw\necho I got your password: $pw' > /tmp/hack.sh
echo 'alias sudo="bash /tmp/hack.sh"' >> ~/.bashrc
If the user executes the malicious software, then opens another bash shell and executes sudo, then enters the password, the password could be stolen:

Code:
$ sudo -s
[sudo] password for searchstar: I got your password: mypassword
By requiring the password of the user or root privilege to modify ~/.bashrc and other alike files, the new shell could be trusted even after executing malicious software.

Additionally, as long as ".bashrc" is placed under ~, the malicious process could remove the file and replace it with a malicious one. So to make the shell trustable, maybe ".bashrc" should be moved to someplace like "/etc/bashrc.d/xxx.bashrc".

To further prevent that the executed software enters a fake shell and the user enters password in it without knowing that it is a fake shell, I think there should be a status bar displaying the path and pid of the current foreground process.

I don't think it's hard to implement. Then why most Linux distributions and even MacOS ignore this security issue? Is that for convenience? I'm looking forward to some discussion here. By the way, I'm not a native English speaker, so any correction of my expression will be appreciated.

Update: After some discussion, I guess the reason is indeed for convenience. Nevertheless, I will try to implement the ideas above in the (maybe far) future if I get some time, and open source it. At that time, if you want to run my script, please check the code first in case that I'm a bad guy;)
 
Last edited:


dcbrown73

Well-Known Member
Credits
3,042
Using chattr is an option for the paranoid! ;)

chattr can make a file immutable even to the root user.
Code:
chattr +i ~/.bash_profile
If you need to edit your .bash_profile, then temporarily remove the mutability attribute with...
Code:
chattr -i ~/.bash_profile
You can verify the status of the mutable status of the file with lsattr.
Code:
lsattr ~/.bash_profile
 

dcbrown73

Well-Known Member
Credits
3,042
There is always the issue of someone getting compromised and then using the hack he suggested to embed ... really anything on your system. If you are only compromising a non-root user. Using the profile to auto-execute is a valid option though not a very stealthy one. There are better more stealthy ways to do it.

If you compromise the root user, the last place you want to leave fingerprints is anywhere near the root user account information. That would (should) tip off a system admin.
 

Tolkem

Well-Known Member
Credits
8,523
If the user executes the malicious software
That's why you should check whatever foreign software you're attempting to install first, otherwise, you might as well just use Windows, and start downloading and running random .exe files from everywhere.
 

KGIII

Super Moderator
Staff member
Gold Supporter
Credits
29,034
There is always the issue of someone getting compromised and then using the hack he suggested to embed
That's just it, in order for this to do anything they'd already need to be compromised.

I suppose they could still do this, I'm just not seeing why they'd want to - or what adding a password will do to help. I could *easily* be missing something.
 

JasKinasis

Well-Known Member
Credits
7,825
The OP seems to be talking about the user downloading and running a malicious script. So the script would be running as the user and would have the same permissions as the user. So this type of attack could succeed. And if the user ran the script as root, or via sudo - then it could wreak even more havoc with a users system.

But if you're dumb enough to just blindly run any old crap downloaded from the internet, you can probably expect to be pwned - doesn't matter what OS you run!

I personally do not think that you should have to enter a password to edit your own personal config files. If you're going to go down that route, you'd have to have the user enter their password to edit ANY of their files - but how much of a ballache would that be?

People switching to Linux from Windows already complain enough about having to keep entering their password in the terminal as it is!

.bashrc contains per-user settings. It doesn't affect the whole system. And if the user running the malicious script is in the sudoers file, then more fool them!

If you wanted to be super paranoid about your .bashrc - store a copy of your .bashrc in a hidden, encrypted partition and then run a cron job to periodically do a SHA256 checksum of the .bashrc in your home directory and check it against a SHA256 checksum of the version backed up in your encrypted partition. And have it pop up a huge, flashing warning dialog and play a siren sound when/if it notices a discrepancy.... Seems a bit overkill to me though. Ha ha!

Alternatively, just be careful what you download and run on your systems. It's really not rocket science!

The weak link in the scenario that the OP has described is not the operating system, or the file-permissions - it's the idiot sat in the chair!
 

wizardfromoz

Administrator
Staff member
Gold Supporter
Credits
18,470
Hang on to your hats folks, we'll take a Magic Carpet Ride to Security (talked with the OP yesterday while his Thread was under Approval).

Cheers all, and welcome @seekstar to linux.org :)

Chris Turner
wizardfromoz
 

seekstar

New Member
Credits
74
If you are only compromising a non-root user. Using the profile to auto-execute is a valid option though not a very stealthy one. There are better more stealthy ways to do it.
I am curious about the more stealthy ways.

If you compromise the root user, the last place you want to leave fingerprints is anywhere near the root user account information. That would (should) tip off a system admin.
I don't know what the meaning of "the root user" is here. If you mean the root user with uid 0, then if that user is compromised, the whole system is not trustable and should be reinstalled, there is no way to rescue. I only want to protect the passwords of admin users, and make sure that the shell is still trustable even after the user itself is compromised.
 

seekstar

New Member
Credits
74
That's why you should check whatever foreign software you're attempting to install first, otherwise, you might as well just use Windows, and start downloading and running random .exe files from everywhere.
Everyone makes mistakes. I just want a trustable shell even after a mistake.
 

seekstar

New Member
Credits
74
I personally do not think that you should have to enter a password to edit your own personal config files. If you're going to go down that route, you'd have to have the user enter their password to edit ANY of their files - but how much of a ballache would that be?
~/.bashrc is a special file, whose reliability determines the reliability of the user shell. With a trustable shell, the user could try to rescue himself by killing the malicious process, cleaning up the malicious software, and so on, without the help of root. For a user in the sudoers, a trustable shell could prevent the leakage of the password, without which the malicious process can not get the root privilege.

People switching to Linux from Windows already complain enough about having to keep entering their password in the terminal as it is!
Modifying ~/.bashrc is not a common action. Actually the action is usually taken by the users manually. Additionally, users modifying ~/.bashrc usually heavily rely on a trustable shell. So I think to make the shell trustable, it is worthwhile to enter passwords.
 

seekstar

New Member
Credits
74
I found another issue. As long as ".bashrc" is placed under ~, the malicious process could remove the file and replace it with a malicious one. So to make the shell trustable, maybe ".bashrc" should be moved to someplace like "/etc/bashrc.d/xxx.bashrc".
 
$100 Digital Ocean Credit
Get a free VM to test out Linux!

Members online


Top