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

NULL pointer dereference in outputSWF_TEXT_RECORD #101

Closed
gy741 opened this issue Jan 12, 2018 · 4 comments
Closed

NULL pointer dereference in outputSWF_TEXT_RECORD #101

gy741 opened this issue Jan 12, 2018 · 4 comments

Comments

@gy741
Copy link

gy741 commented Jan 12, 2018

Hello.

I found a NULL pointer dereference in libming.

Please confirm.

Thanks.

Summary: NULL pointer dereference
OS: CentOS 7 64bit
Version: 1df8bc2
PoC Download: null_outputSWF_TEXT_RECORD.zip

Steps to reproduce:
1.Download the .POC files.
2.Compile the source code with ASan.
3.Execute the following command
: swftocxx $FILE out

=================================================================
==22600==ERROR: AddressSanitizer: SEGV on unknown address 0x602fc0c0c130 (pc 0x000000520a76 bp 0x60400000005e sp 0x7fff09aefbd0 T0)
==22600==The signal is caused by a READ memory access.
    #0 0x520a75 in outputSWF_TEXT_RECORD /home/karas/libming/util/outputscript.c:1444:17
    #1 0x5200b8 in outputSWF_DEFINETEXT /home/karas/libming/util/outputscript.c:1475:6
    #2 0x51fd37 in outputBlock /home/karas/libming/util/outputscript.c:2083:4
    #3 0x526c9e in readMovie /home/karas/libming/util/main.c:286:4
    #4 0x526c9e in main /home/karas/libming/util/main.c:359
    #5 0x7f4833409c04 in __libc_start_main (/lib64/libc.so.6+0x21c04)
    #6 0x41b0ab in _start (/home/karas/libming/run/bin/swftocxx+0x41b0ab)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /home/karas/libming/util/outputscript.c:1444:17 in outputSWF_TEXT_RECORD
==22600==ABORTING

==========
[Acknowledgement]
This work was supported by ICT R&D program of MSIP/IITP. [R7518-16-1001, Innovation hub for high Performance Computing]

@hlef
Copy link
Contributor

hlef commented Jan 17, 2018

Reproducible on latest master. Please ask for CVE number, I'll prepare a patch for this issue.

@hlef
Copy link
Contributor

hlef commented Jan 18, 2018

Well, the first issue here is that the array offset is being stored in a signed int, while (&(trec->GlyphEntries[i]))->GlyphIndex[0] returns an unsigned 32 bit number (see line 1442).

This may lead to integer overflows in two cases:

  1. The glyph index is bigger than INT_MAX
  2. int is 16 bit (not very common though, but we should not rely on it)

In the case of an integer overflow, off gets negative, so we pass the guard off<fi->fontcodearrsizeand execute buffer[i]=fi->fontcodeptr[off] which leads to out of bounds read.

I propose to change the type of off to unsigned long so we are guaranteed to be able to handle 32 unsigned integers. This should fix the issue. I'll test it and submit a PR.

@hlef
Copy link
Contributor

hlef commented Jan 25, 2018

Okay, I'll request a CVE number.

@hlef
Copy link
Contributor

hlef commented Jan 26, 2018

FTR, this issue has been assigned number CVE-2018-6315.

hlef added a commit to hlef/libming that referenced this issue Jan 26, 2018
In outputSWF_TEXT_RECORD, the array offset is stored in a
signed int, while (&(trec->GlyphEntries[i]))->GlyphIndex[0]
returns an unsigned 32 bit number.

This may lead to an integer overflow when reading the offset
from the GlyphIndex array, and further to a buffer overflow
when doing buffer[i]=fi->fontcodeptr[off] with negative off.

In this commit, we change the type of off to unsigned long so
we are guaranteed to be able to store 32 unsigned integers.

This commit fixes CVE-2018-6315 (fixes libming#101).
@strk strk closed this as completed in 3120f1c Jan 27, 2018
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

Successfully merging a pull request may close this issue.

2 participants