First of all, my apologies if this is in the wrong place or has already been covered in another thread. I did quite a lot of searching but couldn't find anything similar. I'm not sure if this is genuinely a security issue but as I'm relatively inexperienced with Linux I'd be grateful for any advice.

I'm running Fedora Kernel 2.6.35.12-90.fc14.i686 and GNOME 2.32.0

In the last couple of days each time I boot up I get a message asking me to enter the root password. This is before I do anything else on the machine, launch any programs or anything like that. The message in full is as follows but I should point out that the path to the command it references each time changes:

"Run as root - KDE su. The action you requested needs root privileges. Please enter root's password below or click Ignore to continue with your current privileges. Command: sh /tmp/tmpTcgnpE" It presents me with a field to enter a password and buttons to ignore, cancel or OK - I've chosen cancel each time.

Each time I get this, it points to /tmp/ but then the last part of the path changes each time. I've attached two screenshots to this as examples.

Can anyone advise me what this is? Is it legitimate or is there something trying to run on my machine that I should be wary of? I'd be grateful for any advice

Attached Thumbnails

   

When you see that message, press Ctrl+Alt+F1 and login. Copy the file mentioned in that message to another place and remove the execute-permission, so that you can examine it without the risk of running it.

TobiSGD has some very good advice. Do not execute the file unless you know what it is. The problem with the TMP directory is that by default it has 777 permissions, meaning anybody could put stuff there. Tmp is also a common place to store malicious binary applications and by being located in tmp makes the file suspicious. Giving this file root permissions could be downright disastrous!

What is also bothersome is the fact that it wants to execute on startup. You should try to find out how this thing got linked and what is calling it during startup. Normally, the startup scripts are covered by the init scripts (/etc/init.d/ or /etc/rc.d/ depending on the distribution). Is it possible that one of these got modified? I would also look for any KDE specific startup applications that get called. The bottom line is that the application got linked to from somewhere. Either you did something that put it there and it is now trying to execute or someone else did, in which case you may have bigger problems but as long as it is confined to /tmp and a user account it should be recoverable.

1 members found this post helpful.

I really appreciate both of these replies, although I'm afraid that some of your advice may be a little beyond my current capabilities so I need to ask for a little more help. First of all here's what I've found:

By moving the file to another location & opening it in a text editor I found that it contains the following

#!/bin/sh -e
cp /etc/fstab /etc/fstab.bak &&
cat /tmp/tmpZEiAJj > /etc/fstab &&
mount -o remount /

My limited understanding makes me think that this is trying to add the contents of the file /tmp/tmpZEiAJj to the fstab file, I think I'm correct in saying that this is then creating new mount points when it calls the remount command.

So the contents of the file /tmp/tmpZEiAJj are:


#
# /etc/fstab
# Created by anaconda on Sun Nov 28 09:03:12 2010
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/vg_home-lv_root / ext4 defaults 1 1
UUID=3e100ef2-c06a-4d53-b5a6-f7335c3d675a /boot ext4 defaults 1 2
/dev/mapper/vg_home-lv_swap swap swap defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0

This, I'm afraid is about as far as my knowledge will take me. I don't know if any of these mount points are likely to be malicious. As far as Noway's suggestions to try and find what links to this file, I'm kind of struggling with that. I have found what looks like init scripts under both /etc/init.d/ and /etc/rc.d/ but am not sure how to determine whether any of them would be responsible for this. Can you provide any more advice?

One thing I should have said previously, this is on a home laptop connected to the net. I am the only person that uses it so if anything has been changed on it that I didn't do, that's come from the web somewhere.

Once again, I am really grateful for any help.

I am starting to this that this may be an excellent example of the difference between Windows and Linux when it comes to security design. Yes, you are correct, the initial script wants to modify your /etc/fstab. Normally, only root is allowed to mount hardware and placing an entry in /etc/fstab says, amongst other things, that non root users are allowed to mount these items.

Some of what is in that /fstab goes a bit over my head too, but the first couple of lines look suspicious. Specifically, they are calling for /dev/mapper (see this wikipedia link). Basically, I believe that means that it allows a virtual device to "overlay" or impersonate the regular device. This feature is used for things like mounting encrypted volumes which logically appear in place of the physical volume that is scrambled. While it is possible that this is legit, assuming you have encrypted the hard drive or something, a /tmp file certainly shouldn't be messing with it.

