DirList2 Server - Fixed Bugs
| Bug | Description |
| Numerous
cross site scripting (XSS) vulnerabilities |
Inserting HTML syntax into searches
and data could lead to the injection of arbitrary HTML commands, including
scripts. Fortunately, version 2.9 fixes HTML and JavaScript injection
scenarios in the data, search parameters, and status/error messages.
Performance is maintained in the new HTML and JavaScript escaping functions
by allocating memory from a shared global string only when the function
finds that escaping is required. |
| High
number of searches can use up large amounts of system resources |
If a web user maliciously sets
the number of searches in a query (ns) to a very high value, such as
38943489, dirlist2.cgi would allocate memory slots for each search,
taking up memory and CPU time unnecessarily. As of DirList Server 2.8,
the number of searches has a hard limit of 10,000, which does not use
up much memory or CPU and should cover many standard deviations from
the normal number of searches. The hard limit can be changed in
src/web.h and dirlist2.cgi recompiled if you really want to change it. |
| Potential
buffer overflow scenarios |
The code in version 2.7 was
extensively checked for buffer overflow vulnerabilities. No
remotely-exploitable holes were found, though a very long local
username could potentially overflow one of the buffers during an index
update. As a part of the security audit, version 2.8 uses safe string
manipulation functions or, in the one case where an unsafe string
function is used, is 100% sure about the buffer's allocation. If you
compile DirList Server on a platform that lacks safe string functions,
it will revert to the old code but will throw compile-time warnings.
DirList Server 2.8 is considered safe. |
| Files
from one CPU endian type would cannot be read by another CPU endian type |
Version 2.8 can now properly
import index files from a different CPU endian type automatically and
transparently. |
| Warnings
regarding assigning a 64-bit pointer to an unsigned integer when
compiling on a 64-bit platform |
DirList Server 2.8's code is now
64-bit friendly and will work on both 32-bit and 64-bit systems in
their respective modes. Currently, though, the 4GB index file size
limit remains in effect even on 64-bit systems, which might change in a
future release. |
| User
Levels between Users was not foolproof |
Previous to DirList Server 2.8,
the User Level property in a database User was loosely enforced and was
not locked down to cover all bases. Version 2.8 addresses this by
enforcing the original intent behind User Levels so that only those
with a higher User Level number can be edited by a User with a lower
User Level. Special rules around who can change what were also
implemented as well as a fail-safe mechanism for the Administrator to
ensure that no User change can lead to a loss of database editing
abilities as long as the Administrator password is known. |
| FLAGS_NOTELEPHONE not set | When updating an index, any new users added to the index did not have FLAGS_NOTELEPHONE flag set, meaning that searches to find people with a telephone number would return these new users even though they don't get a phone number automatically during an index update. This existed in all versions of DirList Server below 2.6. This bug was fixed in version 2.6. |
| Segmentation fault in search | If you tried to search extended data fields using a string and if some entries used ordinal values that pointed to an unknown class value, a segmentation fault could occur. This was fixed in version 2.3d. |
| Extra newlines in extended data | If you requested the string representation of extended data and if a directory entry did not contain data for that classification while the default value for that classification pointed to a non-existent value, the server erroneously returned three extra newlines in the data stream along with an error message. When DirList Server was modified to create DirList2 Server, this message was apparently overlooked. If you used the DirList2ODBC driver, the driver might report an invalid message type or an error about not being able to read the message type. After the extra newlines were removed, the server behaved correctly under the conditions above. This fix first appeared in version 2.3c. |
| Class corruption | When setting an "other" value to a directory entry that already has a numeric value assigned for that classification, the value that was associated with the old numeric value either got set to four bytes of garbage or got set to the new "other" value that you are trying to assign to a specific directory entry. This was caused by freeing memory based on a condition that relies upon the flags for the extended data. Because the flags were already set to new values, the memory freeing routine assumed that the previous pointer was "owned" by the directory entry when it really was not. The memory freeing routine now checks the previous value of the variable by using another one that contains the original value. This fix was applied in DirList2 Server 2.3b. |
| Error deleting first class | When deleting the first data classification group, DirList2 would crash just before the operation took place. At no time was the index file in danger of corruption, since the crash took place well before the server opened the file for writing. This was caused by a couple of typos in the source code that caused the routine to use two undefined pointers. This bug was fixed in DirList2 Server 2.3b. |
| Flag update bug | When setting or clearing one or more flags using a search on Directory Entries, the ModifyEntriesToMatchOne() function did not implement the FLAG_SETREMOVE feature at all, instead using only the first parameter in a SETREMOVE pair as a full REPLACE. As a result, any flags that were not updated were set to zero. This bug was fixed in DirList2 Server 2.3. Note that updates to specific records that do not use full searches use ModifyEntries() and thus were updated correctly as the ModifyEntries() function already implemented FLAG_SETREMOVE. |
Copyright (c) 2000, 2002, 2004, 2007 Steven Lawrance
Copyright (c) 1999-2000 Bryant College
Written by Steven Lawrance
DirList2 Server Version: 2.9
Last Revision: 08-04-2007