Category Archives: Security

Oracle passwords and special characters

As commonly known passwords should have a certain complexity. Thereby it is common to use special characters, numbers, lower and uppercase characters. Depending on the type of special characters Oracle require that the password is enclosed in double quotation marks. Oracle does provide a guideline for Securing Passwords in the Oracle® Database Security Guide. So far so well, depending on the applications or Oracle clients the enclosing doesn’t really work as expected. Some Special characters like a $ or % are used to indicate an environment variable, other special characters like /, [] or @ are used to build the connect string. But a really nasty special character is the backslash respectively the \. The backslash is in general used as escape character to change subsequent literal characters into metacharacters and vice versa. The use of the backslash in an Oracle password has some very interesting side effects :-).

Ok, lets create a test user with a complex password and a backslash \ somewhere in the password.

SQL> conn / AS sysdba

USER created.


GRANT succeeded.

SQL> conn smith/KT20\dft


SQL> conn smith/"KT20\dft"


SQL> conn smith/"KT20\dft"@TDB11


SQL> conn smith/KT20\dft@TDB11

To create the user I’ve used the double quotation marks to enclose the password. As you can see, the attempts to log on to the database have worked in any case. In contrast to the login, alter the password definitely requires some quotation as you can see below.

ERROR at line 1:
ORA-00911: invalid CHARACTER

Ok, lets put the backslash at the end of the password and try to login again.


User altered.

SQL> conn smith/KT20dft\

SQL> show user
USER is "

SQL> conn smith/"
SP2-0306: Invalid option.
Usage: CONN[ECT] [{logon|/|proxy} [AS {SYSDBA|SYSOPER|SYSASM}] [edition=value]]
where <logon> ::= <username>[/<password>][@<connect_identifier>]
      <proxy> ::= <proxyuser>[<username>][/<password>][@<connect_identifier>]

SQL> conn smith/"
SP2-0306: Invalid option.
Usage: CONN[ECT] [{logon|/|proxy} [AS {SYSDBA|SYSOPER|SYSASM}] [edition=value]]
where <logon> ::= <username>[/<password>][@<connect_identifier>]
      <proxy> ::= <proxyuser>[<username>][/<password>][@<connect_identifier>]

SQL> conn smith@TDB11
Enter password: ********
SQL> show user
USER is "

SQL> conn smith/KT20dft\@TDB11
ORA-01017: invalid username/password; logon denied

Warning: You are no longer connected to ORACLE.

As you can see above, the Login no longer works so smoothly. Using the username and password without any quotation does work. Any other combination with quotation or the connect identifier does not work any more. In these cases the backslash does behave as a escape character. Mmh, in this case it should be possible to escape the backslash with a second backslash isn’t it?

SQL> conn smith/"KT20dft\\"
ORA-01017: invalid username/password; logon denied

No, doesn’t work. So far I have found no way to use the backslash at the end of a password, unless the password is entered interactively. For an administration tool like SQLPlus, SQL Developer etc which is anyway used interactively it isn’t a problem. But if you would like to setup batch jobs, RMAN backup’s etc it does not work.

Recovery Manager: Release - Production ON Tue Jun 12 08:33:43 2014

Copyright (c) 1982, 2011, Oracle AND/OR its affiliates.  ALL rights reserved.

RMAN> CONNECT target *
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-10000: error parsing target DATABASE CONNECT string "sys/"KT20dft\"@TDB11"

RMAN> run
2> {
4> allocate channel ch1 TYPE disk;
5> backup CURRENT control file;
6> }
USING target DATABASE control file instead OF recovery catalog
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure OF allocate command at 06/12/2014 08:33:43
RMAN-06171: NOT connected TO target DATABASE


It is still highly recommended to use complex passwords. Although Oracle supports all types of multi-byte characters, it is useful to test some special characters before these are used in passwords. Not everything always works as you expect.

Update: AVDF installation fails on HP server with Smart Array