Chances are that one of the (hidden) files in your home directory has been modified. Adding applications to startup on KDE is pretty easy and involves placing them in the following directory /home/.kde/Autostart. There are other scripts that get run too and could be the root cause. Here is what I would recommend for the next steps:

1) save, but quarantine those files. It may be beneficial to examine them later, but for now they are evidence.
2) search your home directory hidden files for the words /tmp and those file name strings. They are being called from somewhere.
3) What you find will determine the next steps. It appears that files owned by the non-privileged user at least may have been compromised. This can happen with applications such as Java which have access to your files. The next steps will involve finding what has been modified and then determining if they managed to elevate the privilege to root. At the moment, it doesn't look like it or else they wouldn't be asking you to run a script in the temp folder with root privilege.

Once we get to that point, LQ Security will help you with the process, but for now lets take it one step at a time.

Follow-up Edit
The scripts continue to not sit well with me. Here is a link that might prove interesting: http://www.cyberciti.biz/faq/linux-f...-update-fstab/
Basically, like I said, the first line with /dev/mapper can be used to overlay a file system. This is what would be happening with your / and swap spaces. The second line with the UUID looks like it is trying to mount the /boot via the UUID of the drive. From what I understand this is useful for situations where a volume may move to different media. The devpts are your pseudo terminals, shell prompts if you will and gid 5 is probably the tty group. Tmpfs is basically a shared memory ram drive and the last lines mount your /sys and /proc directories for normal operation.

It looks to me like these scripts are designed to replace your file system with a counterfeit one, presumably to allow someone to PWN your system.

Out of curiosity, what does your normal /etc/fstab look like?

1 members found this post helpful.

I suppose this is your Desktop PC (not server). I searched for similar things on the net and it looks like anaconda is trying to mount encrypted root partition and swap.
Didn't you try to install an encrypted filesystem previously or install anything strange before this happened?
It looks like some unsuccessful installation of such things.

http://forums.fedoraforum.org/archiv.../t-251236.html

Hua is correct in that the text in the scripts matches what one sees in attempts to encrypt the hard drive, especially ones that failed. The part about executing scripts in the /tmp directory with strange looking names and wanting root privileges in the process, is troublesome because these are classic warning signs.

In essence, you seriously need to find out what is calling these scripts and determine if it was something you had modified or not.

Just to clarify again, yes this is a desktop machine.

