CVSS2
Attack Vector
NETWORK
Attack Complexity
MEDIUM
Authentication
NONE
Confidentiality Impact
PARTIAL
Integrity Impact
PARTIAL
Availability Impact
PARTIAL
AV:N/AC:M/Au:N/C:P/I:P/A:P
CVSS3
Attack Vector
LOCAL
Attack Complexity
LOW
Privileges Required
NONE
User Interaction
REQUIRED
Scope
UNCHANGED
Confidentiality Impact
HIGH
Integrity Impact
HIGH
Availability Impact
HIGH
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
EPSS
Percentile
57.4%
An exploitable integer overflow exists in the Image loading functionality of the Blender open-source 3d creation suite v2.78c. A specially crafted .blend file can cause an integer overflow resulting in a buffer overflow which can allow for code execution under the context of the application. An attacker can convince a user to open the file or use it as a library in order to trigger this vulnerability.
Blender v2.78c
<http://www.blender.org> <git://git.blender.org/blender.git>
8.8 - CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
CWE-190 - Integer Overflow or Wraparound
Blender is a professional, open-source 3d computer graphics application. It is used for creating animated films, visual effects, art, 3d printed applications, and video games. It is also capable of doing minimalistic video editing and sequencing as needed by the user. There are various features that it provides which allow for a user to perform a multitude of actions as required by a particular project.
This vulnerability exists with how the Blender application allocates space for an Image type when rendering a .blend file. When allocating space for the Image, the application will perform some arithmetic which can overflow. This result will then be used to perform an allocation which can allow for an undersized buffer. Later when the application attempts to render the image data into this buffer, a heap-based buffer overflow will occur.
Due to itβs flexibility, the .blend file format is capable of storing a vast number of data structures and is capable of completely serializing the state of the application to disk. This means that a data structure in C will have the exact same format as the version on disk. In the following file, the structure for an Image
record is described. This data structure is populated using data from the file.
source/blender/makesdna/DNA_image_types.h:99
typedef struct Image {
ID id;
char name[1024]; /* file path, 1024 = FILE_MAX */
...
int flag;
short source, type;
int lastframe;
...
int gen_x, gen_y;
char gen_type, gen_flag;
short gen_depth;
float gen_color[4];
...
} Image
When loading an Image record from a .blend file, the function BKE_image_acquire_ibuf
in the source/blender/blenkernel/intern/image.c
file will be called. This function will be passed two structures. One of which is the Image
record that was read from the file. The other of which is the ImageUser
record which is used to identify the image from either a Texture/Material, Background Image, or the Image Window. This function will call the image_acquire_ibuf
function at [1] in order to allocate space for it.
source/blender/blenkernel/intern/image.c:4086
ImBuf *BKE_image_acquire_ibuf(Image *ima, ImageUser *iuser, void **r_lock)
{
ImBuf *ibuf;
BLI_spin_lock(&image_spin);
ibuf = image_acquire_ibuf(ima, iuser, r_lock); / [1]
BLI_spin_unlock(&image_spin);
return ibuf;
}
Once inside the image_acquire_ibuf
functon, the application will first check a field named βokβ within the Image
and ImageUser
structures [2]. After this is done, the Image
structure will have itβs source
and type
fields checked. The provided proof-of-concept uses an image source
of IMA_SRC_GENERATED(4)
. This will cause the case at [3] to be used to handle the acquiring of the ImBuf
structure. Once the gen_x
, gen_y
, and gen_depth
fields are validated, the add_ibuf_size
function will be called [4]. It is prudent to note that at [5] another similar vulnerability can be found for the IMA_SRC_VIEWER(5)
image source. This will be discussed later.
source/blender/blenkernel/intern/image.c:3990
static ImBuf *image_acquire_ibuf(Image *ima, ImageUser *iuser, void **r_lock)
{
ImBuf *ibuf = NULL;
int frame = 0, index = 0;
if (r_lock)
*r_lock = NULL;
/* quick reject tests */
if (!image_quick_test(ima, iuser)) // [2]
return NULL;
...
if (ibuf == NULL) {
...
else if (ima->source == IMA_SRC_GENERATED) { // [3]
...
if (ima->gen_x == 0) ima->gen_x = 1024;
if (ima->gen_y == 0) ima->gen_y = 1024;
if (ima->gen_depth == 0) ima->gen_depth = 24;
ibuf = add_ibuf_size(ima->gen_x, ima->gen_y, ima->name, ima->gen_depth, (ima->gen_flag & IMA_GEN_FLOAT) != 0, ima->gen_type,
ima->gen_color, &ima->colorspace_settings); // [4]
image_assign_ibuf(ima, ibuf, index, 0);
ima->ok = IMA_OK_LOADED;
}
else if (ima->source == IMA_SRC_VIEWER) { // [5]
if (ima->type == IMA_TYPE_R_RESULT) {
...
ibuf = image_get_render_result(ima, iuser, r_lock);
}
...
}
The add_ibuf_size
function will then take the width
and height
fields that came from Image.gen_x
and Image.gen_y
and then pass them to the IMB_allocImBuf
function at [6]. This function will take the product of these fields and the size of an unsigned int
(4) and use them to calculate the size of a heap-buffer. If the result of this is larger than 32-bits, then an integer overflow will occur. This can result in an undersized buffer that when written to will cause a heap-based buffer overflow. At [7], the application will then write data into this buffer.
source/blender/blenkernel/intern/image.c:632
static ImBuf *add_ibuf_size(unsigned int width, unsigned int height, const char *name, int depth, int floatbuf, short gen_type,
const float color[4], ColorManagedColorspaceSettings *colorspace_settings)
{
ImBuf *ibuf;
unsigned char *rect = NULL;
float *rect_float = NULL;
if (floatbuf) {
ibuf = IMB_allocImBuf(width, height, depth, IB_rectfloat); // [6] Image.gen_flag & IMA_GEN_FLOAT(1)
...
}
else {
ibuf = IMB_allocImBuf(width, height, depth, IB_rect); // [6] Image.gen_flag & ~IMA_GEN_FLOAT(1)
...
}
...
switch (gen_type) {
case IMA_GENTYPE_GRID:
BKE_image_buf_fill_checker(rect, rect_float, width, height); // [7]
break;
case IMA_GENTYPE_GRID_COLOR:
BKE_image_buf_fill_checker_color(rect, rect_float, width, height); // [7]
break;
default:
BKE_image_buf_fill_color(rect, rect_float, width, height, color); // [7] Used by provided proof-of-concept
break;
}
return ibuf;
}
Each of the functions at [7] will then be used to populate the undersized buffer. At [8], the application will hand off initialization of the buffer to a thread. This will wrap a call to image_buf_fill_color_slice
at [9] and then later one of the loops at [10] will be used to write into the buffer. The proof-of-concept that is included chooses the non-rect_float
loop to overflow the buffer.
source/blender/blenkernel/intern/image_gen.c:97
void BKE_image_buf_fill_color(unsigned char *rect,
float *rect_float,
int width, int height,
const float color[4])
{
if (((size_t)width) * height < 64 * 64) {
...
}
else {
FillColorThreadData data;
data.rect = rect;
data.rect_float = rect_float;
data.width = width;
copy_v4_v4(data.color, color);
IMB_processor_apply_threaded_scanlines(
height, image_buf_fill_color_thread_do, &data); // [8] \
}
}
\
source/blender/blenkernel/intern/image_gen.c:82
static void image_buf_fill_color_thread_do(void *data_v,
int start_scanline,
int num_scanlines)
{
...
image_buf_fill_color_slice(rect,
rect_float,
data->width,
num_scanlines,
data->color); // [9] \
}
\
source/blender/blenkernel/intern/image_gen.c:48
static void image_buf_fill_color_slice(unsigned char *rect,
float *rect_float,
int width, int height,
const float color[4])
{
int x, y;
/* blank image */
if (rect_float) {
float linear_color[4];
srgb_to_linearrgb_v4(linear_color, color);
for (y = 0; y < height; y++) { // [10]
for (x = 0; x < width; x++) {
copy_v4_v4(rect_float, linear_color);
rect_float += 4;
}
}
}
if (rect) {
unsigned char ccol[4];
rgba_float_to_uchar(ccol, color);
for (y = 0; y < height; y++) { // [10] Loop chosen by proof-of-concept
for (x = 0; x < width; x++) {
rect[0] = ccol[0];
rect[1] = ccol[1];
rect[2] = ccol[2];
rect[3] = ccol[3];
rect += 4;
}
}
}
}
There is a path to similar bug if the Image.source
field is IMA_SRC_VIEWER(5)
and the Image.type
field is set to IMA_TYPE_R_RESULT(4)
. At [11], the image_get_render_result
function will get called. After selecting the Image.render_slot
index of the Image.renders
array at [12], the application will use the RenderResult.rectx
and RenderResult.recty
fields to allocate an ImBuf
at [13]. Immediately afterwards, the application will assign the Image to the undersized buffer. This will also cause a heap-based buffer overflow.
source/blender/blenkernel/intern/image.c:4041
else if (ima->source == IMA_SRC_VIEWER) { // [5]
if (ima->type == IMA_TYPE_R_RESULT) {
/* always verify entirely, and potentially
* returns pointer to release later */
ibuf = image_get_render_result(ima, iuser, r_lock); // [11] \
}
\
source/blender/blenkernel/intern/image.c:3666
static ImBuf *image_get_render_result(Image *ima, ImageUser *iuser, void **r_lock)
{
...
RenderResult rres;
...
if (from_render) {
RE_AcquireResultImage(re, &rres, actview);
}
else if (ima->renders[ima->render_slot]) { // [12]
rres = *(ima->renders[ima->render_slot]);
rres.have_combined = ((RenderView *)rres.views.first)->rectf != NULL;
}
...
if (ibuf == NULL) {
ibuf = IMB_allocImBuf(rres.rectx, rres.recty, 32, 0); // [13]
image_assign_ibuf(ima, ibuf, IMA_NO_INDEX, 0);
}
The structure for the RenderResult
is located within the source/blender/render/extern/include/RE_pipeline.h
function. The rectx
and recty
fields are multiplied with the size of an unsigned int
in order to calculate the size for the target buffer for the second bug.
source/blender/render/extern/include/RE_pipeline.h:137
typedef struct RenderResult {
struct RenderResult *next, *prev;
/* target image size */
int rectx, recty;
short crop, sample_nr;
/* the following rect32, rectf and rectz buffers are for temporary storage only, for RenderResult structs
* created in #RE_AcquireResultImage - which do not have RenderView */
/* optional, 32 bits version of picture, used for ogl render and image curves */
int *rect32;
/* if this exists, a copy of one of layers, or result of composited layers */
float *rectf;
/* if this exists, a copy of one of layers, or result of composited layers */
float *rectz;
...
} RenderResult;
(1ddc.b58): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000000 ebx=00000003 ecx=00003c01 edx=03ed0000 esi=1e211000 edi=00004000
eip=00b23bc6 esp=305bfacc ebp=305bfaec iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202
blender!PyInit_mathutils_noise_types+0x2e5146:
00b23bc6 8806 mov byte ptr [esi],al ds:002b:1e211000=??
Included with this advisory is a generator for the vulnerability. This proof-of-concept requires python and takes a single-argument which is the filename to write the .blend file to.
$ python poc.py $FILENAME.blend
To trigger the vulnerability with the provided proof-of-concept, one can simply add it as a library and attempt to use the Image. Another way is to open the file and navigate to the DataBlocks view.
$ /path/to/blender.exe $FILENAME.blend
To automate triggering the vulnerability without user-interaction, apply the Image to a Texture and then include the texture in a Scene.
In order to mitigate this vulnerability, it is recommended to not open a .blend file or use a .blend file as a library from an untrusted user.
2017-09-06 - Vendor Disclosure
2018-01-11 - Public Release
CVSS2
Attack Vector
NETWORK
Attack Complexity
MEDIUM
Authentication
NONE
Confidentiality Impact
PARTIAL
Integrity Impact
PARTIAL
Availability Impact
PARTIAL
AV:N/AC:M/Au:N/C:P/I:P/A:P
CVSS3
Attack Vector
LOCAL
Attack Complexity
LOW
Privileges Required
NONE
User Interaction
REQUIRED
Scope
UNCHANGED
Confidentiality Impact
HIGH
Integrity Impact
HIGH
Availability Impact
HIGH
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
EPSS
Percentile
57.4%