exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

raydiumx.txt

raydiumx.txt
Posted May 21, 2006
Authored by Luigi Auriemma | Site aluigi.org

Raydium versions SVN revision 309 and below suffer from buffer overflows, format string, and invalid memory access flaws.

tags | advisory, overflow
SHA-256 | fc9789d4dc2d01d1185c7f66a6bc4d376dca0cead895a512d0357225e4bf792c

raydiumx.txt

Change Mirror Download

#######################################################################

Luigi Auriemma

Application: Raydium
http://raydium.org
Versions: <= SVN revision 309
(newer versions can be vulnerable to some of the bugs
which are still unfixed)
Platforms: Windows, *nix, *BSD and others
Bugs: A] buffer-overflow in raydium_log and
raydium_console_line_add
B] format string in raydium_log
C] NULL function pointer in raydium_network_netcall_exec
D] buffer-overflow and invalid memory access in
raydium_network_read
Exploitation: A] remote, versus server and client
B] remote, versus server and client
C] remote, versus server and client
D] remote, versus client
Date: 12 Maj 2006
Author: Luigi Auriemma
e-mail: aluigi@autistici.org
web: aluigi.org


#######################################################################


1) Introduction
2) Bugs
3) The Code
4) Fix


#######################################################################

===============
1) Introduction
===============


Raydium is a complete open source game engine with multiplayer support
and many other important and interesting features.


#######################################################################

=======
2) Bugs
=======

--------------------------------------------------------------
A] buffer-overflow in raydium_log and raydium_console_line_add
--------------------------------------------------------------

The logging function of Raydium is very used in all the engine.
For example everytime a client tries to join the server it logs the
event in the console:

raydium_log("network: client %i connected as %s"/*,inet_ntoa(from->sin_addr)*/,n,name);

This useful function is affected by a buffer-overflow bug where the
local buffer str of 255 (RAYDIUM_MAX_NAME_LEN) bytes is filled using
the unsecure sprintf function.
The size of the input packet is 512 (RAYDIUM_NETWORK_PACKET_SIZE)
bytes of which 508 are available for the text to use for exploiting the
vulnerability.

From raydium/log.c:

// need to be secured
void raydium_log(char *format, ...)
{
char str[RAYDIUM_MAX_NAME_LEN];
va_list argptr;


va_start(argptr,format);
vsprintf(str,format,argptr);
va_end(argptr);

printf("Raydium: %s\n",str);
if(raydium_log_file) fprintf(raydium_log_file,"%s\n",str);
raydium_console_line_add(str);
}


Similar thing for raydium_console_line_add:

From raydium/console.c:

// need to secure this one too
void raydium_console_line_add(char *format, ...)
{
char str[RAYDIUM_MAX_NAME_LEN];
va_list argptr;
va_start(argptr,format);
vsprintf(str,format,argptr);
va_end(argptr);

raydium_console_line_last++;
if(raydium_console_line_last>=RAYDIUM_CONSOLE_MAX_LINES)
raydium_console_line_last=0;

strcpy(raydium_console_lines[raydium_console_line_last],str);
}


-------------------------------
B] format string in raydium_log
-------------------------------

The same raydium_log function described above is affected also by a
format string vulnerability caused by the calling of
raydium_console_line_add passing directly the text string without the
required format argument:

raydium_console_line_add(str);


--------------------------------------------------------
C] NULL function pointer in raydium_network_netcall_exec
--------------------------------------------------------

The function raydium_network_netcall_exec is called by
raydium_network_read for selecting the specific function to use for
handling the type of packet received.
The raydium_network_netcall_type array is initialized with the type -1
so if the attacker uses the type 0xff the function will try to call
raydium_network_netcall_func which is still initialized with a NULL
pointer.
The effect is the crash of the program.

>From raydium/network.c:

...
for(i=0;i<RAYDIUM_NETWORK_MAX_NETCALLS;i++)
{
raydium_network_netcall_type[i]=-1;
raydium_network_netcall_func[i]=0;
raydium_network_netcall_tcp[i]=0;
}
...

void raydium_network_netcall_exec(int type,char *buff)
{
char tmpbuff[RAYDIUM_NETWORK_PACKET_SIZE];
int i;
void (*f)(int, char*);

for(i=0;i<RAYDIUM_NETWORK_MAX_NETCALLS;i++)
if(raydium_network_netcall_type[i]==type)
{
memcpy(tmpbuff,buff,RAYDIUM_NETWORK_PACKET_SIZE);
f=raydium_network_netcall_func[i];
f(type,tmpbuff);
}
}


--------------------------------------------------------------------
D] buffer-overflow and invalid memory access in raydium_network_read
--------------------------------------------------------------------

The function raydium_network_read is affectd by some buffer-overflow
bugs which happen during the writing of some global variables
allocated in an array of 32 (RAYDIUM_NETWORK_MAX_SERVERS) elements.
The same function is also affected by an invalid memory access could
happen when the server sends a packet to the client containing an 8
bit id bigger than 8 (RAYDIUM_NETWORK_MAX_CLIENTS).
Both the bugs can be exploited only versus the clients.

>From raydium/network.c:

signed char raydium_network_read(int *id, signed char *type, char *buff)
...
strcpy(raydium_network_server_list[slot].name,name);
...
strcpy(raydium_network_server_list[slot].info,info);
...
i=buff[RAYDIUM_NETWORK_PACKET_OFFSET];
strcpy(raydium_network_name[i],buff+RAYDIUM_NETWORK_PACKET_OFFSET+1);
...


#######################################################################

===========
3) The Code
===========


http://aluigi.org/poc/raydiumx.zip


#######################################################################

======
4) Fix
======


Some of the bugs have been fixed in the current SVN and the others will
be fixed soon.


#######################################################################


---
Luigi Auriemma
http://aluigi.org
http://mirror.aluigi.org
Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    0 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close