Bug 11383 - rsync_panic_handler may execute incomplete command
Summary: rsync_panic_handler may execute incomplete command
Status: NEW
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.1.1
Hardware: All Linux
: P5 normal (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-04 07:57 UTC by Brant Gurganus
Modified: 2015-07-04 07:57 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brant Gurganus 2015-07-04 07:57:40 UTC
The rsync_panic_handler currently defined at line 1490 of main.c writes into a fixed size cmd_buf at line 1492 a non-controlled value returned ultimately in get_panic_action() using snprintf at line 1495. The combined values destined for cmd_buf by way of snprintf may be greater than the 300 character buffer. This is not checked. Consequently, a command may attempt to execute that was not intended.

To address this specific issue, if the snprintf function returns a value greater than or equal to the size of cmd_buf, cmd_buf either needs enlarged or some informative action should occur. It should not take the current path of executing an incomplete command. The glibc manual suggests calling asprintf instead of snprintf to dynamically allocate sufficient space for cmd_buf though dynamic memory allocation is a possible failure point which may not be the best for this code path for signal handling.

I believe there may be some issues as well in that the result of get_panic_action is not validated for its usage, and I believe the printf family of functions can do non-failing information disclosure sorts of behaviors if there are more format parameters than passed in. There is a parse_printf_format function in glibc at least that could be used to validate the format matches the inputs given to it instead of possibly leaking stack values occurring after the arguments to snprintf.