resources

December 4, 2003 – Caché Server Pages

Caché ships with a number of components designed to facilitate rapid application development. These include a collection of sample Caché Server Pages which illustrate a variety of programming techniques. These CSP samples are not needed for a Caché Server in a application deployment environment, and could be used by an attacker to compromise a Cache Server hosting them. InterSystems recommends that these CSP samples be disabled in a production environment by selecting

Configuration Manager -> CSP -> Applications -> /csp/samples

and clicking on “Remove”. The sample files can optionally be deleted by deleting the “CSP\samples” directory and all its subdirectories.

Also note that the patch file

ftp://ftp.intersystems.com/pub/cache/old/PatchProdlog34606.zip

first released in conjunction with the alert of November 14, 2003, was updated on November 20, 2003. Customers who installed that patch prior to November 20 are advised to re-apply it.


November 19, 2003 – Caché Backup Error and Lost Updates

A defect has been corrected which causes an access violation during Caché full backup if the size of the database being backed-up is a multiple of 488 MB. Caché incremental backup is not at risk.

There are two side effects to this error:

  1. Caché 5.0-5.0.3. Any database updates after the error occurs will not be written to the database due to write daemon suspension. This side effect occurs only when all databases included in the backup list are 8K-block size and are not cluster mounted. Otherwise, the side effect is that a switch (switch 13) is not cleared and updates are blocked until the switch is cleared manually.
  2. Caché 4.1-4.1.15. A switch (switch 13) is not cleared after the error occurs and updates are blocked until the switch is cleared manually.

If you suspect either of these situations please contact the Worldwide Response Center immediately as it may be possible to clear the problem without restarting Caché.

In all cases, if journaling is enabled, journaling continues normally so that updates are preserved and uncommitted updates will be applied to the databases by the journal recovery mechanism when Caché is restarted.

In all cases the backup should be discarded.

All hardware and operating system combinations are at risk. Only Caché 4.1-4.1.15 and Caché 5.0-5.0.3 are affected by this defect.

The recommendation is to upgrade to 4.1.16 or 5.0.4 to correct this defect. The correction is identified as LRS685.

If you have any questions regarding this, please contact the Worldwide Response Center.


November 17, 2003 – IBM 64 bit – Caché Floating Point Zero Boolean Issue

InterSystems has corrected a defect which caused a variable containing a floating point zero to evaluate as true in some logic tests. This defect is only present on Caché for IBM P Series AIX 64 bit. All other platforms including IBM P Series AIX 32 bit are unaffected. Only Caché versions 5.0 through 5.0.4 are at risk.

The defect can occur when a variable receives zero as the result of a floating-point operation. When the variable is subsequently used in a Boolean test it can evaluate as true.

A few examples are:

s x=0/10 I x w “true”
s x=0/100 I x w “true”
s x=10e10-10e10 I x w “true”
s x=+(“0.000”) I x w “true”

When executed in line each of these examples will output “true”. The value in x is still treated as floating point 0 when used in further operations but a Boolean test results in true.

The correction for this defect is identified as JLC555.

To obtain this correction, or if you have any questions regarding this, please contact the Worldwide Response Center.


November 14, 2003 – Caché Server Pages

InterSystems has encountered a critical issue with the use of Caché Server Pages, which would allow an attacker to remotely compromise the Caché Server and gain complete control over it.

All Caché versions starting with 4.0.3 are affected by this vulnerability and will be fixed with Caché 5.1. Please install the appropriate patch, available from our ftp site ftp://ftp.intersystems.com/pub/cache/old/PatchProdlog34606.zip, to help to protect your Caché system. Included in the zip file are complete instructions on the steps required to correct this issue.

If you have any questions regarding this, please contact the Worldwide Response Center.


November 6, 2003 – CSP Error Messages Corrupt in Caché 5.0.4 Only

In Caché 5.0.4 only, the CSP error messages global contains Unicode characters which may affect 8-bit installations in the following locales:

  • Russian
  • French
  • Italian
  • Portuguese/Brazil
  • Japan
  • Korea

Users who install 8 bit versions of Caché 5.0.4 will possibly get <WIDECHAR> errors when these error codes are requested. Contact the WRC for the correction PatchProdlog34256.zip. Included in the zip file are complete instructions on the steps required to correct this issue. This problem is resolved in Caché 5.0.5 and higher.

If you have any questions regarding this, please contact the Worldwide Response Center.


October 17, 2003 – Microsoft IIS 6.0 on Windows 2003 with CSP

It has come to our attention that Microsoft IIS 6 on Windows 2003 requires extra configuration to serve dynamic web content (such as CSP). As a security measure, the use of all ISAPI extensions is prohibited by default. The CSP gateway, used for communication between the web server and the Caché server, is such an ISAPI interface. We have put together a list of steps necessary to configure IIS 6 to successfully serve CSP pages by enabling ISAPI for ONLY the CSP gateway files. This will still prohibit all non-authorized ISAPI extensions from running.

