-
Notifications
You must be signed in to change notification settings - Fork 390
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Heap buffer overflows in psf_binheader_writef in 1.0.28 and later
#292
Comments
…ader
Fixes the following problems:
1. Case 's' only enlarges the buffer by 16 bytes instead of size bytes.
2. psf_binheader_writef() enlarges the header buffer (if needed) prior to the
big switch statement by an amount (16 bytes) which is enough for all cases
where only a single value gets added. Cases 's', 'S', 'p' however
additionally write an arbitrary length block of data and again enlarge the
buffer to the required amount. However, the required space calculation does
not take into account the size of the length field which gets output before
the data.
3. Buffer size requirement calculation in case 'S' does not account for the
padding byte ("size += (size & 1) ;" happens after the calculation which
uses "size").
4. Case 'S' can overrun the header buffer by 1 byte when no padding is
involved
("memcpy (&(psf->header.ptr [psf->header.indx]), strptr, size + 1) ;" while
the buffer is only guaranteed to have "size" space available).
5. "psf->header.ptr [psf->header.indx] = 0 ;" in case 'S' always writes 1 byte
beyond the space which is guaranteed to be allocated in the header buffer.
6. Case 's' can overrun the provided source string by 1 byte if padding is
involved ("memcpy (&(psf->header.ptr [psf->header.indx]), strptr, size) ;"
where "size" is "strlen (strptr) + 1" (which includes the 0 terminator,
plus optionally another 1 which is padding and not guaranteed to be
readable via the source string pointer).
Closes: libsndfile#292
…ader
Fixes the following problems:
1. Case 's' only enlarges the buffer by 16 bytes instead of size bytes.
2. psf_binheader_writef() enlarges the header buffer (if needed) prior to the
big switch statement by an amount (16 bytes) which is enough for all cases
where only a single value gets added. Cases 's', 'S', 'p' however
additionally write an arbitrary length block of data and again enlarge the
buffer to the required amount. However, the required space calculation does
not take into account the size of the length field which gets output before
the data.
3. Buffer size requirement calculation in case 'S' does not account for the
padding byte ("size += (size & 1) ;" happens after the calculation which
uses "size").
4. Case 'S' can overrun the header buffer by 1 byte when no padding is
involved
("memcpy (&(psf->header.ptr [psf->header.indx]), strptr, size + 1) ;" while
the buffer is only guaranteed to have "size" space available).
5. "psf->header.ptr [psf->header.indx] = 0 ;" in case 'S' always writes 1 byte
beyond the space which is guaranteed to be allocated in the header buffer.
6. Case 's' can overrun the provided source string by 1 byte if padding is
involved ("memcpy (&(psf->header.ptr [psf->header.indx]), strptr, size) ;"
where "size" is "strlen (strptr) + 1" (which includes the 0 terminator,
plus optionally another 1 which is padding and not guaranteed to be
readable via the source string pointer).
Closes: #292
|
Hi @erikd |
|
I have not requested one. No idea if anyone else has. |
|
I did not request a CVE either. |
|
O.k., I've asked for a CVE now |
|
Thanks for requesting the CVE. @erikd Any chance to get a minor release with this fix? |
|
I'll try to do one this weekend. |
|
Not wanting to be nosy, but AFAICT that minor release didn't happen, right? Any chance to get one? |
|
[poking noises] anybody alive in here? A release with this bugfix would be pretty sweet… |
's'only enlarges the buffer by16bytes instead ofsizebytes.This issue had originally reported by funute against openmpt123 (see https://bugs.openmpt.org/view.php?id=974 ). openmpt123 uses libsndfile to write WAV files and can output large amounts of string data in the
SF_STR_COMMENTmetadata field.Valgrind stacktrace (libsndfile 1.0.28):
Test case in bug1.c (tested on Ubuntu 14.04 x86-64 with libsndfile 1.0.28):
psf_binheader_writefinsrc/common.cenlarges the header buffer (if needed) prior to the big switch statement by an amount (16 bytes) which is enough for all cases where only a single value gets added. Cases's','S','p'however additionally write an arbitrary length block of data and again enlarge the buffer to the required amount. However, the required space calculation does not take into account the size of the length field which gets output before the data.Test case bug2.c (tested on Ubuntu 14.04 x86-64 with libsndfile 1.0.28 with
16replaced bysizein the buffer size calculation):Buffer size requirement calculation in case
'S'does not account for the padding byte (size += (size & 1) ;happens after the calculation which usessize).Case
'S'can overrun the header buffer by 1 byte when no padding is involved (memcpy (&(psf->header.ptr [psf->header.indx]), strptr, size + 1) ;while the buffer is only guaranteed to havesizespace available).psf->header.ptr [psf->header.indx] = 0 ;in case'S'always writes 1 byte beyond the space which is guaranteed to be allocated in the header buffer.Case
's'can overrun the provided source string by 1 byte if padding is involved (memcpy (&(psf->header.ptr [psf->header.indx]), strptr, size) ;wheresizeisstrlen (strptr) + 1(which includes the 0 terminator, plus optionally another1which is padding and not guaranteed to be readable via the source string pointer).I have not yet invested the time to provide reproducable tests for 3, 4, 5, 6:
INITAL_HEADER_SIZEconstant and/or a growing factor other than2). I would consider the current code to at least be fragile nonetheless.psf->strings.storage) which makes it impossible for memory checkers to detect buffer overruns inside that buffer.Pull request with fixes will follow.
The text was updated successfully, but these errors were encountered: