Tiplet: DO NOT USE the # symbol in Oracle Enterprise Communication Broker passwords!

I've been working with Oracle Session Border Controllers and Enterprise Communications Brokers a lot recently, A couple of weeks ago I encountered what I think is a new - and quite serious - bug (it's with Oracle for investigation) regarding how the devices *mis*handle special characters. If you admin ECBs or SBCs and are planning to change their credentials to include non-alphanumeric characters, read this first.

I've been working with Oracle Session Border Controllers and Enterprise Communications Brokers a lot recently, and I encountered what I think is a new bug (it's with Oracle for investigation).

After deploying some new ECB instances, I changed the login and enable passwords, per the Oracle ACLI guide ("secret login" and "secret enable" at the SSH prompt). I used randomly generated strong passwords which included limited special characters -- "#", "%", "?" and "!".

The ECB appliances use two passwords per username - one to log on to the unit, and one to 'enable' (admin mode for configuring them, similar to Cisco's enable mode).

On one appliance, the new password I generated for it was accepted without complaint when typed and retyped at the confirmation prompt. However, attempting to then authenticate a new session using this password resulted in immediate refusal by the appliance. It effectively denied access, with no recovery method. I had to flatten and redeploy the appliance!

After I was locked out, I tried all sorts of alternatives, seeing if the password had been partially saved or corrupted - seeing whether the password was truncated at the # symbol, whether the appliance replaced it with a space character, whether it omitted the # symbol when it committed it to memory, or whether it simply swapped it for another character. I must have tried a dozen or so possible variants before giving up.

Despite the documentation saying "do not use special characters", one normally expects a password change routine to immediately reject any invalid special characters on submission using string validation. This isn't a new concept. However, the ECB appliances seem to happily accept invalid characters, even though one of them causes a service-affecting bug.

I've previously set passwords including !, ? and % characters -- those are in use on other ECB appliances using the same software revision (and SBCs) and they work fine. I have only encountered this problem so far using # symbols.

I see conflicting information about acceptable non-alphanumeric symbols in passwords in the Oracle documentation. However, the fact that simply entering a # symbol as part of a new password when updating credentials can lock you out of admin access on a production system seems pretty bad.

I can reproduce the fault with a fresh OVA deployment of ECB PCZ2.2.0 GA (Build 53), so this seems like a serious bug which can end up with an administrator permanently and irreparably locking themselves out of their own system. I'm only glad I was setting the passwords prior to deploying a configuration!

If you're working with Oracle ECBs or SBCs, be very careful about which special characters you use in your strong passwords.

Leave a Reply

Your email address will not be published. Required fields are marked *

Notify me of followup comments via email. You can also subscribe without commenting.

I