GNU bug report logs - #59544
[PATCH] Fixed lib-src/etags.c command execute vulnerability

Previous Next

Package: emacs;

Reported by: "lux" <lx <at> shellcodes.org>

Date: Thu, 24 Nov 2022 15:28:02 UTC

Severity: normal

Tags: patch, security

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: "lux" <lx <at> shellcodes.org>
Cc: 59544 <at> debbugs.gnu.org, lx <at> shellcodes.org
Subject: bug#59544: [PATCH] Fixed lib-src/etags.c command execute vulnerability
Date: Thu, 24 Nov 2022 20:01:46 +0200
> Cc: lux <lx <at> shellcodes.org>
> From: "lux" <lx <at> shellcodes.org>
> Date: Thu, 24 Nov 2022 23:27:13 +0800
> 
> When using the -u parameter, ctags will execute external shell commands by calling the system() function,
> if there are special file names, unexpected shell commands may be executed. The example is as follows:
> 
> $ ls
> etags.c
> $ /usr/local/bin/ctags *.c
> $ touch "'| uname -a #.c"
> $ /usr/local/bin/ctags -u *.c
> Linux mypc 6.0.8-300.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Nov 11 15:09:04 UTC 2022 x86_64
> x86_64 x86_64 GNU/Linux
> 
> ^C/usr/local/bin/ctags: failed to execute shell command
> 
> The vulnerability occurs in the following code:
> 
> char *z = stpcpy (cmd, "mv ");                   
> z = stpcpy (z, tagfile);                         
> z = stpcpy (z, " OTAGS;grep -Fv '\t");           
> z = stpcpy (z, argbuffer[i].what);               
> z = stpcpy (z, "\t' OTAGS >");                   
> z = stpcpy (z, tagfile);                         
> strcpy (z, ";rm OTAGS");                         
> if (system (cmd) != EXIT_SUCCESS)                
>   fatal ("failed to execute shell command");     
> 
> Because the file name is not checked, the file name is used as a concatenated string:
> 
> mv tags OTAGS;grep -Fv ' '| uname -a #.c ' OTAGS >tags;rm OTAGS
> 
> Email attachments are patches.

Thanks, but the solution you propose for this is too drastic: it in effect
rejects legitimate file names just because they have characters which look
"suspicious".  I think we need a more accurate test, which will not produce
false positives so easily.  Or maybe we need to ask the user for
confirmation instead of skipping the files with suspicious names.




This bug report was last modified 2 years and 129 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.