Date:         Sun, 1 Apr 2001 00:08:50 +0200
From: Thomas Lopatic <thomas@LOPATIC.DE>
Subject:      ThomasBSD Security Advisory #1
To: BUGTRAQ@SECURITYFOCUS.COM

                   *** ThomasBSD Security Advisory #1 ***

                               Thomas Lopatic

                              April 1st, 2001


Introduction
------------

Having just found a serious security problem in the current release of
a core Internet service, I have decided to start working on my own
highly secure distribution of BSD, which will be called "ThomasBSD"
for obvious reasons.

Features of ThomasBSD
---------------------

ThomasBSD is based on OpenBSD, thus it is OpenBSD PLUS MORE,
mathematically making it (NetBSD PLUS MORE) PLUS MORE.

The epoch of ThomasBSD will be moved back from January 1st, 1970 to
January 1st, 1960. Whenever a security problem is found and fixed in
OpenBSD, this little shift will enable me to also correct the issue in
ThomasBSD and then send mail to security-related mailing lists stating
that "this was fixed in ThomasBSD about ten years ago."

In addition, ThomasBSD will, in a slightly different application of
the epoch shift, always be able to claim "Ten years without any local
or remote holes in any install, i.e. in the default install PLUS
MORE."

My original plan was to only provide binary releases of ThomasBSD, so
that I would not have to go through the efforts of hiding
security-critical changes in the CVS tree by inventing harmless
comments.

Still, as binaries can be reverse engineered, ThomasBSD releases will
only consist of the MD5 sums of the binaries. However, people actively
contributing to ThomasBSD will be able to obtain MD5 sums of the
source code.

This will ensure that no other operating system can copy any fixes
from ThomasBSD, and thus provide ThomasBSD with a USP, i.e. a unique
security position.

Obtaining ThomasBSD
-------------------

Binary releases will be regularly mailed to bugtraq. ThomasBSD 1.0 is

                  8e507e385887e487d3b6c600d09d1f23.

The mentioned security problem
------------------------------

This advisory will be the only time that I provide information on a
problem fixed in ThomasBSD that exceeds an MD5 sum of the diffs.

The problem is related to using isdigit() on user-supplied signed
characters without using isascii() first or type-casting the signed
character to an unsigned character or doing something similar.

Thus, the integer supplied as an argument to isdigit() may be
negative. If it is negative, the isdigit() function - depending on the
operating system's implementation of libc - potentially performs
look-ups outside its look-up table, since the provided integer is used
as an index for the look-ups.

It has to be noted that some implementations of libc use a construct
along the lines of

[...]

unsigned short table[256 + 128];
unsigned short *base;

[...]

    base = table + 128;

    if (base[input] & ISDIGIT_MASK)
        return TRUE;

    return FALSE;

[...]

together with a table in which table[x] == table[x + 256] to be
tolerant to sloppy coding and return the same values for the inputs of
-128 and 128, -127 and 129, -126 and 130, etc.

However, in vulnerable libraries isdigit() may return TRUE for at
least some negative inputs. As a further hint, consider the following
code snippet.

[...]

int i, v;
char in[MAX_INPUT_SIZE];

[...]

    for (i = v = 0; in[i] && isdigit(in[i]); i++)
        v = v * 10 + (in[i] - '0');

[...]

Also consider the fact that if the variable v was used as an index in
the program that this snippet belongs to, a programmer would typically
rely on v - having been calculated in the way described - being
non-negative and only validate the upper bound before using the index,
i.e. compare v to the number of elements in the array, as in

[...]

unsigned int array[ARRAY_SIZE];

[...]

    if (v >= ARRAY_SIZE)
        return -1;

    array[v] = [...]

The rest of the problem is left as an exercise to the reader. (Hint:
What happens if v is negative?)

Since vulnerabilities based on the described invalid use of the
isXXX() class of functions have up to now not been documented, I claim
the right of assigning this class of security problems a name, the
name of my choice being "giraffes". This will facilitate communication
among security experts as in

             "Cool, I've found a new giraffe in OpenBSD!"