Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 74694

Summary: app-text/vilistextum-2.6.2: get_attr overflows temp buffer
Product: Gentoo Security Reporter: Sascha Silbe <sascha-gentoo-bugzilla>
Component: VulnerabilitiesAssignee: Gentoo Security <security>
Severity: normal CC: bhaak, shell-tools
Priority: High    
Version: unspecified   
Hardware: All   
OS: All   
Whiteboard: B2 [glsa] koon
Package list:
Runtime testing required: ---
Description Flags
Original file 12.html from advisory
Modified exploit that works with 2.6.2
Patch against 2.6.7 which enables use of glibc iconv
enables use of glibc iconv and --disable-multibyte
enables use of glibc iconv and --disable-multibyte again none

Description Sascha Silbe 2004-12-16 15:11:21 UTC
The following advisory from is for vilistextum 2.6.6, but I could get app-text/vilistextum-2.6.2 to SegFault with an adapted exploit (the buffer is 300000 chars in 2.6.2, not 32768 as in 2.6.6), so it's probably also vulnerable.

Date: 15 Dec 2004 08:16:58 -0000
From: "D. J. Bernstein" <>
Subject: [remote] [control] vilistextum 2.6.6 get_attr overflows temp buffer
Mailing-List: contact; run by ezmlm
Automatic-Legal-Notices: See

