what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New


Posted Apr 4, 2004
Authored by Shaun Colley | Site nettwerked.co.uk

A symbolic link condition exists in all versions of texutil. An attacker can overwrite arbitrary files.

tags | advisory, arbitrary
SHA-256 | 586cc0a27418caea44ad3c243bbf5295f48839a64e4f7c4106f429462e13e953


Change Mirror Download

Product: texutil
Versions: All
Bug: Symlink bug
Impact: Attackers can overwrite arbitrary files
with the privileges of the invoking user
Risk: Medium
Date: April 4, 2004
Author: Shaun Colley
Email: shaunige yahoo co uk
WWW: http://www.nettwerked.co.uk



Vendor description:

"When processing a text, ConTEXt saves table and index
entries, cross references, and
some more information in a so called utility file.
After a successful run, this file is
converted into a format suitable for the next run.
This conversion is done by TEXutil,
a Perl script that comes with the ConTEXt
distribution." - Taken from the texutil man page.

Texutil is prone to a symlink vulnerability when
writing output to a hardcoded logfile, when the
'--silent' option is supplied when the texutil script
is invoked.


Texutil is prone to a symlink vulnerability when
writing to a pre-defined logfile, which may allow
local users to overwrite arbitrary files with the
privileges of the invoking user of texutil. This
issue manifests when a user supplies the '--silent'
switch at the shell. When the texutil script is
invoked with the '--silent' flag, all standard output
is redirected to a hardcoded log file, 'texutil.log',
in the current directory.

Below is the offending code:

--- /usr/bin/texutil snippet ---
$ProgramLog = "texutil.log" ;

sub RedirectTerminal
open STDOUT, ">$ProgramLog" ;
select STDOUT; $| = 1 }

#D And, indeed:

if ($ProcessSilent)
{ RedirectTerminal }
{ $ProcessVerbose = 0 }
--- EOC ---

When the command line flags are parsed, $ProcessSilent
is set if '--silent' is supplied.

As one can see, the above code checks for the
existance of the $ProcessSilent variable, indicating
'--silent' was given, and calls the RedirectTerminal
sub-routine, which redirects standard output to
'texutil.log' - otherwise, texutil output is printed

However, when the 'texutil.log' file is opened, checks
aren't performed to ensure that a symlink doesn't
exist, or otherwise:

open STDOUT, ">$ProgramLog" ;

This line simply opens the logfile (texutil.log) with
the 'write, truncate' open() code, thus clobbering
*all* data already in 'texutil.log'. Due to the lack
of file checks on 'texutil.log', a possibility of
exploitation exists.

If an attacker can somehow place a symlink in the
working directory of the invoking user of texutil to a
sensitive system file or otherwise, the attacker can
cause data to be overwritten/destroyed with the
privileges of the invoker of texutil. If the user
running texutil was the root user, and their current
working directory was /tmp, almost any sensitive
system file could be destroyed.


All that a would-be attacker needs to exploit this
flaw is the correct privileges to place a suitable
symlink in the working directory of the invoker on

Below is an example scenario in which the
vulnerability is exploited to create a system file,

--- attack ---
[root@localhost shaun]# cd /tmp


[shaun@localhost shaun]$ ls -al /etc/nologin
ls: /etc/nologin: No such file or directory
[shaun@localhost shaun]$ cd /tmp
[shaun@localhost tmp]$ ln -s /etc/nologin texutil.log


[root@localhost tmp]# texutil --silent


[shaun@localhost tmp]$ ls -al /etc/nologin
-rw-r--r-- 1 root root 1511 Apr 4
15:21 /etc/nologin
--- EO attack ---

After this attack, no users except root can log in,
due to the existance of /etc/nologin.

In the example attack above, the root user changed
directories to /tmp, whilst an attacker created a
symlink by the name of /tmp/texutil.log linked to
/etc/nologin. Because of the non-existance of file
checks performed by texutil on 'texutil.log', the
symlink is followed, and /etc/nologin is written to by
root. Obviously, more sensitive system files could be
overwritten/corrupted, but this scenario demonstrates
partial impact.

It should be noted that the attacker would need to
have sufficient privileges to write to the working
directory of the invoker of texutil, so as to create a
symlink. However, this isn't really infeasible.


I contacted the author of texutil on 25 March 2004,
but I haven't received any response, so I wrote my own
fix for the issue.

--- texutil.patch ---
--- /usr/bin/texutil 2002-08-30 22:11:22.000000000
+++ /usr/bin/texutil.1 2004-04-04 16:41:34.000000000
@@ -126,6 +126,16 @@

sub RedirectTerminal
+ # Check for existance of texutil.log
+ # if the file already exists, or a symlink
+ # the script will die, thus fixing the
+ #
+ # -shaun2k2
+ if(lstat $ProgramLog) {
+ die "texutil: texutil.log exists - possibly a
+ }
open STDOUT, ">$ProgramLog" ;
select STDOUT; $| = 1 }

--- EOF ---

To apply the patch, simply create a file containing
the patch, and issue the following command as root:

root# patch /usr/bin/texutil texutil.patch

When texutil is invoked with the '--silent' flag, a
check is performed for 'texutil.log' - if it exists as
a file or a symlink, the script dies with a
semi-informative error message.

The above patch is also available from:



This issue was discovered by Shaun Colley / shaun2k2 -
<shaunige yahoo co uk>.

Thank you for your time.

WIN FREE WORLDWIDE FLIGHTS - nominate a cafe in the Yahoo! Mail Internet Cafe Awards www.yahoo.co.uk/internetcafes
Login or Register to add favorites

File Archive:

June 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Jun 1st
    0 Files
  • 2
    Jun 2nd
    0 Files
  • 3
    Jun 3rd
    18 Files
  • 4
    Jun 4th
    21 Files
  • 5
    Jun 5th
    0 Files
  • 6
    Jun 6th
    57 Files
  • 7
    Jun 7th
    6 Files
  • 8
    Jun 8th
    0 Files
  • 9
    Jun 9th
    0 Files
  • 10
    Jun 10th
    12 Files
  • 11
    Jun 11th
    27 Files
  • 12
    Jun 12th
    38 Files
  • 13
    Jun 13th
    16 Files
  • 14
    Jun 14th
    14 Files
  • 15
    Jun 15th
    0 Files
  • 16
    Jun 16th
    0 Files
  • 17
    Jun 17th
    0 Files
  • 18
    Jun 18th
    0 Files
  • 19
    Jun 19th
    0 Files
  • 20
    Jun 20th
    0 Files
  • 21
    Jun 21st
    0 Files
  • 22
    Jun 22nd
    0 Files
  • 23
    Jun 23rd
    0 Files
  • 24
    Jun 24th
    0 Files
  • 25
    Jun 25th
    0 Files
  • 26
    Jun 26th
    0 Files
  • 27
    Jun 27th
    0 Files
  • 28
    Jun 28th
    0 Files
  • 29
    Jun 29th
    0 Files
  • 30
    Jun 30th
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2022 Packet Storm. All rights reserved.

Security Services
Hosting By