Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

A hacker has dropped a file in my tmp dir that is causing issues. Nothing malicious except creating GB's of error_log entries because their script is failing. However, the file they are using to execute has no permissions and even as ROOT I can't delete or rename this file.

----------  1 wwwusr wwwusr 1561 Jan 19 02:31 zzzzx.php

root@servername [/home/wwwusr/public_html/tmp]# rm zzzzx.php
rm: remove write-protected regular file './zzzzx.php'? y
rm: cannot remove './zzzzx.php': Operation not permitted

I have also tried removing by inode

root@servername [/home/wwwusr/public_html/tmp]# ls -il

...
1969900 ----------  1 wwwusr wwwusr 1561 Jan 19 02:31 zzzzx.php

root@servername [/home/wwwusr/public_html/tmp]# find . -inum 1969900 -exec rm -i {} \;

rm: remove write-protected regular file './zzzzx.php'? y
rm: cannot remove './zzzzx.php': Operation not permitted

How do I delete this file?

share|improve this question
11  
Were I you, I'd be looking to nuke and pave that box. It clearly has at least one security hole, which is bad enough that someone can write new files with custom permissions outside the document root, and then on top of all that, manage to get PHP/Apache to try and load it. My friend, you are royally pwned. If you want that box back, you've got to nuke it from orbit. It's the only way to be sure. –  Warren Young Jan 23 '13 at 22:42
    
Thanks Warren. This is actually a brand new box moving over accounts that have never been compromised before. I'm trying to figure out what the settings are that are different (both CPanel boxes). –  Bradley Jan 28 '13 at 5:00
    
Just because the OS is recent and the install fresh doesn't mean you cannot have a compromise. A bug detected today in an OS that shipped 6 months ago may persist for years, as people continue to install the older OS from CDs that are continually getting older. Even if there is a patch for the flaw, the window between installation and update allows the compromise. Setting that aside, if I am wrong that some bad actor placed that file on your system, a conscientious sysadmin would have to at least try to explain its presence in another way. –  Warren Young Jan 28 '13 at 5:19
add comment

2 Answers

up vote 20 down vote accepted

The file has probably been locked using file attributes.

As root, do

lsattr zzzzx.php

Attributes a (append mode) or i (immutable) present would prevent your rm. If they're there, then

chattr -ai zzzzx.php
rm zzzzx.php

should delete your file.

share|improve this answer
    
Thank You! This was it. –  Bradley Jan 23 '13 at 19:55
    
I would avoid calling them extended file attributes, as it could cause confusion with the extended file attributes as set with setfxattr and used to store ACL or SELinux... attributes. –  Stephane Chazelas Jan 23 '13 at 20:06
    
@Stephane Chazelas - ok. Does plain 'file attributes' work for you? –  ire_and_curses Jan 23 '13 at 20:07
    
I can't think of anything better. They used to be ext2 file attributes but they are now supported by other FS on Linux like xfs of btrfs, so one can no longer call them that. –  Stephane Chazelas Jan 23 '13 at 20:11
add comment

Unfortunately Warren didn't post as an answer but as a comment; I can't emphasise enough that he's totally correct.

Removing/changing one file won't fix your REAL problem; it will make ONE symptom go away. Take the box offline, take an image for later forensics, and re-install, with a newer version (hopefully w/ new security fixes) of whatever you were running.

I repeat: deleting the file is NOT A FIX.

share|improve this answer
5  
I didn't post an answer because my comment doesn't answer the asked question. –  Warren Young Jan 23 '13 at 23:46
    
Heh ... I guess I'm still too new to the stackexchange way of doing things. I'd rather get down voted for "not answering" than not saying what needs to be said ;D –  tink Jan 23 '13 at 23:55
    
The question isn't about fixing that problem, it's about removing a file with no permissions. And it's an interesting question! –  wim Jan 24 '13 at 1:55
4  
@tink: That's what comments are for: to say things that need to be said, which are not answers to the question. –  Warren Young Jan 24 '13 at 2:05
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.