SNAP Innovation's PrimeBase Database 4.2 poor default file permissions and
use of symlinks during install.
September 1, 2003

I. BACKGROUND

>From the readme.txt file

"The PrimeBase Database Server is a relational Database Management System
(DBMS) for Mac, UNIX and Windows platforms. The PrimeBase Database Server
supports all common database access standards (PBT, SQL, ODBC, JDBC, PHP,
Perl, RealBasic, EOF and DAL) and protocols (TCP/IP, Shared Memory and
Appletalk)."

II. DESCRIPTION

1. Poor use of temporary files during installation.

I noticed the PrimeBase install script creates the following files in
/tmp:

[nobody $] ln -s /etc/shadow /tmp/PrimeBase.log

Then if a malicious user has previous knowledge of the administrators
installation of PrimeBase the contents of /etc/shadow will be overwritten
with the contents of PrimeBase.log.


LOG="/tmp/PrimeBase.log"
echo "$str:[y/n]" | tee $LOG
echo "PrimeBase Installation: $now" >> $LOG

2. Poor default file permissions.
A malicious local user could manipulate the binaries for PrimeBase used by
the administrator and execute arbitrary code. The attacker would need to
wait until the Database was restarted or the system rebooted.

root@Fester <mailto:root@Fester> local]# ls -ld /usr/local/primebase
drwxrwxrwx 6 root root 4096 Sep 1 13:57 primebase

These types of vulnerabilites seem to be common with the database crowd.
I am hoping that soon developers will notice and start thinking more about
local application security during and after installation.

III. ANALYSIS

Local attackers can exploit these vulnerabilities to clobber root owned
system files and modify software binaries. This could possibly lead to a
denial of service or system compromise.

IV. DETECTION

PrimeBase Data Server Build 4212.
<http://www.primebase.com/en/index.html>

V. WORKAROUND

1. temp file vulnerability.

Boot the system into single user mode only and ensure no other users are
logged in during installation.

2. Default file permissions.
Change directories to more restrictive ownerships (untested).

VI. VENDOR FIX

Vendor will fix issues in next release.

VII. CVE INFORMATION

The Mitre Corp.'s Common Vulnerabilities and Exposures (CVE) Project
has not assigned an identification number to this issue.

VIII. DISCLOSURE TIMELINE

9/16/2003 Issue disclosed to Vendor.
9/26/2003 Response from Vendor, next version will be fixed.

IX. CREDIT

Larry W. Cashdollar (<http://vapid.dhs.org>) discovered this vulnerability.