[-- Attachment #1 [details] --]
[-- Type: text/plain, Encoding: 7bit, Size: 1.4K --]

Ariel Berkman, a student in my Fall 2004 UNIX Security Holes course, has
discovered a remotely exploitable security hole in vilistextum, an
HTML-to-text converter. I'm publishing this notice, but all the
discovery credits should be assigned to Berkman.

You are at risk if you take a web page (or any other source that could
be controlled by an attacker) and feed it through vilistextum. (The
vilistextum documentation does not tell users to avoid taking input from
the network.) Whoever provides that web page then has complete control
over your account: he can read and modify your files, watch the programs
you're running, etc.

Proof of concept: On an x86 computer running FreeBSD 4.10, type

   gunzip < vilistextum-2.6.6.tar.gz | tar -xf -
   cd vilistextum-2.6.6

to download and compile the vilistextum program, version 2.6.6
(current). Then save the file 12.html attached to this message, and type

   src/vilistextum 12.html 12.txt

with the unauthorized result that a file named x is removed from the
current directory. (I tested this with a 540-byte environment, as
reported by printenv | wc -c.)

Here's the bug: In html.c, get_attr() reads any amount of data into a
32768-byte temp[] array.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
Comment 1 Sascha Silbe 2004-12-16 15:12:19 UTC
Created attachment 46170 [details]
Original file 12.html from advisory
Comment 2 Sascha Silbe 2004-12-16 15:14:45 UTC
Created attachment 46171 [details]
Modified exploit that works with 2.6.2
Comment 3 Matthias Geerdsen (RETIRED) gentoo-dev 2004-12-17 09:26:34 UTC
shell-tools pls verify/advise

Comment 4 Aaron Walker (RETIRED) gentoo-dev 2004-12-17 17:40:06 UTC
Well, unless I am doing something wrong (pretty hard when there's directions), I cannot reproduce this with either 2.6.2 nor 2.6.6 with the respective attached HTML.

I was, however, able to get 2.6.2 to segfault, but of course after recompiling with debugging flags, it doesn't segfault *sigh*.

I even tried reducing my env size to 540 with the same results.
Comment 5 Thierry Carrez (RETIRED) gentoo-dev 2004-12-20 05:58:49 UTC
vilistextum 2.6.7 is out :

shell-tools, please bump ebuild to that version.
Comment 6 Aaron Walker (RETIRED) gentoo-dev 2004-12-20 06:26:59 UTC
I was actually working on getting a working 2.6.6 ebuild last night, but found out some interesting stuff.  As of 2.6.4 (iirc), multibyte support *requires* libiconv which is pmask'd since some time in '03.
Comment 7 SpanKY gentoo-dev 2004-12-20 06:34:07 UTC
why does it require libiconv ?  iconv is part of glibc now
Comment 8 Aaron Walker (RETIRED) gentoo-dev 2004-12-20 06:57:57 UTC
iirc libiconv was a fork from glibc's iconv.  As to why it requires it, I haven't a clue.  The README explicitly states it as a requirement, and configure fails w/o it.  

I tried to see if it would build w/o it but it failed on a missing header, localcharset.h which is needed for locale_charset().
Comment 9 Aaron Walker (RETIRED) gentoo-dev 2004-12-20 07:07:36 UTC
Forgot to add, I also noticed that gettext provides a localcharset.h with that same function.  I tried to get it work last night, but I know nothing about gettext. I was able to get it to build using it w/o any warnings/errors but it fails every time with "setlocale failed with: yes"...  I didnt think it would work because gettext != iconv, but its the only thing that provides localcharset.h on my box.
Comment 10 Thierry Carrez (RETIRED) gentoo-dev 2004-12-21 07:03:42 UTC
Candidate: CAN-2004-1299
Reference: MISC:

Buffer overflow in the get_attr function in html.c for vilistextum
2.6.6 allows remote attackers to execute arbitrary code via a crafted
web page.
Comment 11 Patric Mueller 2004-12-22 18:17:32 UTC
Created attachment 46682 [details, diff]
Patch against 2.6.7 which enables use of glibc iconv
Comment 12 Patric Mueller 2004-12-22 18:30:53 UTC
Hi, i'm the author of vilistextum.

I've attached a patch that removes the requirement for libiconv and a few off-by-one errors.

I choose to *require* libiconv because it is the most portable iconv implementation. Although iconv(),iconv_open and iconv_close are standard, there are no canonical *names* for the encoding. And on Solaris, last time I looked, it couldn't convert from utf-8 to utf-8, because of the brain damaged way it implemented iconv.

Now I have looked at glibc iconv and it seems to at least have a reasonable way of defining encodings and aliases. The patch changes to to fall back to standard iconv when it can't find libiconv. The need for localcharset.h has been completely removed.

Aaron, I think you've made a mistake when running configure.
When vilistextum fails with "setlocale failed with: yes" that means you must have run it with "--with-unicode-locale=yes". You shouldn't use this option unless "configure --enable-multibyte" fails to automatically detect an utf-8 encoding and tells you to use it. 

For example "configure --enable-multibyte --with-unicode-locale=de_DE.utf8".

I'm sorry I have no gentoo installation so I can't supply the ebuild myself.
Comment 13 Aaron Walker (RETIRED) gentoo-dev 2004-12-23 02:47:19 UTC
> I've attached a patch that removes the requirement for libiconv and a few off-by-one errors.

Patric, I cannot fit enough "thank you"'s in this text box.  Getting 2.6.7 in the tree is my top priority this morning.

> When vilistextum fails with "setlocale failed with: yes" that means you must have run it with "--with-unicode-locale=yes".

doh ;p

> I'm sorry I have no gentoo installation so I can't supply the ebuild myself.

Don't be.  I already have the one I wrote for 2.6.6 (that of course didn't build ;p), that also includes support for kaptain (via USE=kde).

Once again, thanks.
Comment 14 Aaron Walker (RETIRED) gentoo-dev 2004-12-23 04:38:14 UTC
Ok, well this one has me quite confused...

FEATURES=maketest emerge vilistextum

causes two of the tests to fail because of vilistextum segfaulting.

#0  0xb7f12ee0 in _IO_sputbackwc (fp=0x814ef10, c=32) at wgenops.c:608
#1  0xb7f11ade in ungetwc (c=32, fp=0x814ef10) at ioungetwc.c:44
#2  0x080509ea in putback_char ()
#3  0x0804e445 in html_tag ()
#4  0x0804932b in html ()
#5  0x08050ce8 in main ()

both core's show the same stack trace.

When doing it manually (exactly as the ebuild would) it passes all 4 tests every time.  I also tried merging it w/o FEATURES=maketest and then editing the test scripts to run the one just installed; this also passed all tests.

anyone got any ideas?
Comment 15 Thierry Carrez (RETIRED) gentoo-dev 2004-12-28 12:41:54 UTC
Strange, no clue.
Comment 16 Aaron Walker (RETIRED) gentoo-dev 2005-01-01 11:34:54 UTC
I've just committed 2.6.7 to the tree; it is currently package.mask'd until we can figure out why it is failing half its tests because of segfaults (when it works fine when run manually).
Comment 17 Thierry Carrez (RETIRED) gentoo-dev 2005-01-01 14:12:06 UTC
x86, sparc: please test and see if you reproduce the Aaron's problem... If you do, any hint ? If not, please mark stable.
Comment 18 Patric Mueller 2005-01-02 00:31:17 UTC
Created attachment 47351 [details, diff]
enables use of glibc iconv and --disable-multibyte

On a fresh installation of gentoo on AMD Athlon I can't reproduce the two
segfaults. It compiles without an error.

USE="-unicode -kde" emerge vilistextum
fails because the configure script doesn't understand --disable-multibyte.

The patch fixes this, but you'll have to change the ebuild to apply the patch
Comment 19 Aaron Walker (RETIRED) gentoo-dev 2005-01-02 03:41:11 UTC

Ok, changed ebuild to apply patch regardless of USE flags.

That patch works with USE=-unicode but no longer the other way around.  USE=unicode produces the same original error I had with localcharset.h missing... Looking at the patch it looks like some stuff was reverted that the other patch fixed.

Also when testing, you did test with FEATURES=maketest, no?  I've patched vilistextum to only run the tests when that is set (removed it from the all target). Just wanted to be sure as you didnt explicitlu say so.
Comment 20 Patric Mueller 2005-01-02 10:53:18 UTC
Created attachment 47389 [details, diff]
enables use of glibc iconv and --disable-multibyte again

I made a mistake, I forgot to add the recursive option to the diff command.

The changes in the src directory weren't recorded. This patch has been better
Comment 21 Aaron Walker (RETIRED) gentoo-dev 2005-01-02 11:21:04 UTC
Ok, I've updated the patch in portage and now apply it regarless of whether unicode USE flag is enabled.  Still get the segfaults during the tests though, but I realized it only happens when USE=unicode.  All 4 tests complete successfully when USE=-unicode.
Comment 22 Aaron Walker (RETIRED) gentoo-dev 2005-01-02 11:23:25 UTC
Meant to also ask, can some other folks test it and see if they get segfaults with:

USE=unicode FEATURES=maketest emerge =app-text/vilistextum-2.6.7 (assuming you've unmasked it)

If noone else can reproduce it, then I'll unmask it.
Comment 23 Gustavo Zacarias (RETIRED) gentoo-dev 2005-01-03 12:18:17 UTC
Tests pass on sparc with unicode & -unicode.
However USE="kde" doesn't work since kde-misc/kaptain-0.71 doesn't build.
From what i've seen it doesn't like our current stable qt-3.3.3.
Revbumping to kaptain-0.72 solved that problem, but is yet to be included in portage (basically copy over the 0.71 ebuild and exclude the assert patch which was fixed upstream).
KDE team: i think we'll need kde-misc/kaptain-0.72 included quickly.
Comment 24 Olivier Crete (RETIRED) gentoo-dev 2005-01-03 22:56:15 UTC
Would it be possible to just disable the kde support to be able to mark it stable now? There is no stable version of kaptain on any arch. Apart fromt hat, I haven't tested the kde stuff since I dont even have qt here... but the rest seems to work ok.
Comment 25 Aaron Walker (RETIRED) gentoo-dev 2005-01-04 02:36:41 UTC
Ok, well it looks like I'm the only one getting those segfaults, so I won't worry about that.

I'm with Oliver on disabling kde support until a version of kaptain is stable.  I didn't even realize there wasn't a stable version available, or I would've left it out in the first place.

I'll get on this ASAP so we can finally close this bug.
Comment 26 Aaron Walker (RETIRED) gentoo-dev 2005-01-04 03:20:46 UTC
Stable on x86 and unmasked.  No other archs were previously stable.
Comment 27 Thierry Carrez (RETIRED) gentoo-dev 2005-01-04 03:50:42 UTC
Ready for GLSA
Comment 28 Gustavo Zacarias (RETIRED) gentoo-dev 2005-01-04 04:46:27 UTC
Eek! Careful grasshoper! sparc WAS stable before you retired the old ones...
Comment 29 Gustavo Zacarias (RETIRED) gentoo-dev 2005-01-04 04:58:26 UTC
Now it's sparc stable, and ready for GLSA.
Please *PLEASE* next time double check before retiring or going happy about it.
To get this out quick i had to break other stuff i was testing on sparc FYI, which are GLSA-related too (and one of those really long compile ones).
Comment 30 Aaron Walker (RETIRED) gentoo-dev 2005-01-04 05:41:37 UTC
I apologize but for what its worth I did cvs up and check.
Comment 31 Thierry Carrez (RETIRED) gentoo-dev 2005-01-06 13:38:21 UTC
GLSA 200501-10