Pete Finnigan's Oracle Security Weblog

Alex emailed me this morning to let me know that he had put his 4 security advisories on his website this morning. These are for 4 bugs he found in Oracle's products that have been fixed in the CPU July 2005 patch set released yesterday. Alex's Published Security Alerts page lists all 4. The bugs are:

"Oracle JDeveloper passes plaintext password" :- This bug is low risk and involves password and username leakage when a program such as SQL*Plus is started externally. The advisory gives an example and a workaround - do not start SQL*Plus from JDeveloper.

"Oracle JDeveloper Plaintext Passwords" :- This bug is low risk and involves un-encrypted database passwords being leaked from three configuration files - IDEConnections.xml, XSQLConfig.xml and settings.xml - Alex gives examples of all three.

"Oracle Forms Builder Password in Temp Files" :- Again this is a low risk bug and involves a bug where Formsbuilder creates temp files that contain the current database username and password for the connection used. When formsbuilder is closed these files are not deleted. Alex points out the bug was introduced as part of a fix for a previous bug (clear text passwords in the Apache log file). Again Alex gives an example and a workaround. The Workaround is to set the environment variables TMP, TEMP and TMPDIR to a secure location and delete the temp directorys on a regular basis.

"Oracle Forms Insecure Temporary File Handling" :- This bug is a medium risk one and involves a data leakage issue in Oracle Forms. If the number of records returned is greater than the parameter buffered records then Oracle stores the fetched records locally in a file on the application server. The records are stored un-encrypted (assuming they were encrypted) and the file permissions on the files created allow any Unix user to read the contents. Alex again gives an example and also suggests a workaround. This is to set the environment variables TMP, TEMP and TMPDIR to a secure location and to delete the temp files created on a regular basis.

Again each bug has a time to fix detail added. The shortest is 148 days for three of them and a horrendous 693 days for the Forms unsecured file handling issue. This is quite unsatisfactory for the finder of the bugs (Alex in this case) and also for customers of Oracle's Forms product. It is unacceptable that a security bug remained unfixed for almost 2 years.

Considering there is a large list of unfixed Oracle bugs on Alex's site (35 bugs) and on Esteban Mart�nez Fay�'s site (100+ bugs) plus some on others sites such as NGS Software's (17 bugs) I think Oracle need to seriously look at quickly fixing these outstanding bugs. Many security researchers are most likely aware of what they are and most probably a lot of other people as well. A lot of these bugs are checked for in vendor�s products and also are subject to advanced vulnerability notification services (under an NDA) from others. Just from these three sites there are 152 outstanding Oracle security bugs, quite a lot of them for a long time. Maybe it is time some of Oracle's big customers who demand the highest levels of security from vendors should start to ask Oracle about when these outstanding bugs will be fixed?