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
Use-after-free (heap) in the SFD_GetFontMetaData() function #4084
Comments
|
This issue has been assigned CVE-2020-5395. |
|
Is there any plan to address this & #4085 ? |
|
I have no plans to work on this, but someone else might do so. See #4086 (comment) for some reasoning |
|
@ctrlcctrlv Do you plan to contact MITRE to get this CVE disputed ?
|
|
Sorry, I don't understand. What is there to dispute? What analysis has been made? |
@ctrlcctrlv |
|
It's vulnerable. I have no interest in fixing it, I think doing so would be a misallocation of resources. What I choose to spend my time on doesn't bind any other developer, but it doesn't bode well either because there are only so many of us, and probably others agree with me about how to allocate their time. |
Thank you for your explanation and patience ! |
|
@NicoleG25 Just to summarize the explanation @ctrlcctrlv referred to in a somewhat different way: The primary three ways that software systems present security vulnerabilities, given problems like those reported in those issues (buffer overflows, wild pointers, etc.) are:
Without some connection like this a segfault is "just a segfault" -- it doesn't present a security risk. A user gains nothing by tricking FontForge (for example) into executing carefully constructed instructions because FontForge doesn't run with elevated privileges. And FontForge does present any network interfaces (at least since the collaboration system was removed). So any viable vulnerabilities would have be in the form of a carefully constructed font file, which would exploit a buffer overflow or wild pointer to do something when loaded. This scenario is possible but very improbable. The main problem facing the hacker is that FontForge users tend to either develop their own fonts or open specific existing fonts for reasons very specific to them. The other problem is that FontForge is cross-platform and the file would have to be constructed to work on the specific OS of the targeted user. Having said all this, I fixed a bunch of these small issues before the last release and I may fix some or all of these. |
…ta() function Fix for fontforge#4086 NULL pointer dereference in the SFDGetSpiros() function Fix for fontforge#4088 NULL pointer dereference in the SFD_AssignLookups() function Add empty sf->fontname string if it isn't set, fixing fontforge#4089 fontforge#4090 and many other potential issues (many downstream calls to strlen() on the value).
These CVEs have two different issues being tagged as 'Exploit'. CVE-2020-5395 [0]: fontforge/fontforge#4084 CVE-2020-5496 [1]: fontforge/fontforge#4085 Both issues refer to [2] as a fix, so I guess this patch fixes it. [0] https://nvd.nist.gov/vuln/detail/CVE-2020-5395 [1] https://nvd.nist.gov/vuln/detail/CVE-2020-5496 [2] fontforge/fontforge@048a91e
…ta() function Fix for fontforge#4086 NULL pointer dereference in the SFDGetSpiros() function Fix for fontforge#4088 NULL pointer dereference in the SFD_AssignLookups() function Add empty sf->fontname string if it isn't set, fixing fontforge#4089 fontforge#4090 and many other potential issues (many downstream calls to strlen() on the value).
Hi,
While fuzzing FontForge with AFL, I found a heap use-after-free in the SFD_GetFontMetaData() function, in sfd.c.
Attaching a reproducer (gzipped so GitHub accepts it): test01.sfd.gz
Issue can be reproduced in FontForge 20190801 and with latest Git master by running:
The text was updated successfully, but these errors were encountered: