Bug 470619 - Don'd care string ("????") in X11 font name causes NULL pointer dereference in libtk
Don'd care string ("????") in X11 font name causes NULL pointer dereference i...
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: tk (Show other bugs)
4.5
All Linux
medium Severity medium
: rc
: ---
Assigned To: Jaroslav Škarvada
BaseOS QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-07 19:58 EST by Stephen P. Schaefer
Modified: 2010-11-01 04:30 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-11-01 04:30:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Fix Memory fault when X11 server provides oddball fonts. (1.29 KB, patch)
2008-11-07 19:58 EST, Stephen P. Schaefer
no flags Details | Diff
tk-8.4.7-sigsegv.patch (394 bytes, patch)
2010-03-30 06:13 EDT, Jaroslav Škarvada
no flags Details | Diff

  None (edit)
Description Stephen P. Schaefer 2008-11-07 19:58:23 EST
Created attachment 322919 [details]
Fix Memory fault when X11 server provides oddball fonts.

Description of problem:
Memory fault.

Version-Release number of selected component (if applicable):
tk-8.4.7 (in Fedora 8, tk-8.4.17)

How reproducible:
Consistently

Steps to Reproduce:
1.Have an X server with these fonts available:
sschaefe@modelb00h xlsfonts | fgrep 'misc-????'
-misc-????-bold-r-normal--0-0-0-0-p-0-iso8859-1
-misc-????-bold-r-normal--0-0-0-0-p-0-microsoft-symbol
-misc-????-medium-r-normal--0-0-0-0-p-0-iso8859-1
-misc-????-medium-r-normal--0-0-0-0-p-0-microsoft-symbol

2.Attempt to display oddball Unicode characters using the Tk library, for instance, run the following python program:

sschaefe@modelb00h cat t2.py
# -*- coding: utf-8 -*-
import sys, Tkinter, unicodedata
u = u'(a\u00c9\u03a9B\u3045\u4e7cz):\n' # '(aÉΩBぅ乼cz):\n'
Tkinter.Button(text=u, command=sys.exit).pack( )
Tkinter.mainloop( )

3. python t2.py
  
Actual results:        
Memory fault 


Expected results:
Display button containing Unicode characters.

Additional info:
The attached patch solves the problem for me.
Comment 1 Jaroslav Škarvada 2010-03-22 04:27:34 EDT
I can't reproduce this. Please what is the source of problematic fonts? I did:

# yum install '*font*'
# xlsfonts | fgrep 'misc-????' | wc -l
0

I think in properly configured X there shouldn't be any '?' in font names.
Comment 2 Stephen P. Schaefer 2010-03-22 20:22:40 EDT
The fonts in question are the result of following the instructions at http://www.mozilla.org/projects/mathml/fonts/ for support of MathML under Firefox 2; specifically, download http://support.wolfram.com/technotes/fonts/windows/files/MathFonts_TrueType_41.exe; then

mkdir $font_dir
cd $font_dir
unzip $download_dir/MathFonts_TrueType_41.exe
mkfontscale
mkfontdir;
xset +fp `pwd`
xset fp rehash

This is an failure in the *client* to check the failure result of function calls; see the patch.  There are conventions concerning font names, but the only hard restriction is that they are null terminated strings.  Tk is dereferencing a NULL pointer; it's much easier to fix that than determine whether it constitutes a security vulnerability.
Comment 3 Jaroslav Škarvada 2010-03-30 06:13:28 EDT
Created attachment 403460 [details]
tk-8.4.7-sigsegv.patch

According to "X Logical Font Description Conventions":

Field values are constructed as strings of ISO 8859-1 graphic characters, excluding the following:
− (HYPHEN), the XLFD font name delimiter character
? (QUESTION MARK) and * (ASTERISK), the X protocol font name wildcard characters
, (COMMA), used by Xlib to separate XLFD font names in a font set.
" (QUOTATION MARK), used by some commercial products to quote a font name.

Thus the result of mkfontscale seems not to be valid here. I will file bug on it.

I agree that the client shouldn't hang even under these circumstances, but your patch seems for mee too restrictive and far from the call causing the hang. I propose less restrictive solution (in attachement). It seems there are no more calls that could hang, but maybe I overlooked something, so any comments are welcome.
Comment 5 Jaroslav Škarvada 2010-04-08 08:18:36 EDT
The mkfontscale issue continues in Bug 578460.
Comment 6 Jaroslav Škarvada 2010-04-18 05:25:43 EDT
The prerequisite for this bug is misconfiguration of X. The included patch fixes SIGSEGV under this condition. But other tools also SIGSEGV under this condition (e.g. xfontsel). Probably better solution than fixing all of these tools would be back-porting mkfontscale fix from the Bug 578460 that prevents misconfiguration of X from happening.
Comment 7 Ludek Smid 2010-11-01 04:30:16 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release.

Red Hat does not currently plan to fix this issue in a Red Hat Enterprise Linux update for currently deployed products.

With the goal of minimizing risk of change for deployed systems, and in response to customer and partner requirements, Red Hat takes a conservative approach when evaluating enhancements and defects for inclusion in maintenance updates for currently deployed products. The primary objectives of update releases are to enable new hardware platform support and to resolve critical defects.

For more information on Red Hat Enterprise Linux maintenance policies, please consult: http://www.redhat.com/security/updates/errata/

Note You need to log in before you can comment on or make changes to this bug.