[texhax] texutil security bug reports.

[Shaun Colley]

Hello,

Excuse me if this isn't the right email to contact,
but I didn't find anything about TeX bug reports in
the FAQ.


I believe I have found some issues in the texutil Perl
script, which may allow a potential attacker to
overwrite arbitrary files.  There may be more
instances of similar vulnerabilities in texutil, but
these are the few I found.


1) Symlink vulnerability when --silent is used.

This bug occurs due to insecure file handling, when
the --silent flag is used at the shell.  When --silent
is used, texutil.log is written with all program
output, instead of being written to stdout.  The
insecure file creation code is here:


Lines 125 - 137
--
$ProgramLog = "texutil.log" ;

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

#D And, indeed:

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

As you likely know, $ProcessSilent is set when the
--silent flag is issued at the command line with the
texutil invokation.  This can be exploited by users
with write access to the directory which the targetted
user is working in:

--
example$ ls -al /etc/nologin
ls: /etc/nologin: No such file or directory
example$ ln -s /etc/nologin texutil.log

[...]

root# texutil --silent

[...]

example$ ls -al /etc/nologin
-rw-r--r--    1 root     root         1511 Mar 25
20:03 /etc/nologin
--

Although different system files could've been
corrupted, I hope this helps to demonstrate, at least.


2) Insecure tmpfile opening

I haven't explored this one very well, or in what
conditions it could be exploited, but the vulnerable
code is here:


Lines 1701 - 1703
--
else
      { open ( EPS, ">texutil.tmp" ) ;
        binmode EPS }
[...]
--

If the user had the correct privileges (i.e write
access to the current working dir), perhaps this could
be exploited by linking texutil.tmp to an arbitrary
sensitive system file.  Sorry for not providing much
info on this one, but by the code it is apparent that
it could be an issue.



Although the issues do require the user to have write
access to the working dir of the victim, this is by no
means infeasible.  I.e the user might be in the same
GID, but might have a more privileged UID.  Or, the
root user might've 'cd /tmp', and forgotton to revert
back to his/her /root home directory.  Do you agree
with my points?

It should be noted, that I suspect there are a few
more bugs/vulnerabilities similar to these few that I
commented on in the texutil code - I didn't check the
code thoroughly, but more could exist.  You may wish
to check.  Maybe 'grep' the code for 'open' calls and
route out the ones which are sources of trouble.

My suggested fix for this, if you are willing to fix
it (I hear texutil is a popular & useful tool), would
be to use 'sysopen' instead of 'open' and then check
for an error, and 'die' if a file already exists by
the name.  I think this would be more secure, do you
agree?  I could maybe have a go at fixing this if you
no longer maintain it or something, I could perhaps
produce a patch.

Cheers.



Thank you for your time.
Shaun.


	
	
		
___________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html