Solaris is - to the best of my knowledge - unique amongst Unix impementations in having a pluggable password encryption routine so that the administrator has the option of selecting a non-default password hash routine with the hope of making yourself more proof against password cracking - plus you can migrate users off-off older, weaker algorithms in a smooth fashion.

Brendan Gregg took this to the point of extreme silliness when he implemented a ROT13 password-hashing module for which he's posted the source; if you're not familiar with ROT13 it's the most trivial of pencil-and-paper ciphers, the sort of thing which got used to hide the punchlines of jokes posted via e-mail or on USENET.

I wouldn't recommend rolling out Brendan's code in an enterprise deployment - not unless you want all your passwords cracked in about 3 milliseconds flat - but it makes a nice proof of concept, and shows what you are free to do with the pluggable crypt API.

- alec

tags:

Permalink | Comments [4]

Glenn Faden is one of Sun's hardline security geeks, the prime mover behind the Solaris Trusted Extensions project which succeeds the older Trusted Solaris.

Glenn writes:

I have been working on an architecture for multilevel mail in Trusted Extensions in which mail can be delivered to labeled zones that are only in the ready state (mounted but not running). This would reduce the overhead of the current polyinstantiation approach in which an instance of sendmail is running in each zone.

For those unfamiliar with "trusted platforms", their core concept of "labelling" is to mark each file, directory, object, process or person on a machine with both a "compartment" (eg: finance, IT, payroll, human-resources) and some sort of "sensitivity" (eg: unclassified, confidential, secret); the trusted functionality permits "label-aware" applications to enforce need-to-know information handling rules.

That may sound outre or faintly military ("top secret") but there are dozens of possibilities for systems where you can keep programs aloof from each other, or from the data which they are processing.

Consider a webserver with one Internet-facing network interface, and another network interface attached to your credit-card database. Wouldn't it be nice to be assured that no data can pass from your credit-card data through to the Internet without being specially filtered, brokered and sanity checked? I find the idea rather appealing, I must admit.

Or consider the possibility of multilevel Instant Messenger - there would be no cut-and-paste between internal IM and external AIM, Yahoo or Skype; that really gets some finance people (eg: the sort who deal with traders) rather excited...

- alec

tags:

Permalink | Comments [0]

I was over the moon today to see Jonathan Schwartz blog the latest organisational announcement. Not just because of the transparency and openness it demonstrates, but also one of the reasons given for forming the Microelectronics group is "investing in cryptography".

The UltraSPARC T1 processor that we first shipped with the T1000/T2000 machines has some very cool modular exponentiation logic in it which makes it possible to implement a hardware-assisted RSA/DSA implementation that is really fast. "No big deal", you say - "PCI cards have been doing it that way for a while"?

Well roll on Niagara 2, due later this year, where we add AES, 3DES, RC4, SHA1, SHA256, MD5 to that list - all done in hardware and all on a CMT processor.

Niagara 2 also brings us hardware randomness from the chip as well.

Now I don't personally know the future of our hardware crypto products beyond this at the moment, but I hope that the investment in the new Microelectronics group will allow us to go even further in this area. When I know more that I can share I'll share it here. There is some stuff I want to share with you about Rock but I need to get my head around it before I'm ready to share.

- Darren

tags:

Permalink | Comments [2]

As our first Security Link Of The Day we'd really like to mention OpenSolaris and specifically the security communities and projects within it; there are over a score of projects including (but not limited to!) the following categories:

  • Cryptographic Framework (abstract access to accelerated cryptography)
  • IPsec (secure TCP/IP networking)
  • Kerberos (single sign-on solution)
  • SASL (simple authentication security layer, framework for authentication / authorization in internet protocols)
  • SSH (secure shell, encrypted interactive access with tunneling)
  • RBAC (role-based access control, constraining privileged user access)
  • Solaris Auditing (audit trail of user activity)
  • Trusted Extensions (compartmentalisation and labelling of user data and processes)

The best jumping-off points to investigate all the security possibilities are probably the Security Community Wiki and the main OpenSolaris Projects List.

Do take a look. There's a lot of nifty stuff there.

- alec

tags:

Permalink | Comments [0]

Hi,

One of the biggest challenges that Sun's security community - all of the security community, the kernel folk, the applications folk, the Java evangelists, the hardware geeks, the integrators, the cryppies, the researchers, the legal beagles, the politicians, and the just plain interested - one of if not the greatest challenge is "how can we talk with the customer whilst using a single voice?"

It's easy for product-focused groups; when you create a security widget, hoodjamaflip or doohickey there usually comes a product marketeer who expounds relentlessly about your nifty thing at every opportunity, so that interest catches light and sets aflame many imaginations - and product sales follow.

