A security vulnerability in the TLS protocol (TLS 1.0 or later and SSLv3) may allow an unauthenticated, remote attacker to conduct man-in-the-middle (MITM) type of attacks where chosen plain text may be injected as a prefix in an user's TLS session. This vulnerability does not allow one to decrypt the intercepted network communication.

This issue is referenced in CVE-2009-3555

Exact nature of the impact depends on the application making use of the TLS facility. Applications which use Network Security Services (NSS), Java Secure Socket Extensions (JSSE), OpenSSL or GnuTLS libraries may be affected.

Sun is evaluating the impact of the issue on various products which make use of the TLS libraries. We are working to fix the TLS implementations according to the TLS protocol standard extensions currently being developed.

Solaris Kernel SSL proxy module KSSL does not support client renegotiation or rehandshake. It ignores the rehandshake message which is an allowed behavior by the SSL/TLS specification. Hence it is not vulnerable to this issue. KSSL (see ksslcfg(1M)) is available in Solaris 10 and OpenSolaris. It may be used to workaround the described issue.

tags: gnutls jsse nss openssl security tls vulnerability

Permalink |

CVE-2009-0159 describes a security issue in the ntpq(1M) daemon which could allow remote NTP servers to crash the ntpq program or to execute arbitrary code when ntpq is used to query them.

Sun has examined the implementation of the ntpq(1M) command that is shipped with Solaris and has determined that although the affected code is present and has been fixed as Sun bug ID 6831824, it is not possible to exploit this issue on Solaris to execute arbitrary code or to crash the ntpq command.

tags: security solaris vulnerability

Permalink |

An apparent Denial of Service (DoS) issue relating to Sun M-class servers
was reported by three OpenBSD developers to the Full-Disclosure mailing
list:

http://lists.grok.org.uk/pipermail/full-disclosure/2008-September/064312.html

The issue as described relates that the OpenBSD/sparc64 kernel can trigger
a fault which causes the dynamic domain of a Sun M-class server to power
down. Sun has investigated this issue and would like to provide the
following details to help clarify the impact as well as the contributing
factors.

• This issue applies to Sun SPARC Enterprise M4000 Servers and Sun
  SPARC Enterprise M5000 Servers only.
  
• This issue does not apply to the above systems when Solaris is
  installed.
  
• This issue is seen with OpenBSD/sparc64 due to a device driver and
  thus can not be triggered by an unprivileged user.
  
• The OpenBSD/sparc64 device driver causes a hardware fault to occur
  and since the dynamic domains in Sun SPARC Enterprise M4000 and
  M5000 servers share major hardware components the hardware fault
  causes the M-class server processor to shut down the entire platform.
  
• The Sun SPARC Enterprise M4000 and M5000 servers are cold service
  systems and thus to clear a hardware fault the system must be powered
  off.
  

tags: dos m4000 m5000 openbsd vulnerability

Permalink |

Sun is aware of a Denial of Service (DoS) issue in the Sun SPARC Enterprise M4000 server running OpenBSD. This issue could
lead to a hardware failure in one domain that may affect other running domains on the system, thereby requiring complete
power cycle of the hardware to recover from. Sun acknowledges Theo de Raadt of openbsd.org for bringing the issue to our
attention.

Sun has been in contact with the reporters of the issue and is currently investigating to fully understand the root cause,
its impact and to find a resolution. Sun will provide additional information as soon as it becomes available.

Security vulnerabilities or potential security issues in any Sun product may be reported via email to
security {dash} alert {at} sun.com. It is recommended to encrypt all sensitive emails with the Sun Security Coordination Team's PGP key.
More details can be found here

tags: dos m4000 openbsd sparc vulnerability

Permalink |

The Sun Java System Application Server versions 8.1, 9.0 and 9.1 bundle the Java SE Development Kit (JDK) 1.5.0. Sun has recently published JDK
1.5.0_16, which is an Update to JDK 1.5.0, addressing multiple security vulnerabilities as listed in the following Sun Alerts:

Sun Alert 238628 available here
Sun Alert 238905 available here
Sun Alert 238965 available here
Sun Alert 238966 available here
Sun Alert 238967 available here
Sun Alert 238968 available here

All users of Sun Java System Application Server should apply the patches listed in these Sun Alerts or upgrade the JDK to JDK 1.5.0_16 which is
available at

