Pete Finnigan's Oracle Security Weblog

I read Tom Kytes blog post from a couple of days ago titled "Messed up big time" about his own version of direct dictionary editing. Tom edited the repository of his own AskTom system and managed to blow it up. I posted the other day (Tom talks about direct dictionary editing) about this subject of direct dictionary editing as an issue not just for developers and DBA's to avoid - the consequences are obvious. I also talked about it because of the fact that hackers do not care about the rules that should be followed and also the consequences to your support contract, they may hack the dictionary to gain privileges or to hide their actions.

When I saw Tom's post I thought about it and the problem of editing the dictionary directly is not just a problem of Oracle's dictionary but also a problem of any piece of software that includes its own dictionary/repository/configurations - If a general user or developer or DBA is allowed to access and hack your own applications repositories (include third party apps in this) then just as much havoc can ensue. But importantly the same hackers who may want to gain privileges in the database or hide actions or alter the functionality may do the same to your applications for the same reasons.

To this end ensure that no user has access to hack repositories, ensure audit is in place, ensure recoverability if they do manage to hack it. But also ensure that there are checks in place to confirm the integrity of your own repositories. A similar method to that used in repscan can be employed. That is checksum the source code of the API and programs used to access the repository. Deciding how to protect your own repositories will be dependant on their design, structure and use but combinations of controlling access, audit and check summing can be used.