Or, at least, that's how it's supposed to work. Regarding security, things can be a little different.

The challenge is summed up in the very terminology of Sun's approach to "Systemic Security" - it's inarguable that security is holistic, the summation of good code running on good hardware, properly installed and integrated into its larger environment, with availability, integrity and robustness for all.

So who is your product marketer for the entire stack? Aside from you, who can talk about the wider issues, the architectural big pictures or the knock-on benefits you can get from leveraging one tiny, under-advertised feature of a much larger product like Solaris?

If you are member of the Sun security community, and if you have something to say, where do you go to talk about the whole panoply of security? To where should you direct your voice?

The answer, now, is here, blogs.sun.com/security.

This is not to say that Sun security folk should abandon their own blogs - heavens, no! Absolutely not. No no no no no! That's not the point at all. Please be clear about that. Please keep blogging.

In addition, here at blogs.sun.com/security we hope to provide a point of consolidation, where people can find postings and feeds pertinent to their preferred topics - Security Alerts, Tips, New Products, Announcements of "Pertinent Stuff" internal and external to Sun - where you can find personally written content with a high signal-to-noise ratio, and where you can have conversations through comments, cross-linking, providing the immediacy which is a cornerstone of the modern web.

For the Sun employee: if you want to post something, or if you'd like to see a pointer to something you've blogged be added, then drop us a line via e-mail. We'll be in touch. Promise. In the meantime get a blog on blogs.sun.com, if you've not got one already.

For the non-Sun reader: Sun Alerts will continue to be posted here by the Sun Security Co-ordination Team; so there will be no change there; but if you haven't already, please bookmark this site or add it to your feeds. Articles, pointers to other articles, and suggestions for postings are welcome. Just add a comment.

If you desire strictly alerts-only traffic, all the security Sun Alerts will continue to be posted into the Security Alerts Category, which already has a specific RSS feed at blogs.sun.com/security/feed/entries/rss?cat=%2FAlerts .

Over the coming weeks there will be evolution and change, and you'll be hearing from real Sun people with real interest in security. The sidebar will expand, the header too. We're also looking towards better integration with the www.sun.com/security website. It would be nice to have something approaching a one-stop shop for anyone who wants to know about Sun and our Security offerings.

For now, though, please keep watching. We hope you'll like the changes.

alec (alec.muffett@sun.com)

tags:

Permalink | Comments [3]

Product: Sun Java System Access Manager 7 2005Q4

A local user logged in as "root" on a system with Sun Java System Access Manager may be able to use the "amadmin" CLI tool to administer the Access Manager installation with the privileges of the top-level administrator (regardless of the credentials originally used to login to the Access Manager server). Access Manager security is compromised.

Avoidance: Patch
State: Resolved
First released: 01-Feb-2006
Permalink | Comments [1]

Product: Sun ONE Application Server 7, Standard Edition, Sun Java System Web Server 6.1, Sun Java System Web Server 6.0 Service Pack 8, Sun Java System Application Server Enterprise Edition 7 2004Q2, Sun Java System Application Server Enterprise Edition 8.1 2005Q1, Sun ONE Application Server 7, Platform Edition

A security vulnerability in Sun Java System Application Server (SJSAS) and Sun Java System Web Server (SJSWS) may allow a remote unprivileged user to read files outside of the configured document root directory of the system upon which SJSAS or SJSWS is running.

Avoidance: Patch, Upgrade
State: Resolved
First released: 27-Jul-2006
Permalink | Comments [0]

Product: Solaris 9 Operating System, Solaris 10 Operating System, Solaris 8 Operating System

The Xsun(1) server and Xorg(1) server are the X display servers for Version 11 of the X window system on Solaris.

There exists an overflow vulnerability when performing integer multiplication within the libXfont library, as used by the X11 display servers, that can cause a heap overflow while loading the fonts. This may allow a local unprivileged user to be able to execute arbitrary commands with elevated privileges or create a Denial of Service (DoS) to the display managers.

This issue is described in the following documents:

Avoidance: Patch, Workaround
State: Resolved
First released: 14-Nov-2006
Permalink | Comments [0]

Product: Java Dynamic Management Kit 5.1

A security vulnerability in the JMX RMI-IIOP API may allow a local user who is able to create a JMX RMI-IIOP server application to gain unauthorized access to certain local data if a remote user who has privileges to access that data connects to that server application.

Note: JMX RMI-IIOP stands for:

  • JMX: Java Management Extensions Remote API
  • RMI-IIOP: Remote Method Invocation over Internet Inter-ORB Protocol