If Caché is installed after Microsoft Internet Information Services, we will automatically configure IIS with all the information it needs to serve CSP pages. Following this, you will have to perform the following steps to allow our CSP gateway to work as an ISAPI extension.

  1. Open the Start menu.
  2. Click Settings and Select Control Panel.
  3. In Control Panel, double click Administrative Tools.
  4. Double click Internet Information Services.
  5. In the left panel, click Web Services Extensions.
  6. Under Tasks, click Add a New Web Service Extension.
  7. Type csp as the Extension.
  8. Click Add to add the files necessary for the extension to run.
  9. Browse to your Caché Installation directory (CacheSys, by default)
  10. Browse to /csp/bin.
  11. Select cspms.dll and click OK.
  12. Click Add to add a second file.
  13. Browse to <Caché Install>/csp/bin, select cspmssys.dll and click OK.
  14. Check “Set Extension Status to Allowed” and click OK.
  15. Verify that there is now another extension listed called csp and that the Status is specified as Allowed.

If you have installed IIS following Caché, reinstalling Caché will perform the necessary configuration for CSP to work (with the exception of the steps listed above).

If you have any questions regarding this, please contact the Worldwide Response Center.

More information on the changes in IIS 6 on Windows 2003 is available here.


October 6, 2003 – Caché Process Local Variable Corruption [VMS]

Earlier this year InterSystems WRC published the following alert:

March 13, 2003 – Caché Process Local Variable Corruption

The alert introduced correction LFT1076 to address a defect that can cause local variable corruption. It has been discovered that this correction did not fully address the defect for the VMS platform.

Correction LFT1139 has been created to fully correct this defect for VMS. It will be available in Caché 4.1.16 and an upcoming maintenance kit for Caché 5.0.x.

To obtain the fix or for more information please contact the Worldwide Response Center.


September 26, 2003 – Caché and McAfee product conflict

InterSystems WRC has received several reports that Caché will not run correctly when McAfee Personal Firewall v.4 or McAfee Virus Scan v.7 are installed on the same system. The following symptoms have been observed:

TELNET daemon fails to start at Caché startup with message:
” CTELNETD startup error, bind (sock) failed, Reason: WSAENOTSOCK”

GUI connections fail with:
” Unable to connect to cn_iptcp 127.0.0.1[1972];%SYS” or a similar message.

These problems occur because of the filtering implemented in McAfee’s CSLSP.DLL. Note that because the conflict is in a DLL, it is not necessary for the McAfee products to be running on a system, having them installed is enough to trigger the conflict.

The problems can occur with any version of Caché but only on Windows platforms.

McAfee has addressed this conflict in McAfee Personal Firewall Plus v.5 and McAfee Virus Scan v.8. InterSystems WRC has tested these versions with Caché and found that the problems no longer exist.

If the system is not using the HAWK function of McAfee Virus Scan and is not using the McAfee Personal Firewall it is possible to avoid this problem by removing CSLSP.DLL as follows in the Windows Start menu:
Start > run > regsvr32 “C:\winnt\system32\CsLsp.dll” /u

Please contact the Worldwide Response Center if further information is required.


September 22, 2003 -Update: Hyper-Threading and Caché

Earlier this year InterSystems WRC issued the following advisory:

January 15, 2003 – Intel’s Hyper-Threading technology and Caché

This advisory warned of instability with Intel Hyper-Threading and Caché. This issue has been resolved for Windows systems with the introduction of correction JLC489. As of the 5.0.3 maintenance kit of Caché the recommendation to disable Hyper-Threading on Windows systems is removed.

The issue is not yet resolved for Intel Linux systems.

Please contact the Worldwide Response Center if further information is required.


July 28, 2003 – Caché and MultiNet

A Caché cluster site has recently encountered VMS system crashes after upgrading from Caché 4.1.15 to Caché 5.0.1. The symptom is a VMS crash at Caché startup. Analysis of the VMS dump traced the cause to a MultiNet defect fixed in ECO kit:
ftp://ftp.multinet.process.com/patches/multinet044/named-011_a044.zip
available on the Process Software website: http://www.process.com/techsupport/patches.html

InterSystems strongly recommends that all Caché sites running MultiNet install this patch if applicable to their MultiNet version. This recommendation applies to all Caché versions.

Please contact the Worldwide Response Center if further information is required.


July 23, 2003 – Journal Suspension and Data Loss

InterSystems has identified and corrected a defect that could lead to a system hang and data loss in the event of journaling being suspended. This problem is present in all current releases of Cache 5 and all operating systems.

The problem occurs when a journal device fills resulting in journaling being suspended until action is taken to make space available and restart journaling (it will not restart automatically). This problem occurs only when the system is set to NOT freeze on journal i/o error (Configuration Manager -> Advanced -> Miscellaneous), which is the default.

The correction is identified as HYY783. It will be available in an upcoming maintenance kit or can be requested from the Worldwide Response Center.

InterSystems strongly recommends a standard practice of configuring an alternate journal directory on a different files system than the primary journal directory so that journaling can continue if the primary journal device should fill. Space on the journal devices should be monitored closely.


June 27, 2003 – Caché and write permissions on UNIX systems

Default installations of Caché for UNIX systems are configured with write permission on the Caché bin and csp directories enabled for all UNIX users. In addition, Caché can be installed in a configuration that allows UNIX users (other than “root”) in a specified group to start and stop Caché. This can result in certain vulnerabilities if hostile users have access to the system. The following example assumes that Caché has been installed in /cachesys and that members of the ” cachemgr” group are allowed to start and stop Caché.

Vulnerability #1:

Caché startup utilizes a setuid-root wrapper program, cuxs. A hostile user who is a member of the “cachemgr” group could overwrite /cachesys/bin/cache with arbitrary code, and cause that code to be executed as “root” by invoking /cachesys/bin/cuxs.

Vulnerability #2:

Caché Server Pages (CSP) technology is for building and deploying Web applications. Caché executes CSP content using the UID of the user that started Caché, which could be “root”. A hostile user could insert arbitrary code into subdirectories under /cachesys/csp and cause that code to be executed by Caché by accessing it using a Web browser (or other user agent).

Workaround

Log on as “root”, change to the directory where Caché is installed, and issue the command:

chmod go-w bin

If Caché is not being used for CSP programming, and is not running in conjunction with a local Apache web server, issue the command:

chmod -R go-w csp

The installation defaults have been changed in Caché 4.1.16 and 5.0.3. For more information please contact the Worldwide Response Center.


June 23, 2003 – Wrong answer for certain OR conditions when multiple index strategy used

A problem has been identified where, in certain cases, if multiple indexes are used to satisfy an OR condition, a SQL query can return wrong results. This problem exists for all Caché versions prior to 5.0.2 running on all operating systems.

The problem occurs when an SQL query contains certain OR conditions and an index on multiple fields is used. The result of the query will be wrong.

Sample:

CREATE INDEX ix_ItemPos ON ItemPos (PosID, Status)

SELECT DISTINCT
ItemPos. Status,
ItemPos.Order,
ItemPos.OrderedBy

FROM ItemPos
WHERE
(
ItemPos.Status=100
AND ItemPos.Order=1
AND ItemPos.OrderedBy IS NULL
) OR ItemPos.Status=500

The correction for this problem is identified by PVA051. It will be included in upcoming maintenance kits: Caché 4.1.16 and 5.0.3.

To obtain the fix or for more information please contact the InterSystems Worldwide Response Center.


June 20, 2003 – Caché Networking and New Format Databases, Addendum

The newsflash concerning networking and new format databases has generated concern among sites using Caché clustering technology. Caché 4.1 uses DCP for cluster communication. This use of DCP is supported and required for Caché clustering regardless of database format.

For more information please contact the Worldwide Response Center.


June 20, 2003 – Caché Networking and New Format Databases

With the release of Caché 4.1 InterSystems introduced a new format database. The new format is sometimes referred to as “8K Database” since a block size of 8 KB is used as opposed to the older Caché database format that used 2 KB blocks.

Several customers have recently encountered planning difficulties because they were unaware that the Caché networking protocol DCP does not support the new database format. The purpose of this advisory is to reinforce the understanding that if Caché networking with new format databases is required then the new networking protocol ECP must be used. ECP is available starting with Caché 5.

Details of the new database format can be found in the Caché 4.1 release notes.

Details of Caché 5 and the new ECP networking protocol can be found in the Caché 5 documentation.

For more information please contact the Worldwide Response Center.


May 20, 2003 – Transaction Processing over DCP

InterSystems has corrected two Caché defects with Transaction Processing over DCP. These defects are only present when using transaction processing (TP) over DCP. DCP alone or TP alone is not sufficient to trigger this defect. ECP, the new protocol available with Cache 5 is unaffected by these defects.

The first defect causes inappropriate transaction rollback in a DCP environment. This defect is present in all currently released versions of Caché that support DCP.

The cause of the problem is incorrect handling of the journal file counter in DCP. The count of journal files used since Caché startup is part of the pointer used to track open transactions. The PID of the client process requesting the TSTART is another part of this pointer. When a DCP client issues a TSTART the DCP server responds with a handle that points to the transaction that was opened. Since the DCP client receives a handle that does not match up with an open transaction on the server, the subsequent TCOMMIT does not actually close the transaction on the server. The next time Caché is stopped on the server or the client, or the network connection is lost, the server will rollback the most recent transaction for every client PID.

