We just finished up some (very, very) overdue updates to the support portal. The first is probably one of the more popular user requests to create support portal accounts that line up to the ASL user ID. Previously we had maintained a policy of separate portal portal accounts to allow users to have multiple tiers internally, which sounded like a great idea originally but in practice it doesn't get used a whole lot.  This also will align better with the new support programs we'll be launching in 2011.

The second change corrects a much larger internal cost for us with resetting user passwords when those get forgotten ( Password Hasher people!). Why sugarcrm never implemented a password reset option in the portal I have *NO IDEA*. Resetting passwords manually is a painful experience in Sugar.

To sum this up:

• Support Portal accounts are automatically created when a subscription is validated (this means the payment went through).
• You can reset your ASL/Portal password directly through either the License Manager or the Support Portal.
• Current users will automatically generate support portal accounts on renewals, or if you change your password.
• Existing portal accounts that do not line up with your ASL ID will still work just fine.

And of course if anyone is interested in our changes, just let me know. I'd be happy to post them.

Kernel News

Brad Spender of Grsecurity fame gave me the heads up earlier on a few kernel exploits that are on their way to being published in the wild. If you track this kind of thing, you might have seen this post at The Register about one of them already. Its a neat bug in that its really a rehash of one from a few years ago, reintroduced by some other changes. The good news is obviously it does not effect ASL environments, do to the way we handle memory protection on the system.  And demonstrates one of the key advantages to extensive stack and memory protection implementations in the kernel. In this very specific example, the vulnerability exists in an ASL kernel. The buggy code is there, you can verify its there... its scary... your auditors will fail you! That is unless you actually test it, as the following demonstrates (try it yourself!):

http://sota.gen.nz/compat2/robert_you_suck.c

gcc -o kernel_exploit_1 robert_you_suck.c

[sshinn@c5-64-build ~]$ ./kernel_exploit_1
symbol table not available, aborting!
Process finished
[sshinn@c5-64-build ~]$

Twitter updates

You may have noticed a profound lack of spam...er... updates on our atomicorp and my personal twitter feeds. The recent Oauth changes implemented broke all of our build system and updater triggers, that were all very basic wget driven events. Which was awesome... I love wget.. oauth from the command line on the other hand... not so much. Needless to say it was re-implemented (as in total rewrite!) using tools like http_post instead of our beloved wget. Oh how we shall miss you... for anyone else looking to do this check out this site for the details.

mod_fcgid updated

I'll probably post this again to the archive news feed, but mod_fcgid was updated to version 2.3.5. Very minor update, but its important for fcgi environments since Im told it allows you do to something like open_basedir. If this is indeed true, this is fantastic security news.

A few random project updates:

• nikto was updated to 2.1.3. This is a basic web application vulnerability scanner, theres another we've been meaning to package called w3af. Looks promising
• openvas-manager was updated, with more fixes. This is a minor update in a series to support the greenbone security administrator (GSA) on centos 5.
• clapf, an antivirus/antispam module for postfix was updated to 0.4.5rc3. A few more issues were fixed, but I believe it still needs a few more changes in the cron jobs.

The larger project update going on right now is OSSEC version 2.5 (beta). As ASL 3.0 is being developed a number of our support packages need to be either updated, or modified to support our new API's and features. This is a big one, since OSSEC supports both event recording in mysql as well as our enterprise client/server components. The latest build, 2.5-0.2 added a new rule set called exclude_rules.xml which we use in ASL to generate rule customizations. Currently ASL 2.2.11-0.2 allows you to modify either the level (used to manage shunning, shunning/reporting, or ignore) or the email policy on a per alert level via the file /etc/asl/rules.

Please note this is an interim configuration file as the design works itself out, so it can and will change considerably. The current format is:

# Rule ID, Email, Level

When asl -s -f is run, this will generate the appropriate rule exclude data to customize the policy. For example to disable email alerting on specific OSSEC rule ids like 60118 (mod_security) you would use:

60118,no,7

Internally we've already seen the shortcomings of this file based approach to managing the rule configuration and prototyped past this, so this is just going to be an interim solution. Don't get too attached!