Apologies for the delay in replying, this has mainly been because I've had no success in trying to find what is actually calling these files. I followed Noway2's advice and did a search of everything in the hidden files in my home directory for these file name strings but turned up nothing. As the file name in /tmp changes with every reboot I first checked for the name displayed for my current session and then for those from previous sessions but I found nothing at all. Which seems strange based on what's been said in this thread already. Just to be absolutely certain, can someone confirm for me if I'm using the right approach for this (I don't want to be making a n00b mistake on this)? I cd into my home directory then issue the command:

grep -lr 'tmpHqwJEo' .*

Where 'tmpHqwJEo' is the file name displayed by the message I get on screen at boot up. For completeness here's the output of that:

grep: ./.pulse/a7ce572ee4e8806f30aeee9c00000011-runtime/native: No such device or address
grep: ./.mozilla/firefox/wjesgbt5.default/lock: No such file or directory
grep: ./.kde/socket-Home.Laptop/klauncherMT2126.slave-socket: No such device or address
grep: ./.kde/socket-Home.Laptop/kdesud_:0: No such device or address
grep: ./.kde/socket-Home.Laptop/kdeinit4__0: No such device or address
grep: ./.dropbox/iface_socket: No such device or address
grep: ./.dropbox/command_socket: No such device or address
grep: ../Stuart/.pulse/a7ce572ee4e8806f30aeee9c00000011-runtime/native: No such device or address
grep: ../Stuart/.mozilla/firefox/wjesgbt5.default/lock: No such file or directory
grep: ../Stuart/.kde/socket-Home.Laptop/klauncherMT2126.slave-socket: No such device or address
grep: ../Stuart/.kde/socket-Home.Laptop/kdesud_:0: No such device or address
grep: ../Stuart/.kde/socket-Home.Laptop/kdeinit4__0: No such device or address
grep: ../Stuart/.dropbox/iface_socket: No such device or address
grep: ../Stuart/.dropbox/command_socket: No such device or address
grep: .dropbox/iface_socket: No such device or address
grep: .dropbox/command_socket: No such device or address
grep: .kde/socket-Home.Laptop/klauncherMT2126.slave-socket: No such device or address
grep: .kde/socket-Home.Laptop/kdesud_:0: No such device or address
grep: .kde/socket-Home.Laptop/kdeinit4__0: No such device or address
grep: .mozilla/firefox/wjesgbt5.default/lock: No such file or directory
grep: .pulse/a7ce572ee4e8806f30aeee9c00000011-runtime/native: No such device or address

I then took a look at the contents of /etc/fstab as they currently stand and found the following, which is quite worrying. I am absolutely certain I have never given these scripts permission to overwrite that file but it seems that what they are trying to over write it with is what is already in it. Here is the contents of the file, you'll see if you refer to my previous post that it is identical:

#
# /etc/fstab
# Created by anaconda on Sun Nov 28 09:03:12 2010
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/vg_home-lv_root / ext4 defaults 1 1
UUID=3e100ef2-c06a-4d53-b5a6-f7335c3d675a /boot ext4 defaults 1 2
/dev/mapper/vg_home-lv_swap swap swap defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0

Having read Noway2's posts, particularly the one which seems to indicate that the second line is a concern, I commented out that line and tried a re-boot. This failed in that the machine appeared to hang at the fedora splash screen and progressed no further despite leaving it for the better part of 8 hours. I eventually had to boot from disk to get in and remove that comment.

With regards to Hua's post - to my knowledge nothing new has been installed on this machine in over a month, including an encrypted filesystem.

The "/tmp/tmpHqwJEo" name may be a good match for anything using (any equivalent of) 'mktemp /tmp/tmpXXXXXX' ('man mktemp' for more) but this says nothing about it being malicious or not.

Apart from ~/.kde/Autostart/ other options for wedging in commands are:
- SysV init scripts in /etc/rc.d/*,
- ("@reboot") entries in system cron directories ('find /etc/cron* -type f -print0|xargs -0 -iX cat 'X';'), and
- /etc/crontab 'cat /etc/crontab'
though the above usually get executed well before Xorg starts and with root "rights" anyway or otherwise don't require user interaction anyway.
Other user options may be:
- user crontabs ('find /var/spool/cron -type f -print0|xargs -0 -iX cat 'X';'),
- ~/.Xclients,
- any ~/.config/autostart/*
- ~/.gnomerc or ~/.gnome2/session or ~/.gnome2/session-manual (or see System>Preferences>Startup apps or System>Preferences>Sessions in the GNOME menu).

Since the OP stated in his OP that this happened "In the last couple of days" it could be beneficial to run a 'rpm -Vva|grep -v '^\.\{8\}' to see if any (configuration?) files got changed, look for recent package upgrades since this anomaly started and if there's a backup from before this started diff user files with them?

Hi,
I guess it could be correlated to Dropbox, from waht you post it looks like you have a Dropbox client installed in your desktop.
To verify if it is correlated to dropbox you could easily test it quitting the client and restart it again, if you will receive another same request it prove that it is correlated to dropbox

1 members found this post helpful.

This appears to be correct. I stopped and restarted Dropbox and the same error message was displayed. I selected "Cancel" as before and Dropbox appeared to start up as normal. Since then I have been unable to replicate the problem and the message hasn't been displayed again.

This seems like very strange behaviour - I have been using Dropbox for months and the problem only arose last week. Restarting the application seems to have stopped the message from being displayed despite the fact that I have not given it the root password. Given everything that has already been posted on this thread, I now need to consider whether Dropbox is secure.

I've marked this as solved as since disabling dropbox I haven't had the problem again. Many thanks to everyone who tried to help me out with this

Stuart

Strange problem indeed. Definitely mimics signs of host intrusion.
This seems to be a common question and I suggest you do research this. In general with cloud storage, it is best to only put things there that you wouldn't mind seeing on the evening news. If you want to put anything remotely sensitive, be sure to encrypt it with PGP/GPG first. Keep the private key safe and use a good password.

Just saw this: http://hardware.slashdot.org/story/1...About-Security which made me think of this thread.

The bottom line here is ... "do exactly what you did." Refuse to enter the information, stop the system and conclusively find out why you are being asked.

A very close analogy is: "never respond to a request to enter any password, including your own, unless you know damn well why you are getting it and what will happen if you respond correctly."

And: "practice the Principle of Least Privilege." Do not give yourself any more privileges than you actually require. If you need to maintain (e.g. non-system) files in a shared public-to-the-system location, set up a "system maintenance" account for this purpose, and do not give that account (either...) elevated privileges.