As I talked about in part 1, Livelink Enterprise Server security is really two distinct things: the Interpreter of Oscript (dealt with in Part 1) and Oscript itself which I'll speak to now. While I did speak to XSS and XSRF in part 1, the truth is that this is security that is part of the Oscript domain, not the that of the interpreter itself.

Oscript is a very complete programming language, it offers a number of abstractions (or Application Programming Interfaces) like CAPI (the connection API) and DAPI (the Database API) that, when used, provide a great deal of security to the program authors. Unfortunately, while both interfaces are very useful and their use is recommended there is no enforcement and it is possible for Oscript developers to bypass these abstraction layers and while such bypassing doesn't in and of itself lead to privilege escalation, it does remove much of the programming assistance that (for instance) helps to ensure there are no SQL injections possible.

The actual security of Oscript itself is beyond the scope of this article -- suffice it to say that on balance it is a pretty good language ensuring (for instance) that buffer overruns are not possible. The problem with Oscript isn't so much the language, it is that there is no way to really know if the Oscript you believe you have installed is actually the Oscript you have installed. That is, there is no automatic verification process today that allows Livelink administrators to know that they have the Oscript code they think they do. Open Text does not currently offer any data integrity services; the only option an administrator has is to download the most recent release of the Livelink code (and any and all modules) and compare against the ones installed.

Of course, smart and/or paranoid administrators can and probably should deploy server-based techniques like using Tripwire(tm) or some other file integrity checker -- knowing that Oscript files should not change except when a Livelink Administrator performs a module upgrade, any changes found are a red-flag security event.

This same approach can and should be used for the "patches" directory because patches will override any pre-existing Oscript code. In fact, this is one of the biggest security issues within Livelink (along with one of it's most powerful features) .. every single Oscript function can be overwritten (overloaded) subverting security measures and peforming unauthorized actions. It is very difficult to ascertain that this will have happened, there is no indication within LES that any function has been overridden in this manner.

It is this author's opinion that Open Text should have solved this problem long ago, offering PKI-based fingerprints of Oscript modules and any patches. In fact, the entire approach of updating and patching LES is quite out-dated by today's methodologies ... it is designed for the benefit of Open Text rather than the benefit of the administrators of Livelink. I think this is a ticking time bomb for Open Text ... as they get bigger there will be more people looking to exploit the application and, the truly scary part for some, there are some users of Livelink that do put very valuable information (from state secrets to Intellectual Property) worthy of a sophisticated cyber-attacker. While most (if not all) of such sites today are run by IT shops that already know how to protect their services (such that the Oscript / patch integrity checks above are in place), IMO it is only a matter of time before a high-security Livelink site is hacked into using an insider (knowingly or not) as the main weakness to exploit.