This problem is triggered when the number of journal files used since the last Caché start on the server exceeds 255. This count can be viewed by with the function $ZU(78,26).

Two corrections address this issue. The corrections are identified as HYY521 and SML359.

A second, unrelated issue defect also concerns transaction processing over DCP. When a DCPDMN process exits either via shutdown, error, or being forced to exit, transactions that were correctly rolled back may not be recorded in the journal file. The result being that, at Caché startup, the pre-rollback values are restored to the database from the journal file, negating the rollback. This defect is present in all currently released versions of Caché that support DCP.

The correction that addresses this issue is identified as SML367.

If your system is using transaction processing over DCP and you believe you need the corrections detailed above, please contact the Worldwide Response Center.


May 14, 2003 – Telnet Connections on Caché Windows

InterSystems WRC has recently encountered a situation where the number of telnet connections to Caché is artificially limited. The symptom of this problem is that telnet connections will fail once a threshold has been reached. The threshold has been observed to be 150-190 connections depending on memory configuration. An inconsistent error message will be returned to the failing processes. The message may be a generic Windows application error with a memory address, it may be “Connection Refused” or “Connection Timeout”. If a telnet connection is failing with a message concerning licensing then it is not due to the issue covered by this alert.

All versions of Caché on Windows NT or 2000 are susceptible to this issue.

If these symptoms are being observed it is probably because the Caché Controller service has been set to run as something other than local system. This can be seen in the Windows Control Panel -> Administrative Tools -> Services -> Cache Controller for [Cache instance] -> Properties -> Log On tab -> Log on as: and should be set to “Local System account” and the check box for “Allow services to interact with desktop” should be checked.

If Caché must run as a specific user, the Cache Controller service should still be set to run as “Local System account” but use the Caché Network Server user name and password found in the Caché Configuration Manager Advanced tab -> Input/Output to enter the Windows user as whom Caché should run in the DOMAIN\user format.

For more information please contact the Worldwide Response Center.


May 12, 2003 – Caché and AIX

InterSystems has recently investigated two separate issues on AIX platforms which were resolved by applying fixes to the AIX Operating Systems.

Issue 1: Fixed by IBM APAR IY36925

Poor performance was observed with Caché shadowing. Updates to the shadow database were falling behind the primary server. This was tracked to slow transfer of the updates between the primary and shadow systems. Further testing showed that performance was poor for any large TCP transfers.

Issue 2: Fixed by IBM APAR IY40381

Users and background processes running under Caché hang requiring a reboot of the operating system before continuing production.

InterSystems recommends that system managers investigate these IBM APARs and apply them according to IBM guidelines. Descriptions can be found at http://www.ibm.com/support by searching for the APAR number.

For more information please contact the Worldwide Response Center.


March 13, 2003 – Caché Process Local Variable Corruption

A problem has been identified where, in rare cases, a process’s local variables (Caché ObjectScript local variables) can become corrupted. This problem exits for all Caché versions running on all operating systems.

The problem occurs when a process, call it process A, is reading from a device. If, at the same time, process B examines the local variables of process A, the variable that process A is reading into may become corrupt. This can also occur if process A receives a broadcast message sent from process B, while doing a read from a device. Examination of local variables is accomplished either with the ^JOBEXAM routine from the command line or via the Control Panel in the Caché Cube.

The fix for this problem is identified as LFT1076. It will be included in upcoming maintenance kits for Caché 4.1.x and 5.0.x.

To obtain the fix or for more information please contact the Worldwide Response Center.


March 7, 2003 – Multi-homing and Caché Clusters on OpenVMS

InterSystems had determined that a Caché cluster may not reliably recovery from a member failure when two (or more) networks connect cluster members. The problem occurs when the network configured for DCP has higher IP addresses than the other network. The problem is caused because during cluster recovery, communication is expected to take place on the “primary” IP addresses. Under the current implementation “primary” IP address means the lower IP address.

The most effective work around for this problem is to map your private network to a range like 10.0.0.0 to 10.0.0.255. This is the smallest range that is available under RFC1918.

This problem is common to all current versions of Caché that implement clusters using DCP. Caché 5.0 (soon to be released) will use ECP for cluster communication, and the problem still exists. InterSystems is reviewing various configuration options to allow customers to control the IP network to be used for cluster recovery and expects to address this limitation in a future release.

Please contact the Worldwide Response Center if you require more information about this advisory.


January 15, 2003 – Intel’s Hyper-Threading technology and Caché

InterSystems has determined that Caché may be unstable when Hyper-Threading is enable on Intel XEON processors. Most XEON systems have Hyper-Threading disabled by default and it can be enabled/disabled in the BIOS setup menu.

While this problem is under investigation, we recommend that Hyper-Threading be disabled. This issue affects Caché versions through 5.0. Please contact the Worldwide Response Center for further information.