Bug 49296 (CVE-2004-0084)

<!-- SBZ_reproduce  -->
-

Created attachment 15852 [details]
emails

Created attachment 15853 [details]
dirfile.diff

the attachement

Created attachment 15854 [details]
patchinfo-box.xfree

Created attachment 15856 [details]
patchinfo.xfree

Created attachment 15857 [details]
patchinfo.xf86

Created attachment 15858 [details]
patchinfo-box.xf86

Were you able to reproduce the security problem with the mentioned exploit? 
I can't.  
 

I can't get the Xserver crashing. The according line in fonts.alias simply 
does not work. For example: 
 
/usr/X11R6/lib/X11/fonts/misc/fonts.alias: 
[...] 
5x7     <the string mentioned in the exploit (more than 1024 chars)> 
 
sndirsch@shannon:~> xset fp rehash 
sndirsch@shannon:~> xterm -fn "5x7" 
xterm:  unable to open font "5x7", trying "fixed".... 
 
Then I restored original fonts.alias file 
sndirsch@shannon:~> xset fp rehash 
sndirsch@shannon:~> xterm -fn "5x7" 
(works fine) 
 

Yes I can. 
open@Lothlorien:~> uname -a 
Linux Lothlorien 2.4.21-186-default #1 Sat Jan 31 17:19:10 UTC 2004 i686 i686 
i386 GNU/Linux 
open@Lothlorien:~> cat /etc/SuSE-release 
SuSE Linux 9.0 (i586) 
VERSION = 9.0 
open@Lothlorien:~> rpm -q XFree86 
XFree86-4.3.0.1-43 
open@Lothlorien:~> 
 
open@Lothlorien:~> X :1 -fp $PWD 
 
This is a pre-release version of XFree86, and is not supported in any 
way.  Bugs may be reported to XFree86@XFree86.Org and patches submitted 
to fixes@XFree86.Org.  Before reporting bugs in pre-release versions, 
please check the latest version in the XFree86 CVS repository 
(http://www.XFree86.Org/cvs). 
 
XFree86 Version 4.3.0.1 
Release Date: 9 May 2003 
X Protocol Version 11, Revision 0, Release 6.6 
Build Operating System: SuSE Linux [ELF] SuSE 
Build Date: 02 October 2003 
        Before reporting problems, check http://www.XFree86.Org/ 
        to make sure that you have the latest version. 
Module Loader present 
Markers: (--) probed, (**) from config file, (==) default setting, 
         (++) from command line, (!!) notice, (II) informational, 
         (WW) warning, (EE) error, (NI) not implemented, (??) unknown. 
(==) Log file: "/var/log/XFree86.1.log", Time: Wed Feb  4 10:52:39 2004 
(==) Using config file: "/etc/X11/XF86Config" 
 
   *** If unresolved symbols were reported above, they might not 
   *** be the reason for the server aborting. 
 
Fatal server error: 
Caught signal 11.  Server aborting 
 
 
When reporting a problem related to a server crash, please send 
the full server output, not just the last messages. 
This can be found in the log file "/var/log/XFree86.1.log". 
Please report problems to http://www.suse.de/feedback. 
 
Abgebrochen 
 
 

What have you done before? What about the fonts, fonts.dir and fonts.alias 
in $PWD? 

Just as described in the mail. I'll attach them. 

Created attachment 15860 [details]
fonts.alias

Created attachment 15861 [details]
fonts.dir

Sorry, but this cannot work, what you're doing. The font is probably missing 
the fixed and cursor alias are missing and so on. And this is what I get: 
 
$ X :1 -fp $PWD  
 
This is a pre-release version of XFree86, and is not supported in any 
way.  Bugs may be reported to XFree86@XFree86.Org and patches submitted 
to fixes@XFree86.Org.  Before reporting bugs in pre-release versions, 
please check the latest version in the XFree86 CVS repository 
(http://www.XFree86.Org/cvs). 
 
XFree86 Version 4.3.99.902 (4.4.0 RC 2) 
Release Date: 18 December 2003 
X Protocol Version 11, Revision 0, Release 6.6 
Build Operating System: SuSE Linux [ELF] SuSE 
Current Operating System: Linux shannon 2.6.1-5-default #1 Fri Jan 30 17:50:49 
U 
TC 2004 i686 
Build Date: 01 February 2004 
Changelog Date: 27 January 2004 
        Before reporting problems, check http://www.XFree86.Org/ 
        to make sure that you have the latest version. 
Module Loader present 
Markers: (--) probed, (**) from config file, (==) default setting, 
        (++) from command line, (!!) notice, (II) informational, 
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown. 
(==) Log file: "/var/log/XFree86.1.log", Time: Wed Feb  4 13:08:29 2004 
(==) Using config file: "/etc/X11/XF86Config" 
(EE) Failed to load module "rfbmouse" (module does not exist, 0) 
(EE) Failed to load module "rfbkeyb" (module does not exist, 0) 
(II) Initializing extension GLX 
Could not init font path element /suse/sndirsch/tmp, removing from list! 
 
Fatal server error: 
could not open default font 'fixed' 
 
 

1.) it is not designed to work, it is designed to create a SEGV, and that does 
work 
 
2.) you use a very different XFree86 version (4.3.99.902 vs. 4.3.0.1) 
 