A couple of days ago I’ve wrote about some problems when installing Oracle Audit Vault and Database Firewall 12.1.2 on HP server with Smart Array Disk Controller. The problem is still not resolved, but in the meantime Oracle has open a Bug and added some Metalink Notes related to this issue.

  • AVDF 12.1.1 Installation Fails On HP server with Smart Array Disk Controller [1587742.1]
  • Unable To Install AVDF Server With HP Smart Array [1680134.1]
  • AVDF installation ISO [1680961.1]

The contents of MOS note 1680134.1 and 1680961.1 are certainly known to the regular readers of OraDBA. The workaround and procedure are the same as I’ve posted a couple of days ago. Oracle created MOS notes based on my blog post AVDF installation fails on HP server with Smart Array Disk Controller and AVDF installation ISO. In this case, my posts are somehow useful. 🙂 The Bug mentioned above is unfortunately not publicly available. I’ll provide more information as soon as it is available.

AVDF installation fails on HP server with Smart Array Disk Controller

I’ve successfully set up a couple of AVDF installation on different VM Server as well on HP Blade or Rack servers. On the VM server I never had any problems. For the installation of AVDF 12.1.1.x on HP servers BL465c Gen8 or DL380p Gen8, there were always warnings during partitioning of the disks. So far it was never an issue to just continue the installation. With AVDF 12.1.2 this has changed. On some HP servers with smart array disk controller the installation fails because of problems with the drivers respectively device names.

Earlier installation of AVDF like simply complained about not enough space.


OK, 0GB is a bit less for setting up an AVDF Server :-), nevertheless ignoring the error still worked. AVDF as well AVDF could be successfully setup using the cciss Driver for HP Smart Array. As of AVDF 12.1.2 the error is not that friendly any more.


The title of the error “Error Parsing Kickstart Config” indicates that there is an issue at an early stage of the system setup. It is worth having a deeper look into the kickstart configuration file. The kickstart file can be found in the initrd.img image on the AVDF installation ISO. See AVDF installation ISO for how to extract the kickstart file.

In the kickstart file we can see at line 62, that a pre-script is executed to create the partition commands. This pre-script is a python script which does create a temporary file (/tmp/partition-include) with the partition commands based on the available disks. The partition command itself is then included at line 36.

########## Partition the disk ##############
%include /tmp/partition-include

# Create logical volume group - this is where all volumes will reside
volgroup vg_root pv.01
# Now create the volumes, a.k.a logical partitions. The data partions (/var/lib/oracle) is grown
# up to the specified size. The rest of the FS is left unallocated.
# You must make changes to ruby_lib/dbfw/dbfw_fstab.rb if you change the FS specification.
logvol swap --fstype swap --vgname=vg_root --size=4096 --name=lv_swap
logvol / --fstype ext3 --fsoptions="noatime" --vgname=vg_root --size=7000 --name=lv_root
logvol /images --fstype ext3 --fsoptions="noexec,nodev,nosuid,noatime" --vgname=vg_root --size=15000 --name=lv_images
logvol /usr/local/dbfw --fstype ext3 --fsoptions="noatime" --vgname=vg_root --size=1000 --name=lv_local_dbfw
logvol /usr/local/dbfw/tmp --fstype ext3 --fsoptions="noexec,nodev,nosuid,noatime" --vgname=vg_root --size=9000 --name=lv_local_dbfw_tmp
logvol /home --fstype ext3 --fsoptions="noexec,nodev,nosuid,noatime" --vgname=vg_root --size=1000 --name=lv_home
logvol /tmp --fstype ext3 --fsoptions="nodev,nosuid,noatime" --vgname=vg_root --size=2000 --name=lv_tmp
logvol /var/log --fstype ext3 --fsoptions="noexec,nodev,nosuid,noatime" --vgname=vg_root --size=6000 --name=lv_var_log
logvol /var/tmp --fstype ext3 --fsoptions="noexec,nodev,nosuid,noatime" --vgname=vg_root --size=6000 --name=lv_var_tmp
logvol /var/www --fstype ext3 --fsoptions="nodev,nosuid,noatime" --vgname=vg_root --size=1000 --name=lv_var_www
logvol /var/www/tmp --fstype ext3 --fsoptions="nodev,nosuid,noatime" --vgname=vg_root --size=1000 --name=lv_var_www_tmp
logvol /var/lib/oracle --fstype ext3 --fsoptions="noatime" --vgname=vg_root --size=20000 --name=lv_oracle
logvol /var/dbfw --fstype ext3 --fsoptions="noatime" --vgname=vg_root --size=10000 --name=lv_var_dbfw

