Pregunta RedHat

Es la primera vez que me pasa esto. Investigando mas a fondo encontré la siguiente informacion:

Citar

Using a fixed memory address for the return on Linux.
As already discussed, it is common practice for Windows based exploits to overwrite the
saved return address stored on the stack with a fixed address that is known to contain a "jmp
reg" or "call reg" instruction. As there are certain advantages to doing this, can the same be
done for Linux? Well, the answer to that question is yes but only sometimes. The problem is
that there are so many distributions of Linux and on top of that several versions of each
distribution. As such we can't guarantee that all versions of Linux are going to have a "jmp
reg" instruction at a given address. Or can we?
Lets look at what's common across different distros and versions of Linux as far as memory
layout is concerned.
From /proc/[pid]/maps we can determine that the base address of an executable is always
0x08048000. We can also see that the Linux Dynamic Loader, ld-linux, which is responsible
loading shared objects into the process memory image, has a base address of 0x40000000.
We can also see the location of the stack from 0xC0000000 to 0xBFFFXXXX is pretty
standard too.
What we also notice however is that different systems will load shared objects at different
base addresses. On one system libc, for example, may be found at 0x40975000 but for the
same process on a different system the address may be 0x409A3000. Even if they were at
the same address we couldn't guarantee that the version of libc is the same on both systems.
The problem is further exacerbated by the fact that even if they were the same "version",
depending upon the version of gcc used to compile the shared object, the actual machine
code may be slightly different. So using shared objects is out of the question. There's just too
much variation.
So, what about the other areas? Even though we can find ld-linux at the same address on all
systems we can't guarantee that they're going to be the same version or have the exact
same machine code even if they are compiled from the same source. So this is pretty much
ruled out, too.
We can rule out the stack as it's dynamic in nature, anyway. So this leaves us with looking for
our opcode at an offset from the the base address of the actual executable. This too has the
same problems as everything else. If the executable has been compiled from the same
source but using different versions of gcc then we can't guarantee that our opcode will be
found at the right address. But, if the vulnerable process is from a commercial product that is
typically distributed in binary form then we're possibly onto something; and in the Linux world
if a linux box is running commercial software, then the box is usually performing a business
role and therefore making it a much more valuable propostion for an attacker. If a program is
precompiled by the vendor and then distributed, everyone running that version of the
software will have the same machine code at the same virtual address.
Here's the output of getopcode (source in Appendix D) looking for the "jmp esp" opcode in
the Oracle TNS Listener binary from Linux RedHat 9, SuSE 8.1 and Mandrake.
S.u.S.E. 8.1
GETOPCODE v1.0
SYSTEM (from /proc/version):
Linux version 2.4.19-4GB (root@Pentium.suse.de) (gcc version 3.2)
#1 Fri Sep 13 13:14:56 UTC 2002
Searching for "jmp esp" opcode in /orahome/bin/tnslsnr
Found "jmp esp" opcode at offset 0x000CBB97 (0x08113b97)
Finished.
RedHat 9:
GETOPCODE v1.0
SYSTEM (from /proc/version):
Linux version 2.4.20-8 (bhcompile@porky.devel.redhat.com)
(gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5))
#1 Thu Mar 13 17:54:28 EST 2003
Searching for "jmp esp" opcode in /home/oracle/orahome/bin/tnslsnr
Found "jmp esp" opcode at offset 0x000CBB97 (0x08113b97)
Finished.
Mandrake:
GETOPCODE v1.0
SYSTEM (from /proc/version):
Linux version 2.4.21-0.13mdkenterprise (flepied@bi.mandrakesoft.com)
(gcc version 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk))
#1 SMP Fri Mar 14 14:40:17 EST 2003
Searching for "jmp esp" opcode in /opt/Oracle/OraHome1/bin/tnslsnr
Found "jmp esp" opcode at offset 0x000CBB97 (0x08113b97)
Finished.
All three have a "jmp esp" opcode that can be found 834,455 bytes into the file, which, when
running as a process, has a virtual address of 0x08113b97. Searching for other "jmp reg"
instructions matches on all three distributions, too. So, if ever a buffer overflow is found in the
TNS Listener of version 9.2.0.1 of Oracle, then overwriting the saved return address with a
fixed location can work.
As it happens, Oracle does not ship precompiled binaries! It uses gcc and ld to build the
executables dynamically from object files. When built some of the Oracle binaries share the
same machine code where as others do not. That said, the principle still holds that provided
the binaries of a vulnerable program is the same on each system, an event most likely to
occur with commercial software, then we can use this method to gain control. And with this we
can dispatch with the NOP sled.
On top of this, of course, if you can get read access to the binary on the system being
attacked then the exploit can be tailored to that system and this method of gaining control will
work just fine.
Using stack based addresses for the return address.
This method is the preferred Linux way. The same technique can be used on Windows just
as effectively - perhaps even more so on Windows as the "dynamic" nature of the stack is
considerably less dynamic when compared to Linux - or at least some versions of Linux,
anyway.
The table below shows the value of the ESP, the stack pointer, on RedHat, Mandrake and
S.u.S.E. after overflowing a buffer in Oracle three times - with the process stopped and
restarted after each overflow. ESP points to the user supplied data after each overflow.
Mandrake RedHat 9 S.u.S.E 8.1
Overflow 1 0xBFFFC6E0 0xBFFFC0C0 0xBFFFC820
Overflow 2 0xBFFFC6E0 0xBFFFBE40 0xBFFFC820
Overflow 3 0xBFFFC6E0 0xBFFFC140 0xBFFFC820
As we can see the value of ESP is always the same on the Mandrake and S.u.S.E. systems
but changes each time on the RedHat system. No one distribution shares the same address
as another. The least value of ESP was on the RedHat system with 0xBFFFBE40. I tested
the RedHat system five more times and never had a value lower than this and never any
higher than the ESP value on the S.u.S.E. system.
The observed variations in the location of user supplied data after overflow has a maximum
difference of 2528 bytes (0xBFFFC820 - 0xBFFFBE40). As the Oracle XDB ftp service allows
the length of a single command to be only 2048 bytes long the maximum size of NOP sled
that can be employed here is 2048 – 9 – length_of_code – 2. (The 9 is length of “UNLOCK /
“ and the 2 is for the “\r\n”.) This does not bridge the gap in variations so writing a generic
exploit that will work first time, every time is not going to be possible. A more brutish approach
would have to be used and try the exploit several times using an address that increments by
c. 1800 with every attempt. This runs this risk of killing the Oracle process – but it is restarted.
That said if the process does die then there’s going to be a crash logged to the “bdump”
directory, usually, $ORACLE_HOME/admin/$ORACLE_SID/bdump.
The code in Appendix C uses the approach that overwrites the saved return address with a
stack based address and uses a NOP sled.

