Uh oh. Finding an a.out in your /var/log/httpd doesn't instill a warm fuzzy feeling. I have ~ 4k a.out there dated Oct 12, which unfortunately is just past my logrotate cutoff now, so I can't check access.log (drat) without hitting the (hard to hit) backups. file a.out a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped I fired up a live-cd linux with no disks or net attached to try to run it (I put it on a usb stick). But when I do *the shell* returns ENOENT and won't run. I tried ./a.out. I tried moving it to a fs that shouldn't be mounted noexec. I tried strace a.out and strace ./a.out and strace shows only the exec attempt and the error print and quit. Huh? How can I get this thing to run? Anyway to see what it is doing? Disassemble? It is not stripped, so gdb? How can I step-run it from the start (ie nothing executes until I step)? What else to do with this file? I'll see if I can dig up the access.log from that date and get more details.
1) Run it on a 32-bit livecd 2) ldd(1) Otherwise, look at the elftools (or something like that) package to get more info about the binary. Don't you run all your systems with selinux? -Adam On January 5, 2015 5:33:35 PM CST, Trevor Cordes <trevor@tecnopolis.ca> wrote:
Uh oh. Finding an a.out in your /var/log/httpd doesn't instill a warm fuzzy feeling.
I have ~ 4k a.out there dated Oct 12, which unfortunately is just past my logrotate cutoff now, so I can't check access.log (drat) without hitting the (hard to hit) backups.
file a.out a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
I fired up a live-cd linux with no disks or net attached to try to run it (I put it on a usb stick). But when I do *the shell* returns ENOENT and won't run. I tried ./a.out. I tried moving it to a fs that shouldn't be mounted noexec. I tried strace a.out and strace ./a.out and strace shows only the exec attempt and the error print and quit.
Huh? How can I get this thing to run?
Anyway to see what it is doing? Disassemble? It is not stripped, so gdb? How can I step-run it from the start (ie nothing executes until I step)?
What else to do with this file?
I'll see if I can dig up the access.log from that date and get more details. _______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On 2015-01-05 Adam Thompson wrote:
1) Run it on a 32-bit livecd
The SRC I booted was 32-bit (confirmed).
2) ldd(1)
#ldd /tmp/a.out not a dynamic executable
Otherwise, look at the elftools (or something like that) package to
I'll check it out.
get more info about the binary. Don't you run all your systems with selinux? -Adam
Nope, not willing to invest the (at least) month it would take to tweak it for all the crazy stuff I do. It's a real nightmare for complex apache/php setups, not to mention smb, etc. I have enough debugging headaches with perms without selinux. I'll do it one day...
Don't run ldd on a binary you don't trust [1]. I think the safer way is objdump -p a.out | grep NEEDED. Did you try "strings" to see what's in there? "nm" and "objdump" might give some more info on the method names especially since it's been stripped. Also, just for kicks, do an "lsof | grep deleted" to see if any processes have some old files open that you can grab out of proc that the exploit tried to delete but was held open. [1] http://www.catonmat.net/blog/ldd-arbitrary-code-execution/ Sean On Mon, Jan 5, 2015 at 5:56 PM, Adam Thompson <athompso@athompso.net> wrote:
1) Run it on a 32-bit livecd 2) ldd(1) Otherwise, look at the elftools (or something like that) package to get more info about the binary. Don't you run all your systems with selinux? -Adam
On January 5, 2015 5:33:35 PM CST, Trevor Cordes <trevor@tecnopolis.ca> wrote:
Uh oh. Finding an a.out in your /var/log/httpd doesn't instill a warm fuzzy feeling.
I have ~ 4k a.out there dated Oct 12, which unfortunately is just past my logrotate cutoff now, so I can't check access.log (drat) without hitting the (hard to hit) backups.
file a.out a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
I fired up a live-cd linux with no disks or net attached to try to run it (I put it on a usb stick). But when I do *the shell* returns ENOENT and won't run. I tried ./a.out. I tried moving it to a fs that shouldn't be mounted noexec. I tried strace a.out and strace ./a.out and strace shows only the exec attempt and the error print and quit.
Huh? How can I get this thing to run?
Anyway to see what it is doing? Disassemble? It is not stripped, so gdb? How can I ste! p-run it from the start (ie nothing executes until I step)?
What else to do with this file?
I'll see if I can dig up the access.log from that date and get more details. ------------------------------
Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
-- Sean Walberg <sean@ertw.com> http://ertw.com/
On 2015-01-05 Sean Walberg wrote:
Don't run ldd on a binary you don't trust [1]. I think the safer way
Oops. Oh well, it didn't seem to do anything, and I was running it as a bogus severely limited user. I really don't understand the error/output when I run the a.out though. Since my description was lacking, here's the exact output I get: % strace ./a.out execve("./a.out", ["./a.out"], [/* 34 vars */]) = -1 ENOENT (No such file or directory) write(2, "strace: exec: No such file or di"..., 40strace: exec: No such file or directory ) = 40 exit_group(1) = ? +++ exited with 1 +++ Who's telling me ENOENT? The shell? Kernel? a.out? I don't get it at all... very confused. Could this happen with a messed up / incomplete a.out?
is objdump -p a.out | grep NEEDED. NEEDED libnssutil3.so
Did you try "strings" to see what's in there?
10:49pm /tmp>strings a.out /usr/lib/libc.so.1 libnssutil3.so _edata __bss_start _end
"nm" and "objdump"
10:51pm /tmp>nm a.out 08049f98 d _DYNAMIC 00000000 d _GLOBAL_OFFSET_TABLE_ 0804a000 D __bss_start 0804a000 D _edata 0804a000 D _end U _start I tried all the relevant nm options and nothing more interesting than the above popped out. SEP 12 enterprise doesn't detect any threats in it.
Also, just for kicks, do an "lsof | grep deleted" to see if any
That system has been rebooted tons of times since Oct 12, so lsof won't help, unless it's still compromised. But I just did a fresh reinstall (for other reasons) so even that is unlikely. For the masochistic, here's all the info I could get out of objdump. My x86 asm is rusty, but I'll delve into it when I have more time. I'm thinking the key is to just look for system calls to see what it's trying to do. 11:10pm /tmp>objdump -hDpst a.out a.out: file format elf32-i386 Program Header: PHDR off 0x00000034 vaddr 0x08048034 paddr 0x08048034 align 2**2 filesz 0x000000c0 memsz 0x000000c0 flags r-x INTERP off 0x000000f4 vaddr 0x080480f4 paddr 0x080480f4 align 2**0 filesz 0x00000013 memsz 0x00000013 flags r-- LOAD off 0x00000000 vaddr 0x08048000 paddr 0x08048000 align 2**12 filesz 0x00000194 memsz 0x00000194 flags r-- LOAD off 0x00000f98 vaddr 0x08049f98 paddr 0x08049f98 align 2**12 filesz 0x00000068 memsz 0x00000068 flags rw- DYNAMIC off 0x00000f98 vaddr 0x08049f98 paddr 0x08049f98 align 2**2 filesz 0x00000068 memsz 0x00000068 flags rw- RELRO off 0x00000f98 vaddr 0x08049f98 paddr 0x08049f98 align 2**0 filesz 0x00000068 memsz 0x00000068 flags r-- Dynamic Section: NEEDED libnssutil3.so HASH 0x08048108 STRTAB 0x0804816c SYMTAB 0x0804812c STRSZ 0x00000028 SYMENT 0x00000010 DEBUG 0x00000000 Sections: Idx Name Size VMA LMA File off Algn 0 .interp 00000013 080480f4 080480f4 000000f4 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .hash 00000024 08048108 08048108 00000108 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .dynsym 00000040 0804812c 0804812c 0000012c 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .dynstr 00000028 0804816c 0804816c 0000016c 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .eh_frame 00000000 08048194 08048194 00000194 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .dynamic 00000068 08049f98 08049f98 00000f98 2**2 CONTENTS, ALLOC, LOAD, DATA SYMBOL TABLE: 080480f4 l d .interp 00000000 .interp 08048108 l d .hash 00000000 .hash 0804812c l d .dynsym 00000000 .dynsym 0804816c l d .dynstr 00000000 .dynstr 08048194 l d .eh_frame 00000000 .eh_frame 08049f98 l d .dynamic 00000000 .dynamic 08049f98 l O .dynamic 00000000 _DYNAMIC 00000000 l O .dynamic 00000000 _GLOBAL_OFFSET_TABLE_ 0804a000 g .dynamic 00000000 _edata 0804a000 g .dynamic 00000000 _end 00000000 *UND* 00000000 _start 0804a000 g .dynamic 00000000 __bss_start Contents of section .interp: 80480f4 2f757372 2f6c6962 2f6c6962 632e736f /usr/lib/libc.so 8048104 2e3100 .1. Contents of section .hash: 8048108 03000000 04000000 01000000 02000000 ................ 8048118 03000000 00000000 00000000 00000000 ................ 8048128 00000000 .... Contents of section .dynsym: 804812c 00000000 00000000 00000000 00000000 ................ 804813c 10000000 00a00408 00000000 10000600 ................ 804814c 23000000 00a00408 00000000 10000600 #............... 804815c 17000000 00a00408 00000000 10000600 ................ Contents of section .dynstr: 804816c 006c6962 6e737375 74696c33 2e736f00 .libnssutil3.so. 804817c 5f656461 7461005f 5f627373 5f737461 _edata.__bss_sta 804818c 7274005f 656e6400 rt._end. Contents of section .dynamic: 8049f98 01000000 01000000 04000000 08810408 ................ 8049fa8 05000000 6c810408 06000000 2c810408 ....l.......,... 8049fb8 0a000000 28000000 0b000000 10000000 ....(........... 8049fc8 15000000 00000000 00000000 00000000 ................ 8049fd8 00000000 00000000 00000000 00000000 ................ 8049fe8 00000000 00000000 00000000 00000000 ................ 8049ff8 00000000 00000000 ........ Disassembly of section .interp: 080480f4 <.interp>: 80480f4: 2f das 80480f5: 75 73 jne 804816a <_GLOBAL_OFFSET_TABLE_+0x804816a> 80480f7: 72 2f jb 8048128 <_GLOBAL_OFFSET_TABLE_+0x8048128> 80480f9: 6c insb (%dx),%es:(%edi) 80480fa: 69 62 2f 6c 69 62 63 imul $0x6362696c,0x2f(%edx),%esp 8048101: 2e 73 6f jae,pn 8048173 <_GLOBAL_OFFSET_TABLE_+0x8048173> 8048104: 2e 31 00 xor %eax,%cs:(%eax) Disassembly of section .hash: 08048108 <.hash>: 8048108: 03 00 add (%eax),%eax 804810a: 00 00 add %al,(%eax) 804810c: 04 00 add $0x0,%al 804810e: 00 00 add %al,(%eax) 8048110: 01 00 add %eax,(%eax) 8048112: 00 00 add %al,(%eax) 8048114: 02 00 add (%eax),%al 8048116: 00 00 add %al,(%eax) 8048118: 03 00 add (%eax),%eax ... Disassembly of section .dynsym: 0804812c <.dynsym>: ... 804813c: 10 00 adc %al,(%eax) 804813e: 00 00 add %al,(%eax) 8048140: 00 a0 04 08 00 00 add %ah,0x804(%eax) 8048146: 00 00 add %al,(%eax) 8048148: 10 00 adc %al,(%eax) 804814a: 06 push %es 804814b: 00 23 add %ah,(%ebx) 804814d: 00 00 add %al,(%eax) 804814f: 00 00 add %al,(%eax) 8048151: a0 04 08 00 00 mov 0x804,%al 8048156: 00 00 add %al,(%eax) 8048158: 10 00 adc %al,(%eax) 804815a: 06 push %es 804815b: 00 17 add %dl,(%edi) 804815d: 00 00 add %al,(%eax) 804815f: 00 00 add %al,(%eax) 8048161: a0 04 08 00 00 mov 0x804,%al 8048166: 00 00 add %al,(%eax) 8048168: 10 00 adc %al,(%eax) 804816a: 06 push %es ... 0804816c <.dynstr>: 804816c: 00 6c 69 62 add %ch,0x62(%ecx,%ebp,2) 8048170: 6e outsb %ds:(%esi),(%dx) 8048171: 73 73 jae 80481e6 <_GLOBAL_OFFSET_TABLE_+0x80481e6> 8048173: 75 74 jne 80481e9 <_GLOBAL_OFFSET_TABLE_+0x80481e9> 8048175: 69 6c 33 2e 73 6f 00 imul $0x5f006f73,0x2e(%ebx,%esi,1),%ebp 804817c: 5f 804817d: 65 gs 804817e: 64 fs 804817f: 61 popa 8048180: 74 61 je 80481e3 <_GLOBAL_OFFSET_TABLE_+0x80481e3> 8048182: 00 5f 5f add %bl,0x5f(%edi) 8048185: 62 73 73 bound %esi,0x73(%ebx) 8048188: 5f pop %edi 8048189: 73 74 jae 80481ff <_GLOBAL_OFFSET_TABLE_+0x80481ff> 804818b: 61 popa 804818c: 72 74 jb 8048202 <_GLOBAL_OFFSET_TABLE_+0x8048202> 804818e: 00 5f 65 add %bl,0x65(%edi) 8048191: 6e outsb %ds:(%esi),(%dx) 8048192: 64 fs ... Disassembly of section .dynamic: 08049f98 <_DYNAMIC>: 8049f98: 01 00 add %eax,(%eax) 8049f9a: 00 00 add %al,(%eax) 8049f9c: 01 00 add %eax,(%eax) 8049f9e: 00 00 add %al,(%eax) 8049fa0: 04 00 add $0x0,%al 8049fa2: 00 00 add %al,(%eax) 8049fa4: 08 81 04 08 05 00 or %al,0x50804(%ecx) 8049faa: 00 00 add %al,(%eax) 8049fac: 6c insb (%dx),%es:(%edi) 8049fad: 81 04 08 06 00 00 00 addl $0x6,(%eax,%ecx,1) 8049fb4: 2c 81 sub $0x81,%al 8049fb6: 04 08 add $0x8,%al 8049fb8: 0a 00 or (%eax),%al 8049fba: 00 00 add %al,(%eax) 8049fbc: 28 00 sub %al,(%eax) 8049fbe: 00 00 add %al,(%eax) 8049fc0: 0b 00 or (%eax),%eax 8049fc2: 00 00 add %al,(%eax) 8049fc4: 10 00 adc %al,(%eax) 8049fc6: 00 00 add %al,(%eax) 8049fc8: 15 00 00 00 00 adc $0x0,%eax ...
On 05/01/2015 11:23 PM, Trevor Cordes wrote:
On 2015-01-05 Sean Walberg wrote:
Don't run ldd on a binary you don't trust [1]. I think the safer way Oops. Oh well, it didn't seem to do anything, and I was running it as a bogus severely limited user.
I really don't understand the error/output when I run the a.out though. Since my description was lacking, here's the exact output I get:
% strace ./a.out execve("./a.out", ["./a.out"], [/* 34 vars */]) = -1 ENOENT (No such file or directory) write(2, "strace: exec: No such file or di"..., 40strace: exec: No such file or directory ) = 40 exit_group(1) = ? +++ exited with 1 +++
Who's telling me ENOENT? The shell? Kernel? a.out? I don't get it at all... very confused.
Could this happen with a messed up / incomplete a.out?
Well, execve is a system call, as shown by strace, so the ENOENT error most likely would come from the kernel. A "man execve" lists the reasons for various error codes, and it seems in this case, a missing shared library is the most likely candidate.
is objdump -p a.out | grep NEEDED. NEEDED libnssutil3.so
If that library is not in the usual /lib or /usr/lib, or somewhere in the LD_LIBRARY_PATH, then that's probably the problem. Otherwise, I don't know what the problem might be. The executable file obviously exists, and it doesn't seem it would need an interpreter, so it must be a shared library that it needs and the kernel can't find. -- Gilles R. Detillieux E-mail: <grdetil@scrc.umanitoba.ca> Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/ Dept. of Physiology and Pathophysiology, Faculty of Health Sciences, Univ. of Manitoba Winnipeg, MB R3E 0J9 (Canada)
participants (4)
-
Adam Thompson -
Gilles Detillieux -
Sean Walberg -
Trevor Cordes