Opened 5 years ago

Closed 9 months ago

#644 closed defect (fixed)

buffer overflow with long exclude list

Reported by: vicgat Owned by: bruno
Priority: normal Milestone: 3.3.0
Component: mondo Version: 3.0.2
Severity: normal Keywords: mondoarchive buffer overflow
Cc:

Description

The exclude list is 2617 characters long, and a buffer overflow occurs at mondoarchive

Command in a shell-script

/usr/sbin/mondoarchive -O  -i -d /mnt/backup -N -E "`cat $EXCL_TMP`" -s 4480m -S $SCRATCH_DIR -T $SCRATCH_DIR -p `hostname`-`date +%Y-%m-%d`

backup log

---evalcall---1--- Calling MINDI to create boot+data disk
---evalcall---2--- TASK:  [*...................]   3% done;  2:09 to go
---evalcall---E---
*** buffer overflow detected ***: /usr/sbin/mondoarchive terminated
======= Backtrace: =========
/lib64/libc.so.6(__fortify_fail+0x37)[0x7fb70e90f877]
/lib64/libc.so.6(+0xe9510)[0x7fb70e90d510]
/lib64/libc.so.6(+0xe8809)[0x7fb70e90c809]
/lib64/libc.so.6(_IO_default_xsputn+0x85)[0x7fb70e897905]
/lib64/libc.so.6(_IO_vfprintf+0x34ba)[0x7fb70e86a3fa]
/lib64/libc.so.6(__vsprintf_chk+0x9d)[0x7fb70e90c8ad]
/lib64/libc.so.6(__sprintf_chk+0x80)[0x7fb70e90c7f0]
/usr/sbin/mondoarchive[0x420813]
/usr/sbin/mondoarchive[0x40cc2e]
/usr/sbin/mondoarchive[0x40dc56]
/usr/sbin/mondoarchive[0x403d77]
/lib64/libc.so.6(__libc_start_main+0xe6)[0x7fb70e842bc6]
/usr/sbin/mondoarchive[0x403089]

mondoarchive.log

    [Main] libmondo-archive.c->call_mindi_to_supply_boot_disks#918: mindi   --custom /depot_local/mondo.tmp.UgBjbI /depot_local/mondo.scratch.22514/mondo.scratch.27861/images '/boot/vmlinuz-2.6.32.54-0.3.1.4252.1.PTF-default' '' '0' 351154 'no' 'no' '' 'yes' 953 131 '/dev/mapper/mp_eva11_chu404_vgdb3arch_disk02|...|/dev/mapper/mp_eva11_chu404_vgsb3_disk2' 'yes' 'no' 'no' 32768 0 'no'
SIGABRT signal received from OS

The problem could be the one hereafter

In libmondo-archive.c, Line 922

    res = run_program_and_log_output(command, FALSE);

In libmondo-fork.c I think that is missing

char *command = NULL;

in the function run_program_and_log_output

int run_program_and_log_output(char *program, int debug_level)
{
    /*@ buffer ****************************************************** */
    char callstr[MAX_STR_LEN * 2];
    char incoming[MAX_STR_LEN * 2];
    char tmp[MAX_STR_LEN * 2];
    char initial_label[MAX_STR_LEN * 2];

For information, "char *command = NULL;" is defined in function "run_program_and_log_to_screen" :

int run_program_and_log_to_screen(char *basic_call, char *what_i_am_doing)
{
   ..........
    /*@ buffers **************************************************** */
    char *tmp = NULL;
    char *command = NULL;

I emailed logs and other informations directly to Bruno.

Change History (13)

comment:1 Changed 5 years ago by vicgat

I checked again. It's not the problem, as the "command" parameter is defined as "char *program" when run_program_and_log_output function is called.

Another track - in mondorescue file my-stuff.h

As the maximum length of almost all @p char buffers in Mondo defined to 512 :

#define MAX_STR_LEN 512

As the exclude list is 2617 characters long, and as most char arrays are defined as "char xxxxxxx[MAX_STR_LEN * 2]" we could redefine MAX_STR_LEN to :

#define MAX_STR_LEN 2048

comment:2 Changed 5 years ago by bruno

  • Status changed from new to assigned

I've always resisted to increase the MAX_STR_LEN to avoid consuming too much memory. Now, maybe it's time to consider it, seeing how much memory systems have nowadays.

The way I understand thee issue described, is that the call to mindi creates the issue here by passing too many chars to the command var called to launch mindi.

THis seems to be linked to the function run_program_and_log_output which has limitations in its string management. I have back ported code from 3.1 which deals with that, in order to see if that could help. Now in rev [3034]

Maybe we'll find another issue later on in another part due to the same cause, so that may be a iterative process.

Have you possibility to reproduce, and which package should I make for you to test (SLES or Ubuntu ?)

comment:3 Changed 5 years ago by bruno

  • Resolution set to fixed
  • Status changed from assigned to closed

Seems fixed in the latest beta of 3.0.3 as reported by Victor

comment:4 Changed 5 years ago by vicgat

  • Priority changed from high to normal
  • Resolution fixed deleted
  • Severity changed from major to normal
  • Status changed from closed to reopened

I tested rev 3053 on SLES 11 SP2.

I tested with an exclude list of 2623 characters, no buffer overflow.

With an exclude list of 5642 characters, I got a buffer overflow.

I email to Bruno the log file for exclude list of 5642 characters.

comment:5 Changed 5 years ago by bruno

  • Milestone changed from 3.0.3 to 3.1.0

I extended a value to support twice the size of the previous exclude list in rev [3062]. However, there is still a limit and when reached mondoarchive will crash.

The solution is in the backport of 3.1 code that solves this for good. Pushed to that version (or 3.2 for a clean tree)

comment:6 Changed 4 years ago by bruno

  • Milestone 3.1.0 deleted

Milestone 3.1.0 deleted

comment:7 Changed 3 years ago by bruno

  • Milestone set to 3.2.0

Should be addressed in 3.2.0 as a lot of fixed size strings have been removed (but not all yet)

comment:8 Changed 3 years ago by bruno

Well will be after 3.2.0 that I want to issue now ASAP. THere are still 2 fixed strings in mondo/src/common/libmondo-fork.c and one of them is the cause of this bug:

In run_program_and_log_output

char incoming[MAX_STR_LEN * 2];

Should be possible to fix in 3.2.1.

comment:9 Changed 3 years ago by bruno

  • Milestone changed from 3.2.0 to 3.2.1

comment:10 Changed 2 years ago by bruno

  • Milestone changed from 3.2.1 to 3.2.2

comment:11 Changed 18 months ago by bruno

  • Milestone changed from 3.2.2 to 3.2.3

comment:12 Changed 9 months ago by bruno

should be fixed with rev [3641]

comment:13 Changed 9 months ago by bruno

  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.