rares_dumitrescu
asked on
DoS program/bug .
Hello, i have a program that was used to bypass my security stuff. I am running freebsd 5.4 pl13. it is a shell server. the exploit creates like 400.000 files. each 1000 files have the SAME inode. i don't know how this is possible but maybe you can help me out on this. The idea is that when periodic tasks run ... like updatedb, or security or whatever uses find/locate command, server reboots. i think the issue is because the files have the same inodes, and they are a lot ...
the files look like this you can see the inode in the left side, that it is the same
1319375 -rw------- 30000 user users 0 Apr 10 23:31 xxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxx0 75
1319375 -rw------- 30000 user users 0 Apr 10 23:31 xxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxx0 76
1319375 -rw------- 30000 user users 0 Apr 10 23:31 xxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxx0 77
Now, i tried to decompile, and i think i got the procedures in assembly. the file is relative small. 6667 bytes ...
here is what i got. all procedures are here. is it assembly ? could you please tell me what the script does ? because i have quota enabled, and limitations for files and disk space, but with this proggie, 400000 files were using 400 inodes. because each 1000 had the same inode. need help pls
<Code Removed by Request> Paul Caswell
the files look like this you can see the inode in the left side, that it is the same
1319375 -rw------- 30000 user users 0 Apr 10 23:31 xxxxxxxxxxxxxxxxxxxxxxxxxx
1319375 -rw------- 30000 user users 0 Apr 10 23:31 xxxxxxxxxxxxxxxxxxxxxxxxxx
1319375 -rw------- 30000 user users 0 Apr 10 23:31 xxxxxxxxxxxxxxxxxxxxxxxxxx
Now, i tried to decompile, and i think i got the procedures in assembly. the file is relative small. 6667 bytes ...
here is what i got. all procedures are here. is it assembly ? could you please tell me what the script does ? because i have quota enabled, and limitations for files and disk space, but with this proggie, 400000 files were using 400 inodes. because each 1000 had the same inode. need help pls
<Code Removed by Request> Paul Caswell
Could you be a bot clearer about what you are asking us to do?
If you are asking how this program was built then it's originally written in C or C++. I can get that because of the "%02d/%05d" type formatting and the fact that there exists a function called '_main'.
The existence of __do_global_ctors_aux suggests it might be C++ but it may not be.
Paul
If you are asking how this program was built then it's originally written in C or C++. I can get that because of the "%02d/%05d" type formatting and the fact that there exists a function called '_main'.
The existence of __do_global_ctors_aux suggests it might be C++ but it may not be.
Paul
A few comments :
1) eggdrop is the name of a popular IRC bot ... any chance this is what this executable is ?
2) multiple filenames using the same inode, refer to the same physical file ... afaik that shouldn't pose any problems. I've seen an exploit that overflowed the i_count member of a struct inode by referring to the same inode more than 65535 times, but as you say that in this case only 1000 filenames map to the same inode, that shouldn't be a problem here.
3) As Paul said, the language this software was originally written in is C, as shown by the use of the libc.so.5 library
A few questions :
1) Are you sure that it was this program that created all those files ?
2) How did you track down the crash problem to this particular piece of software ?
I'll look over the code a bit to see if I can find something of use ...
1) eggdrop is the name of a popular IRC bot ... any chance this is what this executable is ?
2) multiple filenames using the same inode, refer to the same physical file ... afaik that shouldn't pose any problems. I've seen an exploit that overflowed the i_count member of a struct inode by referring to the same inode more than 65535 times, but as you say that in this case only 1000 filenames map to the same inode, that shouldn't be a problem here.
3) As Paul said, the language this software was originally written in is C, as shown by the use of the libc.so.5 library
A few questions :
1) Are you sure that it was this program that created all those files ?
2) How did you track down the crash problem to this particular piece of software ?
I'll look over the code a bit to see if I can find something of use ...
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
It would maybe have been better to put this in the Security department ... but I've got the impression that rares_dumitrescu just wants to know what happened to his system. In any case, exploits like this (if it is one, and it looks like it is) are more easily available than by decompiling a binary.
I will however be a bit more cautious from now on not to post anything that could harm EE ... I just got sucked into the challenge to find out what this code does, and once I found out, it seemed a pity not to post it lol. My apologies ...
I will however be a bit more cautious from now on not to post anything that could harm EE ... I just got sucked into the challenge to find out what this code does, and once I found out, it seemed a pity not to post it lol. My apologies ...
ASKER
we solved the problem. system was rebuilt using different partitioning system. /home - mounted with noexec. users were installed programs global and configs are in their home directories, so this program that was used to crash the system or any program / exploit could not be run ... i been trying to find a way so i would not rebuild the system to beat this thing off but this was the only viable solution i got ...
thanks guys for all the help you got me.
thanks guys for all the help you got me.
ASKER
please edit the post and take out the code that might harm other people... this stuff is really dangerous ... really
ASKER
and please delete the procedures and ldd i wrote up there because someone could rebuild the code, and really i saw what it did to my box, so i would not want to be the cause for pain on someone else's back ... i mean .. for this one the only solution i got was either give no shells, either the specific partitioning up there and rest hardening stuff ....
again thanks for your help and dedication ... was great
again thanks for your help and dedication ... was great
Hi Paul,
no problem at all ... since rares_dumitrescu resolved his problem it's no longer needed (especially since he could resolve it without the code :)). It was a fun challenge for me (to refresh my reverse engineering skills which I haven't used in a while lol), but this is indeed not the best place to be posting this.
Although I still believe that security comes from the public knowledge of all kinds of attacks ... If you make code like this publicly available (to crackers as well as security people), it will be a short while before a patch (or similar) is written to fix this security hole. There are several good sites around that are built on this idea ... I won't mention their names (although they should be common knowledge), but I'm sure you know what I'm talking about :)
Again : no problem ... Whatever is necessary to uphold the quality of this site is fine by me :) btw, as rares_dumitrescu said : you might want to remove the code in his question too, as it does exactly the same, although a bit more cryptical :)
Infinity
@
no problem at all ... since rares_dumitrescu resolved his problem it's no longer needed (especially since he could resolve it without the code :)). It was a fun challenge for me (to refresh my reverse engineering skills which I haven't used in a while lol), but this is indeed not the best place to be posting this.
Although I still believe that security comes from the public knowledge of all kinds of attacks ... If you make code like this publicly available (to crackers as well as security people), it will be a short while before a patch (or similar) is written to fix this security hole. There are several good sites around that are built on this idea ... I won't mention their names (although they should be common knowledge), but I'm sure you know what I'm talking about :)
Again : no problem ... Whatever is necessary to uphold the quality of this site is fine by me :) btw, as rares_dumitrescu said : you might want to remove the code in his question too, as it does exactly the same, although a bit more cryptical :)
Infinity
@
rares_dumitrescu,
if you want this problem fixed in a more permanent way, I suggest posting this on one of the security sites i mentioned, as well as in the bugs/security holes section of your OS's site/forum/mailing list. It shouldn't take long for someone to come up with a fix ...
if you want this problem fixed in a more permanent way, I suggest posting this on one of the security sites i mentioned, as well as in the bugs/security holes section of your OS's site/forum/mailing list. It shouldn't take long for someone to come up with a fix ...
ASKER
ldd eggdrop
eggdrop:
libc.so.5 => /lib/libc.so.5 (0x28076000)
trings eggdrop
/libexec/ld-elf.so.1
FreeBSD
libc.so.5
__stdoutp
_DYNAMIC
__stderrp
creat
fflush
_init
environ
fprintf
__deregister_frame_info
__progname
memset
_init_tls
_fini
sprintf
atexit
stat
_GLOBAL_OFFSET_TABLE_
link
_Jv_RegisterClasses
mkdir
__register_frame_info
_edata
__bss_start
_end
$FreeBSD: src/lib/csu/i386-elf/crti.
%02d/%05d...
%02d-%02d
mkdir(%s) failed
%s/%s%03d
creat(%s) failed
stat(%s) failed
link(%s,%s) failed
finished successfully
$FreeBSD: src/lib/csu/i386-elf/crtn.