---------------------------- °°--------------------------------
Y el codigo fuente de programita que obtiene los opcodes:

Código:

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
FILE *fd = NULL;
unsigned char code=0;
unsigned char cnst=0x7F;
unsigned char buffer[2000]="";
size_t bytesread=0;
size_t count = 0, cnt = 0;
int found = 0;
int last = 0;
if(argc !=3)
{
printf("\n\tFIND-OPCODE\n\n\t%s /path/to/executable \"opcode\");
printf("\n\n\te.g.\n\n\t%s /bin/sh \"jmp esi\");
printf(“\n\n\tDavid Litchfield\n\t(david@ngssoftware.com)”);
printf(“\n\t27th June 2003\n\n\n",argv[0],argv[0]);
return 0;
}
if(strcmp("jmp esp",argv[2])==0)
code = 0xE4;
else if(strcmp("call esp",argv[2])==0)
code = 0xD4;
else if(strcmp("call eax",argv[2])==0)
code = 0xD0;
else if(strcmp("jmp eax",argv[2])==0)
code = 0xE0;
else if(strcmp("call ebx",argv[2])==0)
code = 0xD3;
else if(strcmp("jmp ebx",argv[2])==0)
code = 0xE3;
else if(strcmp("jmp ecx",argv[2])==0)
code = 0xE1;
else if(strcmp("call ecx",argv[2])==0)
code = 0xD1;
else if(strcmp("jmp esi",argv[2])==0)
code = 0xE6;
else if(strcmp("call esi",argv[2])==0)
code = 0xD6;
else if(strcmp("jmp edi",argv[2])==0)
code = 0xE7;
else if(strcmp("call edi",argv[2])==0)
code = 0xD7;
else if(strcmp("jmp edx",argv[2])==0)
code = 0xE2;
else if(strcmp("call edx",argv[2])==0)
code = 0xD2;
else if(strcmp("jmp ebp",argv[2])==0)
code = 0xE5;
else if(strcmp("call ebp",argv[2])==0)
code = 0xD5;
else
return printf("opcode not recognized.\n");
printf("\n\nGETOPCODE v1.0\n\n");
fd = fopen("/proc/version","r");
if(fd)
{
fgets(buffer,1996,fd);
printf("SYSTEM (from /proc/version):\n%s\n",buffer);
fclose(fd);
}
fd = fopen(argv[1],"rb");
if(!fd)
return printf("Failed to open file %s\n",argv[1]);
printf("Searching for \"%s\" opcode in %s\n\n",argv[2],argv[1]);
while(1)
{
bytesread = fread(buffer,1,1996,fd);
if(bytesread == 0)
break;
if(last == 1 && buffer[0]== code)
{
found = 1;
printf("Found \"%s\" opcode at offset 0x%.8X (0x%.8x)\n",
argv[2],(cnt-1),(cnt -1 + 0x08048000));
}
last = 0;
while(count < 1996)
{
if(buffer[count]==0xFF)
{
if(count == 1995)
last = 1;
if(buffer[count+1] == code)
{
found = 1;
printf("Found \"%s\" opcode at offset 0x%.8X
(0x%.8x)\n",argv[2],(count+cnt),(count + cnt + 0x08048000));
}
}
count ++;
}
count =0;
cnt = cnt + bytesread;
}
fclose(fd);
if(!found)
printf("Sorry...\"%s\" was not found.\n\n",argv[2]);
else
printf("\nFinished.\n\n");
return 0;
}

no es mas. Es posible que esto me sirva para el problemita?. Opinen ustedes...