# Tasks performed before installation

python /kickstart/ 2&gt; /tmp/partitions_error
if [ $? -ne 0 ]; then
DISKERROR=$(/bin/cat /tmp/partitions_error)

Having a look into the file /tmp/partition-include reveals the wrong partition command which leads to the error mentioned earlier. As you can see below the disks are specified with –ondisk=cciss!c0d0 rather than –ondisk=cciss/c0d0. The python script which builds the partition commands, has issues with the device names. Actually, for an HP smart array disk, the corresponding driver should be loaded so that the devices are visible as sd*. The root cause could be the missing driver or an error in the python script. I’ve opened a service request with oracle Support for further analysis.


For the moment I just see the following two workarounds.

  • First install and configure AVDF and perform an upgrade to AVDF 12.1.2.
  • Install AVDF 12.1.2 with an alternative kickstart file respectively partition commands

The first workaround is straightforward. It just takes a bit more time. For the second workaround you may create a new AVDF ISO image, but this is way to complex. It is much simpler to manually specify the boot options and provide an alternative kickstart file on an internal web server. The kickstart file is the same as for the regular AVDF 12.1.2 installation, it just has a fixed partition section. For that I have taken the partitioning commands from the file /tmp/partition-include and removed the –ondisk parameter. I’ll provide my kickstart file as an example for download. But do not use it directly the partitioning section must be adapted to your environment.
Action plan for the workaround:

  1. Create an alternative kickstart file with correct partition commands for your environment
  2. Put the kickstart file on a Webserver which is accessible by the AVDF Server
  3. Boot from AVDF 12.1.2 ISO image with custom boot parameter

My custom boot option did look like the following command. The IP address is the address of my web server.

vmlinuz noipv6 initrd=initrd.img ramdisk_size=8192 ks=


This problem is quite annoying, especially if you have already done the installation on another physical or virtual servers several times. The workaround is basically simple. With a bit enhanced Linux knowledge and a web server, one has quickly created an installation with an alternative kickstart file. Nevertheless I highly recommend to open a service request with Oracle when you have similar issues with your hardware during the setup of a productive AVDF 12.1.2 environment.


Further information on this topic.

Audit Vault and Database Firewall 12.1.2

Oracle has just released a new Release of its Oracle Audit Vault and Database Firewall. The new release is immediately available on Oracle’s Software Delivery Cloud. It look’s like Oracle added a bunch of Enterprise-Grade Features like iSCSI SAN Disk, NFS Storage as well as SYSLOG integration. Starting with this Release, the Audit Vault Repository is again protected by Database Vault.

The installation / update is done in the same manner as the other versions AVDF. Download the ISO, reboot the AVDF server and initiate an upgrade. But be carefully to not initiate an installation. This would erase your system and data.

A bit unusual that the ISO image was split into two parts. They have to be merged prior to use.

  1. Unzip Images avs-installer-disc-, avs-installer-disc-
  2. Combine the two files to create a single .iso

Combine the two files to create a single .iso on Windows:

copy /b avs-installer-disc-

Combine the two files to create a single .iso on Linux:

cat avs-installer-disc- \
avs-installer-disc- > avs-installer-disc-

Oracle Audit Vault and Database Firewall 12.1.2 New Features

