Thursday Jan 07, 2010

Vulnerability in TLS Protocol during Renegotiation [CVE-2009-3555]

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 or modify the intercepted network communication.

This issue is referenced in CVE-2009-3555 and US-CERT VU#120541

Exact nature of the impact depends on the application making use of the TLS facility.

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 RFC 5746.

  • Solaris Kernel SSL:
    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 in server applications.

  • Java:
    The Java Secure Socket Extension (JSSE) included in the following Java SE and Java SE for Business releases for Windows, Solaris, and Linux are affected:

    • JDK and JRE 6 Update 17 and earlier
    • JDK and JRE 5.0 Update 22 and earlier
    • SDK and JRE 1.4.2_24 and earlier

    An interim fix, that disables TLS/SSL renegotiation in JSSE by default, is included in March 2010 Java security update.

  • GnuTLS libraries in Solaris:
    The issue does not affect any server applications distributed with Solaris which use the GnuTLS library. At this time we do not plan to issue any interim fixes to GnuTLS libraries. Fixes to GnuTLS distributed with Solaris would be provided when the proposed TLS extensions become a standard.

  • OpenSSL libraries in Solaris:
    Sun Alert 273029 describes this issue in OpenSSL (openssl(5)) libraries provided with in Solaris 10 and OpenSolaris.

  • Network Security Services (NSS):
    Sun Alert 273350 describes the issue in NSS libraries provided with Solaris and Sun Java Enterprise System.

  • Sun Java Enterprise System Suite
    Sun Alert 274990 describes the issue in Sun Java System Web Server 6.1, 7.0, Sun Java System Web Proxy Server 4.0, Sun Java System Application Server Enterprise Edition and Sun GlassFish Enterprise Server v2.1. This article explains the issue in Sun Java System Web Server and provides workarounds and mitigation.

Thursday Jun 25, 2009

Solaris not impacted by CVE-2009-0159

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.

Friday Dec 05, 2008

Sun Response to M-Class Server Denial of Service (DoS) Report

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.

Monday Sep 22, 2008

Denial of Service (DoS) issue reported in Sun SPARC Enterprise M4000 running OpenBSD

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

Monday Sep 15, 2008

Update JDK in Sun Java System Application Server

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


Tuesday Nov 06, 2007

Reference document for security Sun Alerts

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.

Tuesday May 15, 2007

SLOTD: Infoworld Writes On Vulnerability Fixing...

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

About

This blog provides security vulnerability fix notifications relevant to third party software components distributed and supported as part of Oracle Products.
Summarized version of this blog is available as a mapping of CVEs and solutions.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
2
3
4
5
6
7
8
9
10
11
12
13
14
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today