If we use 4.3.99.902 in STABLE then it seems to be fixed there, but 4.3.0.1 is 
the official version from SL9.0 (and I bet a beer that older version are 
affected too) 
 

This is surprising as the security fix is not yet in our STABLE XFree86 
version. Indeed, it happens on a SuSE 9.0 system. Just checked. Looks like 
the security bug was fixed by accident in CVS. :-) 

If the code is still in there we should fix it too. 
 
Maybe due to some more sanity checks this dirty example didn't get to the 
vulnerable code. 

Yes, I think so. I'll wait until David commited the patch. 

You mean David Dawes <dawes@XFree86.Org>, right? 
 
At the moment this bug is private till iDEFENSE mades it public. 
 
Nevertheless, waiting for an official patch in their CVS is too late to be 
ready for a coordinate release. 
 
The patch is simple: 
switch (token) { 
       case NAME: 
-         strcpy(alias, lexToken); 
+         strncpy(alias, lexToken, sizeof(alias)-1); 
+         alias[sizeof(alias)-1] = '\0'; 
 
Or are there more strcpy's and strcat's in the code? 

I want to avoid using another patch than in XFree86 4.4.0. BTW, you've sent me 
another patch. I don't think we're in a hurry now. Testing and approving the 
update will need some weeks as usual anyway. 
 
Index: dirfile.c 
=================================================================== 
RCS file: /home/x-cvs/xc/lib/font/fontfile/dirfile.c,v 
retrieving revision 3.16 
diff -u -r3.16 dirfile.c 
--- dirfile.c   7 Apr 2003 16:23:31 -0000       3.16 
+++ dirfile.c   4 Feb 2004 00:19:49 -0000 
@@ -291,6 +291,10 @@ 
            status = AllocError; 
            break; 
        case NAME: 
+           if (strlen(lexToken) >= sizeof(alias)) { 
+               status = BadFontPath; 
+               break; 
+           } 
            strcpy(alias, lexToken); 
            token = lexAlias(file, &lexToken); 
            switch (token) { 
 

Ah yes. Use this one. 
 
If you submit the packages fast, the QA team can start testing early and 
we have the packages ready for the coordinate release date. We really should 
meet this date to avoid bad press. 

My update plan: 
 
Sources                                            /work/src/done/<dir> 
----------------------------------------------------------------------- 
/work/SRC/old-versions/7.2/all/xf86                SLES7 
/work/SRC/old-versions/7.2/arch/s390/xf86           ??? (7.2-s390) 
/work/SRC/old-versions/7.2/arch/sles-s390x/xf86    SLES7-s390x 
/work/SRC/old-versions/7.3/arch/ppc/xf86           SLES7-PPC 
/work/SRC/old-versions/8.0/all/xf86                8.0 
/work/SRC/old-versions/8.1/UL/all/xf86             8.1 
 
/work/SRC/old-versions/8.1/SLEC/all/XFree86        SLEC 
/work/SRC/old-versions/8.2/all/XFree86             8.2 
/work/SRC/old-versions/9.0/all/XFree86             9.0 
 

There is no common setuid/setgid Xserver for s390/s390x available as these 
beasts don't have any graphics hardware. I need to adjust the patchinfo 
files for this. Here's my new udpate plan. 
 
Sources                                            /work/src/done/<dir>  
-----------------------------------------------------------------------  
/work/SRC/old-versions/7.2/all/xf86                SLES7 
/work/SRC/old-versions/7.3/arch/ppc/xf86           SLES7-PPC 
/work/SRC/old-versions/8.0/all/xf86                8.0  
/work/SRC/old-versions/8.1/UL/all/xf86             8.1  
  
/work/SRC/old-versions/8.1/SLEC/all/XFree86        SLEC  
/work/SRC/old-versions/8.2/all/XFree86             8.2  
/work/SRC/old-versions/9.0/all/XFree86             9.0  
  

*scratch chin* So s390 dont have a X server at all, right? 
 

Only "virtual" Xservers like Xvfb, Xnest, Xvnc. :-) 

Do they run with root privileges? 

No. It isn't required as they don't access any hardware. 

Ah ok. :) 

Fixed. Updated packages are now below /work/src/done (see comment #24) and 
patchfiles in /work/src/done/PATCHINFO. Assigning to Thomas now, so he cares 
about that the security update will be tested and (hopefully) approved. 
 

Thanks Stefan! 
 
note: CAN-2004-0083 

another note for me: CAN-2004-0084 

David found a new bug in dirfile. I'll attach the diff and reject the 
packages. :( 

Created attachment 15925 [details]
dirfile2.diff

Looks like we still can use the same changelog for the package and the same 
description for the patchinfo. I just will append the new patch to the old one 
therefore. 

Ok. 
Can you add a newline or space to the old patchinfos to get a new MD5 sum. 
It will improve the ability to track this new one. 

I'll replace font.alias with fonts.alias in the description. :-) font.alias is 
simply wrong. 

Fixed. Updated packages are now below /work/src/done (see comment #24) and  
patchfiles in /work/src/done/PATCHINFO. Assigning to Thomas now, so he cares  
about that the security update will be tested and (hopefully) approved. 

*sigh* 
David reported more problem in dirfile... *grrml* 
 
I will not reject the packages that are currently in autobuild 
and will do a audit of dirfile on my own today. 

# /suse/bin/tel sndirsch 
[...] 
Vacation   : Mi 11.02. - Fr 13.02. 
 
I'll be back on monday. 

Ok, it looks like I need to reject the packages again. *sigh* 
 
I will be back with a quick source code review of directory  
xc/lib/font/fontfile 

Created attachment 15938 [details]
dirfile.c.diff

includes all three bugfixes

Created attachment 15939 [details]
fontfile.c.diff

includes some more sanity checks

patch makes problems: 
fontfile.c: In function `FontFileOpenBitmapNCF': 
fontfile.c:504: error: `scalable' undeclared (first use in this function) 
fontfile.c:504: error: (Each undeclared identifier is reported only once 
fontfile.c:504: error: for each function it appears in.) 
fontfile.c: In function `FontFileGetInfoBitmap': 
fontfile.c:538: error: `scalable' undeclared (first use in this function) 
 
Will submit packages tomorrow... 

Created attachment 15947 [details]
fontfile-sec_bufferoverflows.diff

hopefully final patch

submitted: 
- 8.0 
- 8.1 
- 8.2 
- 9.0 
- SLES8 
- SLES7 
- SLES7-PPC 
 
------------------------------------------------------------------- 
Thu Feb 12 11:52:46 CET 2004 - thomas@suse.de 
 
- fixed more buffer overflows in fontfile/ direc (#34296) 
- put together old and new bugs in 
  fontfile-sec_bufferoverflows.diff 
 
 

What about SLEC sources? BTW, 8.1 and SLES8 sources are exactly the same. 

Will submit SLEC packages in a few minutes. 

Date: Sat, 14 Feb 2004 08:58:09 +0000 (GMT) 
From: Dr Andrew C Aitchison <A.C.Aitchison@dpmms.cam.ac.uk> 
To: iDefense Labs <labs@iDefense.com> 
Cc: bugs@securitytracker.com, bugtraq@securityfocus.com 
Subject: Re: iDEFENSESecurityAdvisory02.10.04: 
XFree86FontInformationFileBufferOverflow 
 
On Tue, 10 Feb 2004, iDefense Labs wrote: 
 
> - - - From XFree86-4.2.1/xc/lib/font/fontfile/dirfile.c: 
> 
> ReadFontAlias(char *directory, Bool isFile, FontDirectoryPtr *pdir) 
> { 
> char alias[MAXFONTNAMELEN]; 
 
>        switch (token) { 
>        case NAME: 
>          strcpy(alias, lexToken); 
> 
> If lexToken is longer than MAXFONTNAMELEN (1024 chars) an overflow 
> occurs. 
 
I note that this code also ocurs in Xvnc, 
and that ReadFontAlias is essentially unchanged in XFree86 CVS since 
version 1.1, which has the CVS id string 
/* $XConsortium: dirfile.c,v 1.11 94/04/17 20:17:01 gildea Exp $ */ 
 
I would expect that X servers from many vendors have the same 
vunerablility. 
 
-- 
Dr. Andrew C. AitchisonComputer Officer, DPMMS, Cambridge 
A.C.Aitchison@dpmms.cam.ac.uk  http://www.dpmms.cam.ac.uk/~werdna 

I think Andrew is speaking of XFree86 3.x based Xvnc servers. We use xf4vnc 
since SuSE 9.0, which uses the same font library as the XFree86 server. 

packages approved. 

<!-- SBZ_reopen -->Reopened by thomas@suse.de at Wed Feb 25 10:44:27 2004

We got reports that this issue is NOT FIXED. :-( 
 
I'll check this today. 

Date: Tue, 24 Feb 2004 22:41:15 +0100 
From: Frank Steiner <fst@bio.informatik.uni-muenchen.de> 
To: Thomas Biege <thomas@suse.de> 
Cc: suse-security@suse.de 
Subject: Re: [suse-security] SUSE Security Announcement: xf86/XFree86
(SuSE-SA:2004:006) 
 
Hi, 
 
Thomas Biege wrote: 
 
> Hm, did you restart the X server? 
 
Yes, even rebooted the PC to avoid any caching effect. 
 
> Does this even happen as non-root user? 
 
yes, same effect. 
 
> 
> > Fatal server error: 
> > Caught signal 4.  Server aborting 
> 
> The original bug triggered a SIGSEGV (11) this one is a SIGILL (4). 
> Maybe it triggered just another bug. I'll verify the sources... 
 
Actually, rebooting the PC changed the signal to 11 again... It also 
happens on our SuSE 9.0 PCs with the updated XFree86 (as root and as 
any other user). And the signal is indeed caused by the font files: 
 
riemann /root# rpm -q --changelog XFree86 |head -n 5 
* Thu Feb 12 2004 - thomas@suse.de 
 
- fixed more buffer overflows in fontfile/ direc (#34296) 
- put together old and new bugs in 
  fontfile-sec_bufferoverflows.diff 
 
riemann /root/tmp# strace -f X :0 -fp $PWD 
: 
: 
open("/root/tmp/fonts.dir", O_RDONLY)   = 7 
fstat64(7, {st_mode=S_IFREG|0644, st_size=75, ...}) = 0 
fstat64(7, {st_mode=S_IFREG|0644, st_size=75, ...}) = 0 
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x40022000 
read(7, "1\nword.bdf -misc-fixed-medium-r-"..., 4096) = 75 
read(7, "", 4096)                       = 0 
read(7, "", 4096)                       = 0 
close(7)                                = 0 
munmap(0x40022000, 4096)                = 0 
open("/root/tmp/fonts.alias", O_RDONLY) = 7 
fstat64(7, {st_mode=S_IFREG|0644, st_size=1121, ...}) = 0 
fstat64(7, {st_mode=S_IFREG|0644, st_size=1121, ...}) = 0 
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x40022000 
read(7, "00000000000000000000000000000000"..., 4096) = 1121 
close(7)                                = 0 
munmap(0x40022000, 4096)                = 0 
--- SIGSEGV (Segmentation fault) @ 0 (0) --- 
rt_sigaction(SIGSEGV, {SIG_IGN}, {0x8084330, [SEGV], SA_RESTORER|SA_RESTART, 
0x4009caa8}, 8) = 0 
... 
 
 
 
Any more information I can send to help track down the problem (full strace, 
XF8Config etc.)? 
 
cu, 
Frank 
 
-- 
Dipl.-Inform. Frank Steiner     mailto:fst_at_bio.informatik.uni-muenchen.de 
Lehrstuhl f. Bioinformatik 
 

Sure, that XFree86-server package was updated by YOU? 

Does this make a difference? 
 
I did via YOU for 9.0 and I got SIGILL 
ltrace -S output attached 

Sure. It's a Xserver bug. Therefore XFree86-server package must be updated. 
SIGILL ist totally strange. 

Created attachment 16168 [details]
XFree86.1.log

Created attachment 16169 [details]
x.ltrc.gz

buffer overflows trigger SEGVs as well as SIGILLs. 

I'm still waiting for the answer of my question in comment #55. 

Yes Sir! Just see comment #56, Sir! 

An update was published for the package XFree86, but not for XFree86-server.
This means that the package provided does not fix the problem.

We need patchinfo files for the XFree86-server package.

Shouldn't happen...

R.

Ok, more news on this: Both the XFree86 base packages AND the XFree86-server
packages have been copied to the ftp server, but the patchfile will only have
the XFree86 package installed, leaving XFree86-server where it is.

Is this a failure on behalf of patchinfo?

Added ro@ and kukuk@ to Cc:.

Roman.

for clarification: comment #64 refers to SL8.2 and 9.0. The respective 8.1 and
8.0 packages are named xloader, which are not on the ftp server either.

I'm turning in new patchinfo files now.

My fault to trust the patchinfo files I've got. We need to update 
XFree86-server/xloader package as well. Oops! What I forgot completely, we 
need to warn the nvidia users, that they need to reinstall ther driver, 
because during the update of XFree86-server package, the nvidia driver needs 
to be uninstalled. Where can I find the latest patchinfo files for the update, 
so I can provide new patchinfo files with this information? 

~draht/Export/{XF,xl}*

These two are referring to boxpatchinfo only, not the maintained products.
I have just made them. Of course, the xloader package (or the XFree86-server
package, respectively) must be mentioned there. The packages provided for 
download are useless with respect to this bug.

What the maintained products is concerned, the text could be a little bit more
descriptive.

There used to be
------------------------------------------------
DISTRIBUTION: sles8-slec-i386
PACKAGE: XFree86
PACKAGER: sndirsch@suse.de
CATEGORY: security
INDICATIONS: Everyone using X should update.
CONTRAINDICATIONS:
CD-Produkt-Name:
CD-Produkt-Version:
REQUIRES:
DESCRIPTION:
A buffer overflow in the X server can be triggered by using a malformed
fonts.alias file. This bug can be used to gain local root privilege.
------------------------------------------------


DISTRIBUTION:
sles7-i386,sles7-ia64,sles7-ppc,sles8-i386,sles8-ppc,ul1-i386,ul1-ia64,ul1-x86_64
PACKAGE: xf86
PACKAGER: sndirsch@suse.de
CATEGORY: security
INDICATIONS: Everyone using X should update.
CONTRAINDICATIONS:
CD-Produkt-Name:
CD-Produkt-Version:
REQUIRES:
DESCRIPTION:
Security Fix:
A buffer overflow in the X server can be triggered by using a malformed
fonts.alias file. This bug can be used to gain local root privilege.
--------------------------------------------------

DISTRIBUTION: 8.0-i386,8.1-i386
PACKAGE: xf86
PACKAGER: sndirsch@suse.de
CATEGORY: security
DESCRIPTION:
Security Fix:
A buffer overflow in the X server can be triggered by using a malformed
fonts.alias file. This bug can be used to gain local root privilege.
DESCRIPTION_DE:
Sicherheits-Update:
Durch eine spezielle "fonts.alias"-Datei kann ein Speicherueberlauf im X-Server
ausgenutzt werden, um lokal root-Rechte zu erlangen.


------------------------------------------------a483a54ee5ada247095dea0b798871fd/patchinfo

We should fix the tmp races that still exists in the RPM postinstall script 
and in /etc/X11/xdm/Xsession with this update too. 
 
And yes. The strace output shows that the update package lacks the patch. 

Never heard of any tmp races in /etc/X11/xdm/Xsession. Can you give me some 
more details or even a patch for this? Fixing tmp races in postinstall scripts 
needs some testing and it's unlikely that I find the time for this now. About 
testing, I've got the impression that the udpates weren't tested by our test 
team at all. Otherwise we would have seen the problem with the missing 
XFree86-server packge in patchinfo file a long time ago ...  

Roman, the files ~draht/Export/{XF,xl}* seem to have wrong permissions. I 
can't read them. 

postinstall: bug 49253 
The other thingy is new and seems to be harder to fix. 
I try to provide you with a patch within the next hour. 

Created attachment 16180 [details]
Xsession.diff

Easier then first thought.
But check this please.

Stefan: permissions fixed.

The postinstall issue: mktemp only creates a filename for a temporary file, it
doesn't create the file. The resulting race is existent, but the potential is
considerably small. It can be fixed by changing 

  tmpfile=`mktemp /tmp/XF86Config.XXXXXXXXXX`
to read
  tmpfile=`mktemp /root/XF86Config.XXXXXXXXXX`

The Xsession issue: Currently it looks like:

: ${TMPDIR=/tmp}
for errfile in  "$HOME/.xsession-errors" \
                "$TMPDIR/xses-$USER"     \
                "/tmp/xses-$USER"
do
    #
    # Avoid bad symbolic links
    #
    case "$errfile" in
        /tmp/*|$TMPDIR/*) rm -f $errfile ;;
    esac
    if (> "$errfile") 2> /dev/null ; then
        chmod 0600 "$errfile"
        exec > "$errfile" 2>&1
        break
    fi
done

------- snip ---------------
This doesn't avoid anything. The gap between removing the file in /tmp and 
creating it again may be large enough to place a symlink in there.

The suggestion is to remove the lines that contain /tmp, to make it look like this:

errfile=$HOME/.xsession-errors
    if (> "$errfile") 2> /dev/null ; then
        chmod 0600 "$errfile"
        exec > "$errfile" 2>&1
    else
        logger -s -p user.err "$0: $errfile is not writeable"
    fi
--------- snip ----------------


rationale: If the HOME directory isn't writeable by the script (which runs as
the authenticated user after xdm login), then we have a whole set of different
oddities (such as .Xauthority file writing and such) so that it doesn't 
make sense any more to write the file in the first place.

Roman.

Sorry, thomas, I have overridden your comment, I was too fast with the mouse.

mktemp does create the files securely. 
that's why the patch in comment #73 shall suffice. 

Due to overload and _missing testcases_ for the packages inside PDB, there was
only done a basic testing. 
This isn't an excuse - but don't blame QA by finger pointing!

In my opinion we are all guilty- QA, Security-Team and the package-maintainer as
well me as maintenance coordinator. As long as we are humans, we will make
mistakes and we will make more mistakes if we are overloaded and we will make
more mistakes if we are disappointed. Finger pointing is a important source for
disappointment!

The "guilty" thing hasn't been an issue... Thomas and I are aware of the fact
that it was our fault, because the package names were just plain wrong. :-/
Shit happens.

It was meant more this way. Does it make sense to try to fix additional 
security problem (tmp races), when the test team doesn't have the time to test 
it anyway ... 

I think making mistakes is normal, but showing them to the public is stupid... 
or let's call it painful. :) 
 
Maybe we should install more measurements in the update process to catch 
simple mistakes made due to precipitance or by the lack of experience. 
 
I submitted the packages a second time because a patch was missing and Stafan 
was not available, and I was not aware of this package separation. 
To quote Roman: Shit Happens. :) 
 
 
QA is the best/logical part of the update process to hook such measurements, 
unfortunately these guys are already overloaded. 
 
 

Stefan, 
it's always worth trying to fix it. We should stay thinking positive. ;) 
 
BTW, the QA-Team always does YOU install tests, therefore problems with the 
postinstall changes should be recognized. 
 
But we have no testing for box products just for maintained products...  

Update: We can't afford the rebuild of all packages that depend on XFree86
(information from Thorsten). By consequence, we will have to get the tmpfile
fixes checked in on another day asap, but we can't wait for them today.

Means: we will provide the XFree86-server and xloader packages via (box) patchinfo
today, without any further package check-in or tests.

Roman.

Affirmative. 

I think I have the new patchinfo files ready. Unfortunately check_patchinfo 
don't like them. :-( 
 
--> ~sndirsch/pkgs/XFree86.bug34296 
 
# /work/src/bin/check_patchinfo patchinfo.XFree86-server.slec  
PRE has trailing space(s) 
Bad Line: Please note that users of the NVIDIA driver need to reinstall it 
after 
Bad Line: updating the package. Please follow the instructions in our NVIDIA 
Bad Line: Installer HOWTO, which can be found at the URL 
Bad Line: "http://www.suse.de/~sndirsch/nvidia-installer-HOWTO.html". 
Please fix your patchinfo file! 
 
# /work/src/bin/check_patchinfo patchinfo.XFree86-server.box  
PRE has trailing space(s) 
Bad Line: Please note that users of the NVIDIA driver need to reinstall it 
after 
Bad Line: updating the package. Please follow the instructions in our NVIDIA 
Bad Line: Installer HOWTO, which can be found at the URL 
Bad Line: "http://www.suse.de/~sndirsch/nvidia-installer-HOWTO.html". 
Bad Line: Beachten Sie bitte, dass Benutzer des NVIDIA Treibers diesen nach 
dem 
Bad Line: Update des Paketes neu installieren müssen. Befolgen Sie dazu bitte 
Bad Line: die Anweisungen in unserem NVIDIA Installer HOWTO (englisch), das 
Sie 
Bad Line: unter der folgenden URL finden. 
Bad Line: "http://www.suse.de/~sndirsch/nvidia-installer-HOWTO.html". 
Please fix your patchinfo file! 
 

Created attachment 16183 [details]
patchinfo.XFree86-server.box

Created attachment 16184 [details]
patchinfo.XFree86-server.slec

The complete text in one line. Cool. I've updated my files in 
 
  ~sndirsch/pkgs/XFree86.bug34296 
  

I copied the patchinfo files to /work/src/done/PATCHINFO. I'll take care about 
the tmp races in RPM post scripts and /etc/X11/xdm/Xsession in Bug 49253. 
Assigning bug now back to Thomas to take care about this now. 

The update packages are available via YOU and our ftp server, don't they? What 
about closing this bugreport as fixed now? 

SLES and SLEC is still in QA queue. 

packages approved (YOU only test). 

CVE-2004-0084: CVSS v2 Base Score: 10.0 (AV:N/AC:L/Au:N/C:C/I:C/A:C)