Re: [ft] FreeType 2.4.1 has been released
BTW, VUPEN lists two vulnerabilities, but FreeType2 mentions a vulnerability. Somebody may afraid that another vulnerability is left in genuine FreeType2. This is the difference of the modification part in Apple's patch our patch. In Apple's patch, 2 stack checking are inserted to 2 CFF operators increasing the stack. In our patch, a stack checking is inserted after all CFF operations, aslike existing stack checking for CFF numerical objects. Frankly, that makes the most sense. Technote 5177 on Type2 charstrings rather explicitly states the maximum allowed sizes for various aspects of charstring parsing, pretty plainly stating that the normal argument stack has max size 48, and the transient stack (for opcode programs) max size 32, so a push onto the stack should always be conditional on whether or not it's already full... wonder why Apple decided to completely ignore that fact... - Mike ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] FreeType 2.4.1 has been released
On Fri, 06 Aug 2010 22:49:20 +0200 (CEST) Werner LEMBERG w...@gnu.org wrote: out of curiosity, has Apple contacted the FreeType dev group concerning http://www.vupen.com/english/advisories/2010/2018 (FreeType Compact Font Format Two Buffer Overflow Vulnerabilities)? Yes. Fixed in 2.4.2. Unfortunately, at least, Werner and me had not heard anything from Apple (there is a possibility that we had overlooked their contact in the spam messages). We had found the mention of CFF driver vulnerability (used to crack iOS) in some web sites, and we had fixed by ourselves. It seems that RedHat got the patch written by Apple engineers, before our fix, so I guess it was just that Apple didn't find appropriate contact in FreeType2 developers. BTW, VUPEN lists two vulnerabilities, but FreeType2 mentions a vulnerability. Somebody may afraid that another vulnerability is left in genuine FreeType2. This is the difference of the modification part in Apple's patch our patch. In Apple's patch, 2 stack checking are inserted to 2 CFF operators increasing the stack. In our patch, a stack checking is inserted after all CFF operations, aslike existing stack checking for CFF numerical objects. Regards, mpsuzuki ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] FreeType 2.4.1 has been released
out of curiosity, has Apple contacted the FreeType dev group concerning http://www.vupen.com/english/advisories/2010/2018 (FreeType Compact Font Format Two Buffer Overflow Vulnerabilities)? Yes. Fixed in 2.4.2. Unfortunately, at least, Werner and me had not heard anything from Apple (there is a possibility that we had overlooked their contact in the spam messages). This is not correct. Apple has contacted me privately. And indeed, I considered their mails as spam inadvertently, so they've fixed it in a slightly different way. Werner ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] FreeType 2.4.1 has been released
out of curiosity, has Apple contacted the FreeType dev group concerning http://www.vupen.com/english/advisories/2010/2018 (FreeType Compact Font Format Two Buffer Overflow Vulnerabilities)? Yes. Fixed in 2.4.2. Even if it's not a serious problem on anything that isn't iOS, It is a serious problem on all platforms. a problem with opcode parsing might also lead to the incorrect execution of opcode-based CFF glyph rendering; it would be nice to know where it's going wrong, so that normal fonts (i.e., not created specifically to exploit the problem) that make use of the problematic opcode patterns can be identified. Normal fonts will *never* encounter this particular bug. It relies on opcodes which push data on the stack without consuming arguments, for example, repeatedly calling `random'. Werner ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