Avoidance: Patch
State: Resolved
First released: 09-Mar-2007
Permalink | Comments [0]

Product: Solaris 9 Operating System, Solaris 10 Operating System

Two integer overflows, one in the CIDAFM() function and one in the scan_cidfont() function, have been found in the Xorg X server (see Xorg(1)) which may allow a local unprivileged user the ability to execute arbitrary code with the privileges of the Xorg server. The Xorg X server runs with root privileges on Solaris.

These issues are described in the following documents:

CVE-2006-3739 at: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3739

CVE-2006-3740 at: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3740

iDefense Multiple Vendor X Server CID-keyed Fonts 'CIDAFM()' Integer Overflow Vulnerability at: http://www.idefense.com/intelligence/vulnerabilities/display.php?id=412

Multiple Vendor X Server CID-keyed Fonts 'scan_cidfont()' Integer Overflow Vulnerability at: http://www.idefense.com/intelligence/vulnerabilities/display.php?id=411

Avoidance: Patch, Workaround
State: Resolved
First released: 23-Jan-2007
Permalink | Comments [0]

Product: Solaris 9 Operating System, Solaris 10 Operating System, Solaris 8 Operating System

Security vulnerabilities in the gzip(1) command may allow a local or remote unprivileged user to execute arbitrary code with the privileges of another user who runs the gzip(1) command, or cause a Denial of Service (DoS) condition using a specially crafted gzip archive.

These issues are also referenced in the following documents:

Sun acknowledges with thanks, Tavis Ormandy, Google Security Team, for discovering and reporting these issues.

Avoidance: Patch
State: Resolved
First released: 08-Jan-2007
Permalink | Comments [0]

Product: Solaris 10 Operating System

Two security vulnerabilities in the PostgreSQL database server (see postgres(1)) may allow local or remote PostgreSQL users the ability to cause the PostgreSQL server to crash or access restricted database content.

The ability to crash the PostgreSQL server is a type of Denial of Service (DoS).

These issues are described in the following documents:

Avoidance: Patch, Workaround
State: Resolved
First released: 27-Feb-2007
Permalink | Comments [0]

Product: Solaris 9 Operating System, Solaris 10 Operating System, Solaris 8 Operating System

Two security vulnerabilities have been found in the Apache HTTP server which affect the Apache 1.3 web server bundled with Solaris 8, 9, and 10.

The first issue, a vulnerability in the mod_rewrite Apache HTTP server module (CVE-2006-3747), may allow a local or remote unprivileged user to execute arbitrary code with the privileges of the Apache 1.3 process, or cause a Denial of Service (DoS) to the Apache HTTP process. The Apache process normally runs as the unprivileged user "nobody" (uid 60001).

The second issue, a Cross Site Scripting (CSS or XSS) vulnerability in the mod_imap Apache HTTP server module (CVE-2005-3352), may allow a local or remote unprivileged user to steal cookie information, hijack sessions, or cause a loss of data privacy between a client and the server.

Additional information regarding these issues is available at:

Avoidance: Patch, Workaround
State: Resolved
First released: 11-Oct-2006
Permalink | Comments [0]

Product: Solaris 10 Operating System

This Sun Alert is entirely replaced by 102662 for Apache 2.0 and 102663 for Apache 1.3.

Sun Alert 102662 is available at:

Sun Alert 102663 is available at:

Avoidance: Patch
State: Resolved
First released: 04-Oct-2006
Permalink | Comments [0]

Product: Solaris 10 Operating System

Three security vulnerabilities have been found in the Apache HTTP server which affect the Apache 2.0 web server bundled with Solaris 10.

The first issue, a vulnerability in the mod_rewrite Apache HTTP server module (CVE-2006-3747), may allow a local or remote unprivileged user to execute arbitrary code with the privileges of the Apache 2.0 process or cause a Denial of Service (DoS) to the Apache HTTP process. The Apache 2.0 HTTP process normally runs as the unprivileged user "webservd" (uid 80).

The second issue, a vulnerability in the mod_ssl Apache HTTP server module (CVE-2005-3357), may allow a local or remote unprivileged user to cause a Denial of Service (DoS) to the Apache HTTP process.

The third issue, a Cross Site Scripting (CSS or XSS) vulnerability in the mod_imap Apache HTTP server module (CVE-2005-3352), may allow a local or remote unprivileged user to steal cookie information, hijack sessions, or cause a loss of data privacy between a client and the server.

Additional information regarding these issues is available at:

Avoidance: Patch, Workaround
State: Resolved
First released: 10-Oct-2006
Permalink | Comments [0]