Skip to content
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

3 bugs for #1

Open
ghost opened this issue Nov 16, 2017 · 3 comments
Open

3 bugs for #1

ghost opened this issue Nov 16, 2017 · 3 comments

Comments

@ghost
Copy link

ghost commented Nov 16, 2017

No description provided.

@ghost
Copy link
Author

ghost commented Nov 16, 2017

3 bugsfor libbpg. I send these bugs to author and request 3 CVEs. Here are the details of them.

bug 1

NULL Pointer Dereference in libbpg 0.9.7 and older versions allows attackers to DoS the image analyse server.
/x265/source/common/cudata.cpp#CUData::initialize(L198)
/*
uint8_t charBuf = dataPool.charMemBlock + (m_numPartitions * BytesPerPartition) * instance;
m_qp = (int8_t
)charBuf; charBuf += m_numPartitions;
*/ here the parameter charBuf can be NULL because when CHECKED_MALLOC failed, so dataPool.charMemBlock will be
NULL, then m_qp will be NULL. And in line 246, the m_partSet will use m_qp, which is NULL. This causes a NULL pointer use.
to exploit, someone must open a crafted bpg file https://drive.google.com/open?id=0B4aWmtdznlVKMnBqYjBlY2ZhNkk

bug 2:

Integer Overflow in libbpg 0.9.7 and older versions allows attackers to malloc a abnormal space.
bpgenc.c#image_alloc(L717)
/*
img->data[i] = malloc(linesize * h1);
*/
This is an integer overflow. Here the linesize * h1 can result a
really big number, and then movsx makes it a negative number. So,
malloc will return NULL; img->data[0] will be a NULL pointer.
to exploit, someone must open a crafted bpg file https://drive.google.com/open?id=0B4aWmtdznlVKSVlGdE5jazhGWW8

bug 3:

It's an heap-buffer-overflow vuln.
vuln_ASAN:https://drive.google.com/open?id=0B4aWmtdznlVKSWIzZFJXQ3RRVEU
vuln_location:https://drive.google.com/open?id=0B4aWmtdznlVKb3hlcFhoZ19VcTQ

the heap overflow is in the memcpy of restore_tqb_pixels function
the dst address of memcpy is

dst1 + (((y - y0) << s->sps->log2_min_pu_size) >> vshift) * stride_dst + ((((x - x0) << s->sps->log2_min_pu_size) >> hshift) << s->sps->pixel_shift);

When sao_filter_CTB calls restore_tqb_pixels, dst1 will be

uint8_t *dst = s->sao_pixel_buffer + (1 * stride_dst) + (1 << s->sps->pixel_shift);

y is a minimum of ((y0) >> s->sps->log2_min_pu_size); In this poc, the value of s->sps->log2_min_pu_size is 2.
so y-y0=-y0/2 , x-x0 are negative. and the dst of memcpy is smaller than s->sao_pixel_buffer, so it
overflowed the data before s->sao_pixel_buffer, thus it received a SIGSEGV.
to exploit vulnerability, someone must open a crafted BPG file: https://drive.google.com/open?id=0B4aWmtdznlVKYkRhUlhKNGxiWGc

@ghost
Copy link
Author

ghost commented Nov 16, 2017

for libbpg

@galaktipus
Copy link

Is there any fix regarding that issue? (CVE-2017-13136)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant