Bug#889720: xauth crashes when directory name matches host name

2022-04-01 Thread Larry Doolittle
My testing confirms this bug still applies to xauth-1:1.1-1 in Bullseye,
as the status graphic indicates.

Fixed upstream in xauth-1.1.1.  I hope that version can be
packaged in time for Bookworm -- it includes a number of
subtle but important improvements.

Looking at the upstream repo at
  https://gitlab.freedesktop.org/alanc/xauth
the fix for this particular issue was applied in commit c2811c95
by Alex Gendin on Sep 26, 2020.

Triggering the bug was also made less likely with commit 18a3c3a7
by Dr. Tilmann Bubeck on Aug 20, 2020, but that change seems
incomplete in my testing.  I attach a two-line patch that
gives correct output when a file or directory in $PWD happens
to have the same name as $(hostname).

Example, starting with the buggy Debian Bullseye xauth-1.1:

guest@redacted:~/empty$ ls
guest@redacted:~/empty$ ls -l ~/.Xauthority-*
ls: cannot access '/home/guest/.Xauthority-*': No such file or directory
guest@redacted:~/empty$ xauth list $(hostname -f):0
redacted.localdomain:0  MIT-MAGIC-COOKIE-1  d41d8cd98f00b204e9800998ecf8427e
guest@redacted:~/empty$ touch $(hostname)
guest@redacted:~/empty$ xauth list $(hostname -f):0
Segmentation fault
guest@redacted:~/empty$ ls -li ~/.Xauthority-*
57941079 -rw--- 2 guest guest 0 Mar 31 13:09 /home/guest/.Xauthority-c
57941079 -rw--- 2 guest guest 0 Mar 31 13:09 /home/guest/.Xauthority-l
guest@redacted:~/empty$ 

Then xauth-1.1.1:

guest@redacted:~/empty$ ls
guest@redacted:~/empty$ ls -l ~/.Xauthority-*
ls: cannot access '/home/guest/.Xauthority-*': No such file or directory
guest@redacted:~/empty$ xauth-1.1.1 list $(hostname -f):0
redacted.localdomain:0  MIT-MAGIC-COOKIE-1  d41d8cd98f00b204e9800998ecf8427e
guest@redacted:~/empty$ touch $(hostname)
guest@redacted:~/empty$ xauth-1.1.1 list $(hostname -f):0
xauth-1.1.1: (argv):1:  bad display name "redacted.localdomain:0" in "list" 
command
guest@redacted:~/empty$ ls -li ~/.Xauthority-*
ls: cannot access '/home/guest/.Xauthority-*': No such file or directory

And finally my patched xauth-1.1.1:

guest@redacted:~/empty$ ls
guest@redacted:~/empty$ ls -l ~/.Xauthority-*
ls: cannot access '/home/guest/.Xauthority-*': No such file or directory
guest@redacted:~/empty$ xauth-fixed list $(hostname -f):0
redacted.localdomain:0  MIT-MAGIC-COOKIE-1  d41d8cd98f00b204e9800998ecf8427e
guest@redacted:~/empty$ touch $(hostname)
guest@redacted:~/empty$ xauth-fixed list $(hostname -f):0
redacted.localdomain:0  MIT-MAGIC-COOKIE-1  d41d8cd98f00b204e9800998ecf8427e
guest@redacted:~/empty$ ls -li ~/.Xauthority-*
ls: cannot access '/home/guest/.Xauthority-*': No such file or directory

  - Larry
--- xauth-1.1.1/parsedpy.c	2021-11-28 15:33:47.0 -0800
+++ xauth-1.1.1-lrd/parsedpy.c	2022-03-31 12:20:38.700070442 -0700
@@ -175,14 +175,14 @@
 strncpy(path, displayname, sizeof(path) - 1);
 path[sizeof(path) - 1] = '\0';
 #endif
-if (0 == stat(path, )) {
+if (0 == stat(path, ) && S_ISSOCK(sbuf.st_mode)) {
 family = FamilyLocal;
 } else {
 char *dot = strrchr(path, '.');
 if (dot) {
 *dot = '\0';
 /* screen = atoi(dot + 1); */
-if (0 == stat(path, )) {
+if (0 == stat(path, ) && S_ISSOCK(sbuf.st_mode)) {
 family = FamilyLocal;
 }
 }


Bug#889720: xauth crashes when directory name matches host name

2018-02-06 Thread John Williams
Package: xauth
Version: 1:1.0.10-1
Architecture: arm64

Running 'startx' on a machine named 'myhost' (aarch64), with a sub-directory 
named 'myhost' in my home directory:  X starts very slowly, and I see the 
message:

xauth:  timeout in locking authority file /home/john/.Xauthority

Here's what happens: the 'startx' script calls 'xauth list' in a loop (line 
199) and the first call crashes after receiving SIG_SEGV; this leaves its lock 
files in place, and the next instance of xauth times out waiting for them to go 
away.

I think I've traced the reason for 'xauth list' crashing: my .Xauthority file 
contains a line like this:

myhost:0 MIT-MAGIC-COOKIE-1 

and while processing this for printing, there's some code in parsedpy.c (line 
178) that does this:

if (0 == stat(path, ))
family = FamilyLocal;

and this test succeeds because 'myhost' is the name of a valid file (actually a 
directory)

Then later on in gethost.c we have:

switch (family) {
case FamilyLocal: /* hostname/unix:0 */
...
if (0 == stat(path, ))
is_path_to_socket = 1;
...
if (is_path_to_socket)
strncpy(buf, strrchr(fulldpyname, '/') + 1, 
sizeof(buf));

But there is no '/' in the name, so we end up passing a null pointer to 
strncpy(), which crashes the whole program.