bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

sharutils: various uudecode bugs


From: Eric Blake
Subject: sharutils: various uudecode bugs
Date: Sat, 10 Sep 2005 12:37:21 -0600
User-agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)

I've taken a closer look at uudecode, and spotted several bugs and standards issues:

read_stduu, read_base64, decode: arbitrary limitation, by using a fixed length buffer. Although well-formed uuencode coded output always fits within this buffer, an arbitrary-length filename may make the begin line exceed the buffer, and it is not robust to malicious input. Furthermore, POSIX states that input files are not necessarily text files since arbitrary data and line lengths may proceed the embedded uuencode section. We should probably be using gnulib's getline here.

decode: POSIX only states that the input file contain output from uuencode, not that the encoded data begins immediately after a newline character. Maybe it is worth asking for a standard's interpretation as to whether arbitrary characters can proceed the "begin" on the first line of the encoded data.

decode: POSIX requires uudecode to parse both octal AND symbolic mode, but the GNU uudecode currently fails on symbolic modes.

main: When using the GNU uudecode extension of parsing multiple filenames, the -o option no longer makes sense (you end up decoding multiple source files into the same destination, destroying data from all but the last filename argument). Since multiple filenames is an extension, you should reject attempts to use -o if more than one file is specified.

decode: GNU uudecode attempts to do ~ expansion, which is allowed by POSIX since ~ is not part of the portable filename character set. However, it may be worth considering extensions to uuencode and uudecode that encode non-portable filename characters in such a manner that uudecode can recreate any valid filename (within the limits of the filesystem it is expanding onto).

decode: If the output file already exists and is a FIFO or symlink, GNU uudecode fails, although POSIX requires that a FIFO be opened for writing and a symlink be followed.

all over: uudecode should be careful to use binary mode ("rb" instead of "r" for fopen, for example), on systems where it matters.

--
Someday, I might put a cute statement here.

Eric Blake             address@hidden





reply via email to

[Prev in Thread] Current Thread [Next in Thread]