[tex-live] crash using bibtex on large .bib files

[Vincent Danen]

* [2009-08-11 19:04:10 -0500] Karl Berry wrote:

>Sorry for the delayed reply.

No problem.  It wasn't overly urgent.

>    There is a string pool size limit per one reallocation that is defined
>    to 65000, and a large .bib file will exceed this.  
>
>Bletch.

Yeah.  We've adjusted this limit upwards to 650,000 in the upcoming
Fedora 12 and while it passes this case, it's not really a "fix",
exactly.

>    Do you feel this is a security issue that needs to be addressed, or
>    merely a bug that needs correcting?
>
>I don't see any particular security ramifications here.
>It's not like bibtex is setuid or commonly run by root or anything.
>Do you have something else in mind?

Not really.  The rationale we were thinking is that untrusted .bib files
would be quite uncommon (not to mention the user-base for these files is
considerably smaller than other applications due to how specialized it
is).  Then again, I'm unfamiliar with it and don't know if this would
corrupt memory or allow for arbitrary code execution.  I don't *think*
it would, but I can't tell.

Privilege escalation is one thing, but having a large/naughty .bib file
execute something like "rm -rf ~/" isn't nice either so if there was the
possibility for this, we would want to correct it.  If it's not
possible, we'll live with the adjusted limit and chalk it up to a simple
crash (i.e. a "don't do that again" scenario).

As well, I don't think there are many sites that offer .bib files for
download (I found one, but didn't look too hard).  So the idea of
untrusted .bib files would also be quite remote.

>    [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520920
>
>I downloaded
>http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=29;filename=bibtex-crash.tar.lzma;att=1;bug=520920
>and running  bibtex live_fp  does reproduce the crash for me.
>I'll see if I can fix it.

Thanks, Karl.  If nothing else, it would be good to have it fixed
upstream I think (even if treated as a regular bug/crash than a security
issue which I suspect it probably only is).  If there were security
ramifications, we'd like to deal with it.  If not, we're more than happy
to let you deal with it upstream.  =)

-- 
Vincent Danen / Red Hat Security Response Team