On Thu, Jun 30, 2011 at 9:09 AM, Glenn Adams <glenn@skynav.com> wrote: > There is no mechanism to allow script content to access font data, even by > inference (as was used in the image theft example you cite). Further, unlike > JS or OpenGL Shader code, fonts do not employ a user defined, turing > complete language. I admit it can be effectively argued that TTF 'mort' and > 'morx' tables define FSMs, and that a malicious font could be constructed > that would put the FSM into a loop, thus potentially creating a DoS risk. > Actually, the same applies to OTF 'gsub' and 'gpos', which, due to the > chaining mechanism, could also be exploited to create a circular chaining > loop. > > However, these risks are present independently of origin processing. Other > than these risks, the only use I can see for same origin in regards to fonts > is the protection of font owner IPR, which is clearly in the domain of > content protection (CP). > > I may be missing something here, but I have seen it said here that SO on > fonts helps protect end users. But all I see is very weak CP for font > owners. Please explain the security risk for CO fonts on end users. > >From the font side of the fence, over the years I have seen what most folks would consider a surprising number of things arise in terms of security issues around fonts, of a wide range of types, from multiple kinds of DOS attacks to enabling fraud. The potential for fonts to cause problems is often understated. Some of these issues have not been widely publicized, but rather quietly fixed or worked around by the vendors in question. Cheers, T
Received on Thursday, 30 June 2011 21:37:45 UTC