http://java.sun.com/javase/downloads/index_jdk5.jsp

tags: alert appserver jdk vulnerability

Permalink | Comments [1]

The Sun Security Coordination Team has published a reference document for security Sun Alerts at:

http://sunsolve.sun.com/search/document.do?assetkey=1-9-91209-1

This document includes information on Preliminary and Workaround Sun Alerts, various sections in the body of a Sun Alert, definitions of frequently used vulnerability related terminology (such as 'local user', 'remote user', 'execution of arbitrary code' and so on) and a brief summary of Sun's response to security vulnerability reports.

tags: alert reference sun vulnerability

Permalink | Comments [0]

So a friend punted this URL over to me:

InfoWorld: Should vendors close all security holes?
Fix it or forget it? A reader presents an intriguing counterpoint

In last week's column, I argued that vendors should close all known security holes. A reader wrote me with a somewhat interesting argument that I'm still slightly debating, although my overall conclusion stands: Vendors should close all known security holes, whether publicly discussed or not. The idea behind this is that any existing security vulnerability should be closed to strengthen the product and protect consumers. Sounds great, right?

The reader wrote to say that his company often sits on security bugs until they are publicly announced or until at least one customer complaint is made. Before you start disagreeing with this policy, hear out the rest of his argument.

(continues...)

...and I shared the link and article with our security community chat channel, inviting comment. The result itself surpassed what I was intending to write, and provides food for thought:

• (15:36:32) alecm has changed the topic to: http://www.infoworld.com/article/07/05/11/20OPsecadvise_1.html - Comments please before I SLOTD a critique...

• (16:13:03) bartb: alecm: what kind of comments are you looking for? Summary of thoughts: reality says you'll always have bugs, you'll always be short-staffed, so fix those that are publicly known, fix those that have a large-ish impact, fix the remainder if time permits.

• (16:33:14) darrenm: re: the topic, I agree with some of what is being said in that article though not the "defer indefinitely until it is reported" way; priority scheduling for fixes to get patches out for those that are publically known is a no-brainer.

• (17:32:15) bartb: alecm: schneier's fresh blog posting may be of interest around your planned blog post

• (17:46:27) alecm: My take on the Infoworld article: I think it's a bad idea, I'm with Bart and Darren but probably showing my sys-admin heritage. To me security-bugs need "fixing" ASAP they are found, and yes I expect vendors to do the extant exploits first... but if a hole is wide-open and I am told about it, I can mitigate it in more ways than a software patch. Eg: Firewall port-blocking. Hence why I support full-disclosure within a per-event "reasonable" time period.

• (18:08:45) Avalon: Yes, vendors should close all security holes.

• (18:09:14) sommerfeld: the more interesting question is: given limited development resources, in what order should they be closed.

• (18:09:59) Avalon: There's another question that begs to be asked by that article: what about security holes that are closed without being disclosed publicly? I make that point because quite obviously someone is saying that fixing one (and subsequent patch/fix announcement) draws more attention and therefor exploits than without said publicity.

• (18:11:19) sommerfeld: what about security holes that are closed without the developer realizing that they bug they fixed was exploitable? I have done this. IMHO that's the best kind of security fix - *NOBODY* knows about the exploit! The one time in my memory when someone asked me why I didn't publish a security alert on a bugfix, it was because I had been fixing a bunch of gcc -Wall warnings and didn't stop to check whether any of the fixes were exploitable.

• (18:12:38) Avalon: hmmm, the article does mention people reverse engineering patches. Hmmm... Would you rather have only the Red Army know about your bugs or everyone? It's unquestioned that there are teams of Chinese hackers trying to break into military and commercial systems around the world. They've got access to more man power than most hacker organisations ever will...

• (18:18:12) alecm: Avalon: have you a citation for the chinese thing ?

• (18:37:02) Avalon: USA Today.

...and on rolls the paranoid chatter which drives all us security geeks. I thought I would post this and open it up to discussion than just leave it hanging.

In summary I would suggest (in slight disagreement with the "fix it when it goes public" position cited by the article) that the consensus amongst our little group is that we should fix everything because that's the right thing to do; but pragmatic prioritisation in the face of exploitation is wise.

You just can't rely on that, since you don't always know when you're being exploited.

- alec

tags: engineering hacking schneier security slotd vulnerability

Permalink | Comments [0]