unable to create any directory that uses numbers as the directory name

Version-Release number of selected component (if applicable):

root@server [~]# cat /etc/redhat-release

Red Hat Enterprise Linux ES release 4 (Nahant Update 5)

root@server [~]# uname -a
Linux server.integrityserver.net 2.6.9-55.ELsmp #1 SMP Fri Apr 20 17:03:35 EDT

2007 i686 i686 i386 GNU/Linux
root@server [~]#

How reproducible:

root@server [~]# mkdir 1
mkdir: cannot create directory `1': No such file or directory
root@server
[~]# mkdir 12
mkdir: cannot create directory `12': No such file or directory
root@server [~]# mkdir 1a2
root@server [~]#

Actual results:

mkdir: cannot create directory `1': No such file or directory

Expected results:

should be able to create a directory

Additional Info:

root@server [~]# ll $(which mkdir)
-rwxr-xr-x 1 root root 25060 Sep 19 15:46 /bin/mkdir*

root@server [~]# rpm -qf $(which mkdir)
coreutils-5.2.1-31.6
root@server [~]#
root@server [~]# mount -a
root@server [~]#
root@server [~]#alias | grep mk
root@server [~]#

FSType = ext3

Please advise.

Thanks

That's odd.... I can create folders just fine, i.e. mkdir 1 works.
You are root, so you have permissions, it's not nfs mounted folder, no aliases.... hmmm...
can you create normal folder like "mkdir test1" ? What is the status of "echo $?" after it fails ? Can you use "mkdir -p /path/to/1" ?

Very odd. Could something be wrong with the current directory? Try

pwd
ls -ld .

I agree... very odd. :slight_smile:

Try making a substitute command. With bash or ksh:
function xmkdir { perl -e 'mkdir(shift)' $1 ; }
xmkdir 12

Does that work? What about "mkdir ./12" and "xmkdir ./12"? What about "touch 12"?

Hi,

kernel upgrade fixed the issue

Hi I have the same issue as fed.linuxgossip.

I am running
RHEL AS 4 (Update 5)

Filesystem = ext3

Same Problem:
#########
I can not create numeric files.

I can not create them via anything i can think of, via echo, dd, touch, etc etc.

########

What I can do:

I can write to the same filesystem over NFS on a different machine just fine.

I can boot up off of a Live CD and write to the file system fine.

########
I tried using statically linked binaries like busybox, and I can not create the files.

I updated the system completely to RHEL AS 4 Update 6, (including the kernel), and the problem still persists.

#######
Perderabo :
Changing shells didnt help, nor did quotes or escape characters.

###########

Anything else special you did fed.linuxgossip ?

A kernel upgrade fixed the issue for a while but I ended up with an OS reload.

Does anybody have a copy of the 'mount' binary which was on these systems? Even a copy from backup is fine. I honestly suspect a rootkit being involved in this issue as I have seen it before. Looks like a number of binaries are involved, mount being one of them (due to how early it is called during bootup).

If you do have a copy from these systems, I would recommend you examine the impacted system's from another good kernel and then look for the binaries. You should find the 'mount' binary, another mount binary with what looks like a hash string appended to the end of the name, and then another empty mount file with another hash appended to the name. This seems to be the indicator that the system truly is infected.

Please post the binary to this forum, or PM me if you can supply me with a copy for analysis. I am interested to know if this is the same exact MD5 hash I found or not. Would really like to identify this particular rootkit and get some signatures out there so other people can find it easier.

We're having this problem as well, also on RHEL4. Does anyone have an idea of how their machines were compromised initially? We don't want to open up the same vulnerability again. I've attached the three /bin/mount* files we found on the compromised machine. There were other similarly compromised binaries as well, such as touch, basename and cat.
-Tom

Moderator's note: I have just approved the attachment so it should now be available for downloading. Download it with caution! It is suspected of being malware. --- Perderabo

Our system are compromised with this rootkit. We followed the recommendation from Hookups and found the mount binary with what looks like a hash string appended to the end. We could not find any infor about this on the internet. If you have any additional information regarding this root kit please let us know. Your help is greatly appreciated.

Daisy

This is not certain to be the same rootkit, this is pretty much standard MO for a rootkit.

This article is helpful on the subject of cleanup and evidence gathering:
http://www.honeynet.org/challenge/results/submissions/andy/evidence.txt

The posted binary is not the exact same as md5sums do not match. However, the file size is spot on. Also the same characteristics. Namely, the binary looks to be broken, but still loadable by the linux kernel:

---
[badfile@host badfiles]$ readelf -a ./mount
ELF Header:
Magic: 7f 45 4c 46 00 00 00 00 00 00 00 00 00 00 00 00
Class: none
Data: none
Version: 0
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0x1df26054
Start of program headers: 52 (bytes into file)
Start of section headers: 0 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 1
Size of section headers: 0 (bytes)
Number of section headers: 0
Section header string table index: 0

There are no sections in this file.

There are no section groups in this file.

Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x1df26000 0x1df26000 0x8453f 0x13e000 RWE 0x1000

There is no dynamic section in this file.

There are no relocations in this file.

There are no unwind sections in this file.

No version information found in this file.
[badfile@host badfiles]$ objdump -d ./mount
objdump: ./mount: File format not recognized
[badfile@host badfiles]$ file ./mount
mount: ELF invalid class invalid byte order (SYSV)
---

strace as unprivileged user show one system call to 'sysinfo()' with the argument of '0'. It returns an error:

---
[badfile@host evil_mount]$ strace ./mount
execve("./mount", ["./mount"], [/* 22 vars */]) = 0
sysinfo(0) = -1 EFAULT (Bad address)
---

Going to look further into the binary from an analysis workstation I have setup and see if I can get any more information.

Cheers,
Hookups

I appreciate any additional information you find on this rootkit.

Daisy

Does anyone have anymore information on this one, as I seem to have it on one of my servers...

Thanks

im wondering if anyone has identified a solution to this?

we have a new centos 5 server with the latest 2.6 kernel with the exact same mkdir issue

we have run ossec, rkhunter and chkrootkit and found nothing unusual so are at a loss

Hi,
Did anyone find the solution for this issue, I am too facing the same on my 3 servers at a time. Very strange issue. And along with that javascript insertion on all websites on those servers. Kindly respond if anyone has the solution for it or anyway to stop this from happening after new install....

Any news on this issue guys.... waiting for any solution...