This is an update to the security notice sent out Thursday, February 21, 2008.

After reviewing security logs and comparing file systems and source code to known backups as part of our security audit, we are relieved to report that we have not found any evidence that any systems or customer information were successfully compromised during the period that firewall rules were partially disabled and some internet-facing systems were under attack. Additionally it appears that at least some of what was reported as an attack was the work of worms targeting Windows vulnerabilities, which we do not use for our servers–traffic we do not normally see due to firewalls and other protections.

The main avenue for attack that we were most concerned with was certain systems that were being brought up to migrate services to that might not have been fully patched or locked down yet while they were in transition. Though it doesn’t appear there’s been any compromise, as an added precaution, we will still be reinstalling these systems and services, so you may expect some brief periods of down time over the weekend (much of this we’re doing anyway, to sync up deployed software versions with versions being installed on the new systems to ease transition). We’re also revoking all authentication and encryption keys and have requested a new SSL certificate, and will take additional steps to improve our auditing procedures and response time.

Once we have finished upgrading critical server software and have received the new SSL certificate, we will bring the shopping system back online. You will not be able to log into your Muonics web site account until this time.

Please accept our apology for any inconvenience or worry caused by our previous notice and the downtime involved. Though it appears to have been a false alarm, one can never be too cautious about these things.

Should you have any lingering concerns, we will be more than happy to reimburse anyone who has placed orders with us online, at any time in the past, for up to 12 months of credit activity monitoring from your choice of provider. You can contact me directly by phone or email any time between now and March 31, 2008 to arrange.

Thank you for your patience.

Michael Kirkham, President & CEO

Continue reading Security Notice (Updated)

An unknown variable error that would occur when adding a MIB if either a file with the same name was already added or if copying/linking the file into the mibs directory failed, rather than the intended dialog, and was corrected in this release.

Changes in this release:

• nmtrapd under Linux could max out CPU usage due to Linux-specific handling of select() timeouts.
• Newlines and carriage returns in OCTET STRING values were forcing conversion to hex (such as in varbind values in responses) as if they were non-printable characters.
• A crash could occur if the environment variable for pointing to the license key file were mistakenly set to a directory instead.

Changes affecting MIB Smithy:

• A “wrong # args” error could occur when previewing a single OBJECT-TYPE in SMI format (the error did not occur when previewing the whole module).

Changes affecting both MIB Smithy and MIB Smithy SDK:

• The “piberrors” type in the XML-SMI Schema document was not correct and did not match the implementation and has been corrected.
• Newlines and carriage returns in OCTET STRING values were forcing conversion to hex (such as in varbind values in responses) as if they were on-printable characters.
• A crash could occur if the environment variable for pointing to the license key file were mistakenly set to a directory instead.

There was another issue with the table SEQUENCE definition relocation change merged into 4.0.4 and not fixed in 4.0.5 that caused them to be generated twice rather than once. This could cause a module that was saved to fail to load back into MIB Smithy later.

Also, when such failure occurred due to the duplicate definition, double-clicking on the error in the compiler log should have opened the text file editor for manual correction, but instead caused an “invalid workspace type” error.

Both of these issues have been corrected in the 4.0.6 release.