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
Stack-based buffer overflow in the spiro_to_bpath0() function #21
Comments
|
Yes, you are correct, dm[5] = 1. would be a problem. Also noticed line 548 d[0] = 1.; d[1] = d[1] = 0.;needs to be fixed as: d[0] = 1.; d[1] = d[2] = 0.;@fcambus, can you do those two mods and try it again? |
|
This issue has been assigned CVE-2019-19847. |
|
@JoesCat Sure, will try your modifications when I come back home and report back. |
|
For clarification - the buffer overflow happens in the test programs, not the library itself. call-testN do progressive tests of the library, so it does some calls that aren't defined entrypoints in the developer H files - anyone that uses the libspiro H files shouldn't need to be playing around with these dm[6] variables. Thanks! - good catch - will look forwards to seeing a patch. |
|
Well, the buffer overflow happens in spiro_to_bpath0() which is a library function and an exported symbol: And you also define its prototype in spiro.h which is installed in PREFIX/include. But I understand it is called directly in the test suite for testing purposes but is not supposed to be called directly by library users. Your modifications indeed fix the crashes in the test suite, so you should commit that as a first step. As a second step, you should probably stop exporting this function. |
|
We should first make sure it's not being used, as it's likely been exported for years. I checked—it's not in use by FontForge. @JoesCat would know best as to other projects to check. |
|
Debian Code Search shows it is apparently only used in libspiro itself: https://codesearch.debian.net/search?q=spiro_to_bpath0&literal=1 |
|
Likewise, internet search for spiro_to_bpath0 also showed nothing except for the CVE-2019-19847. Most users that come to mind, use the "advertised" API entries, examples: I've verified Good catch. |
|
Thanks for the update, you can go ahead and commit your patch. |
Frederic Cambus (@fcambus) discovered a bug in call-test.c using: ./configure CFLAGS="-fsanitize=address" make ./tests/call-test[14,15,16,17,18,19] Fredrick Brennan (@ctrlcctrlv) provided bugfix. See issue #21
|
I worked on this a bit, and you have to copy the dm[] resulting values calculated in run_spiro0() and give them to the spiro_to_bpath0() - it can be internalized, but it would make the access points run_spiro0() and spiro_to_bpath0() of no value as you would not be able to scale or shift results. bugs patched. |
|
Released Libspiro, version 20200505 (1.1.0) |
Collective fixes from tagpoint v1.1 (20200505) up to v1.2 (20220722). "Need to Clean up Licensing" due to confusion as mentioned in issues: fontforge/fontforge#4077 #16 Thanks to orbea, bugfixes LIBADD for linker flags instead of LDFLAGS, and removed .libs from linker paths (these fixes help other linkers). Removed 'make test' and added some Maintenance info for 'make check'. Reduced the number of exported symbols as discussed earlier in issue: #21 bezctx_intf.h is now local instead of exported (the intf was a hint). Implemented in https://gcc.gnu.org/wiki/Visibility to reduce exports. Added more information into spiroentrypoints.h to help developers see expected return pass/fail values with exported functions/definitions. SPIRO_INTERNAL_BEZCTX and call-test21.c added for a simpler method of accessing libspiro for developers that only want the array of curves. Test added for 'a','h' to ensure points aren't overlapping else exit.
Hi,
When building libspiro 20190731 with AddressSanitizer enabled and running the test suite, I found a stack-based buffer overflow in spiro_to_bpath0() in spiro.c.
In the test suite,
call-test14tocall-test19all trigger the same issue.The issue can be triggered as follow:
The text was updated successfully, but these errors were encountered: