The cache files are insufficiently validated. Even though the magic
number at the beginning of the file as well as time stamps are checked,
it is not verified if contained offsets are in legal ranges or are
even pointers.
The lack of validation allows an attacker to trigger arbitrary free()
calls, which in turn allows double free attacks and therefore arbitrary
code execution. Due to the conversion from offsets into pointers through
macros, this even allows to circumvent ASLR protections.
This attack vector allows privilege escalation when used with setuid
binaries like fbterm. A user can create ~/.fonts or any other
system-defined user-private font directory, run fc-cache and adjust
cache files in ~/.cache/fontconfig. The execution of setuid binaries will
scan these files and therefore are prone to attacks.
If it's not about code execution, an endless loop can be created by
letting linked lists become circular linked lists.
This patch verifies that:
- The file is not larger than the maximum addressable space, which
basically only affects 32 bit systems. This allows out of boundary
access into unallocated memory.
- Offsets are always positive or zero
- Offsets do not point outside file boundaries
- No pointers are allowed in cache files, every "pointer or offset"
field must be an offset or NULL
- Iterating linked lists must not take longer than the amount of elements
specified. A violation of this rule can break a possible endless loop.
If one or more of these points are violated, the cache is recreated.
This is current behaviour.
Even though this patch fixes many issues, the use of mmap() shall be
forbidden in setuid binaries. It is impossible to guarantee with these
checks that a malicious user does not change cache files after
verification. This should be handled in a different patch.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Take a look at the nano second in the mtime to figure out
if the cache needs to be updated if available.
and do the mutex lock between scanning and writing a cache
to avoid the conflict.
Also we don't need to scan directories again after writing
caches. so getting rid of the related code as well.
https://bugs.freedesktop.org/show_bug.cgi?id=69845
and for reference:
https://bugzilla.redhat.com/show_bug.cgi?id=1236034
In 32ac7c75e8 the behavior of
FcConfigAppFontAddFile/Dir() were changed to return false
if not fonts were found. While this is welldefined and useful
for AddFile(), it's quite problematic for AddDir(). For example,
if the directory is empty, is that a failure or success? Worse,
the false value from AddDir() was being propagated all the way
to FcInit() returning false now. This only happened upon memory
allocation failure before, and some clients assert that FcInit()
is successful.
With this change, AddDir() is reverted back to what it was.
AddFont() change (which was actually in fcdir.c) from the original
commit is left in.
just setting FC_MATCH=3 shows a lot of information and hard to keep on track for informamtion
which is really necessary to see. to use this more effectively, added FC_DBG_MATCH_FILTER to
see for what one really want to see. it takes a comma-separated-list of object names.
If you want to see family name only, try like this:
FC_DBG_MATCH_FILTER=family FC_DEBUG=4096 fc-match
debugging output will be filtered out and see family only in the result.
Continue to increase the object id even after FcFini()
and detect the overflow. that would be rather easier than
reset the object id with the complicated mutex and atomic
functions.
This situation would be quite unlikely to happen though
Adds FC_SYMBOL.
This affects fonts having a cmap with platform 3 encoding 0.
We now map their glyphs from the PUA area to the Latin1 area.
See thread "Webdings and other MS symbol fonts don't display"
on the mailing list.
Test before/after with:
$ pango-view --markup --text='<span fallback="false">×</span>' --font=Wingdings
Paths starting with '/' don't make sense on W32 as-is,
prepend the installation root directory to them.
This allows the cache to be contained within a particular
fontconfig installation (as long as the default
--with-cache-dir= is overriden at configure time).
Prior to the change of 32ac7c75e8
FcConfigAppFontAddFile() always returned FcTrue no matter what
fonts was added. after that, it always returned FcFalse because
adding a font doesn't add any subdirs with FcFileScanConfig().
so changing that to simply ignore it.
Also fixing it to return FcFalse if non-fonts was added, i.e.
FcFreeTypeQuery() fails.
https://bugs.freedesktop.org/show_bug.cgi?id=89617
Tobias Stoeckmann
Akira TAGOH
Erik de Castro Lopo
Petr Filipsky
Behdad Esfahbod
Patrick Haller
Руслан Ижбулатов