According to the Release Notes, the following features are available as of 12.1.2:

  • Configure the Audit Vault Server to use an external iSCSI SAN server to store the audit event repository and system data
  • The Audit Vault Agent is updated automatically when the Audit Vault Server is upgraded or a patch is applied
  • Store archive data in a Network File Share (NFS) location
  • Entitlement reports include data specific to Oracle Database 12c
  • Database Vault is automatically enabled and configured in the Oracle Database embedded in the Audit Vault Server. This further strengthens security by restricting privileged access to the Oracle Database for all users including those with administrative access
  • Password hashing has been upgraded to a more secure standard. Change your passwords after upgrade to take advantage of the more secure hash
  • The Audit Vault Agent deployment procedure has been simplified. Registering a host in the Audit Vault Server automatically generates an Agent activation key, and therefore, the step requesting Agent activation is no longer required
  • Adding and updating a secured target location has been simplified in the Audit Vault Server administrator console UI
  • Define policy alerts to be forwarded to syslog
  • Download diagnostics log files from the Audit Vault Server UI
  • The Audit Vault Agent is supported on 32-bit Linux and Windows platforms
  • Oracle Database 9i is supported for Database Firewall
  • MySQL 5.6 is supported on the Database Firewall
  • Migration Path to Migrate Oracle Audit Vault 10.3 to AVDF 12.1.2. See MOS Note 1666742.1


Some links related to this post.

As soon as the download of the images is done, I’ll start to test the new release on my test AVDF Server. So stay tuned…

Update: Oracle and OpenSSL ‘Heartbleed’ vulnerability

While writing a post about the new Critical Patch Advisory I’ve discovered, that Oracle made the Information about the OpenSSL Vulnerability publicly available. The information in MOS Note 1645479.1 has been moved to OpenSSL Security Bug – Heartbleed CVE-2014-0160.

Until now it looks like that Oracle Databases are not affected since they do not use OpenSSL. On the other hand products like Oracle Wallet Manager and EM Base Platform are still under investigation. We’ll know more once Oracle has completed its investigations.

Oracle released CPU / PSU April 2014

As announced last week in my post Oracle CPU / PSU Pre-Release Announcement April 2014, Oracle has now released the Critical Patch Updates for April 2014. Overall this CPU contains 104 new security fixes across several Oracle products like Database Server, MySQL Server, Sun Product Suite, WebLogic Server etc. For Oracle Database it contains only 2 security fixes, whereas one of the fixes has a very high CVSS rating. But this only affects installations on Windows. On these platform it is recommended to install the patch bundle as soon as possible. Nevertheless it is certainly advisable to install the patches on Unix/Linux-based systems

As somehow expectable, Oracle did not add any information about the OpenSSL issue to it’s current Critical Patch Advisory. I assume this is because the vulnerability was announced a few days ago. As discussed in my post Oracle and OpenSSL ‘Heartbleed’ vulnerability, Oracle is tracking information about this issue in MOS Note 1645479.1 OpenSSL Security Bug-Heartbleed.

CPU Release Dates

The next four Critical Patch Updates will be released at the following dates:

  • 15 July 2014
  • 14 October 2014
  • 20 January 2015
  • 14 April 2015


As usual there are a bunch of links and MOS Notes around the critical patch update available:

  • Oracle Critical Patch Update Advisory – April 2014
  • Patch Set Update and Critical Patch Update April 2014 Availability Document [1618213.1]
  • Oracle Critical Patch Update April 2014 Documentation Map [1637289.1]
  • Critical Patch Update April 2014 Database Known Issues [1615881.1]
  • Critical Patch April 2014 Database Patch Security Vulnerability Molecule Mapping [1615882.1]
  • Critical Patch Update April 2014 Oracle Fusion Middleware Known Issues [1618208.1]
  • Oracle Critical Patch Updates and Security Alerts on OTN

Oracle and OpenSSL ‘Heartbleed’ vulnerability

Earlier this week the OpenSSL Project as well US-CERT informed about a Security Vulnerability in OpenSSL. See OpenSSL Security Advisory or US-CERT Alert (TA14-098A) The vulnerability may affect Oracle Products as well, since some of them do use OpenSSL. So far Oracle did not provide dedicate information on it’s public Critical Patch Updates and Security Alerts web page. But there is a MOS Note 1645479.1 OpenSSL Security Bug-Heartbleed, which contains a list of affected products. It seems to get regularly updated. Nevertheless you have to open a service request to get information on possible workarounds or get a patch.

Fortunately not all products always use the latest versions. Thus, in Oracle Audit Vault and Database Firewall still OpenSSL 0.9.8 in use.

[support@melete ~]$ openssl version
OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008


Some links related to the OpenSSL Heartbleed issues.