자사의 오라클 자바 SE 제품군(JDK & JRE 프로그램)의 보안업데이트가 공개되었습니다.
반드시 업데이트하길 바랍니다.
CVE-2013-5778, CVE-2013-5780, CVE-2013-5782, CVE-2013-5783, CVE-2013-5784, CVE-2013-5787, CVE-2013-5788,
CVE-2013-5789, CVE-2013-5790, CVE-2013-5797, CVE-2013-5800, CVE-2013-5801, CVE-2013-5802, CVE-2013-5803,
CVE-2013-5804, CVE-2013-5805, CVE-2013-5806, CVE-2013-5809, CVE-2013-5810, CVE-2013-5812, CVE-2013-5814,
CVE-2013-5817, CVE-2013-5818, CVE-2013-5819, CVE-2013-5820, CVE-2013-5823, CVE-2013-5824, CVE-2013-5825,
CVE-2013-5829, CVE-2013-5830, CVE-2013-5831, CVE-2013-5832, CVE-2013-5838, CVE-2013-5840, CVE-2013-5842,
CVE-2013-5843, CVE-2013-5844, CVE-2013-5846, CVE-2013-5848, CVE-2013-5849, CVE-2013-5850, CVE-2013-5851,
CVE-2013-5852, CVE-2013-5854)
[영향을 받는 소프트웨어 및 업데이트 버전]
□ JDK and JRE 7 Update 40 버전 및 하위 버전 → JDK and JRE 7 Update 45 버전
※ JDK and JRE 6 버전 및 모든 하위 버전은 더 이상 보안 패치를 제공하지 않으므로 반드시 JDK and JRE 7 Update 45 버전으로 업데이트를 하시기 바랍니다.
※ JDK & JRE 6 버전 및 모든 하위 버전 사용자는 프로그램 제거 후 JDK & JRE 7 Update 45버전 설치 권장
- 업데이트 관련 내용 : http://www.oracle.com/technetwork/java/javase/7u45-relnotes-2016950.html
Java™ SE Development Kit 7, Update 45 (JDK 7u45)
The full version string for this update release is 1.7.0_45-b18 (where "b" means "build"). The version number is 7u45.
Highlights
Olson Data 2013d
JDK 7u45 contains Olson time zone data version 2013d. For more information, refer to Timezone Data Versions in the JRE Software.
Security Baselines
The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 7u45 are specified in the following table:
| JRE Family Version | JRE Security Baseline (Full Version String) |
|---|---|
| 7 | 1.7.0_45 |
| 6 | 1.6.0_65 |
| 5.0 | 1.5.0_55 |
For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.
JRE Expiration Date
The expiration date for JRE 7u45 is 02/14/2014. After this date, Java will provide additional warnings and reminders to users to update to the newer version. For more information, see JRE Expiration Date.
Blacklist Entries
This update release includes a blacklist entry for a standalone JavaFX installer.
JavaFX Release Notes
JavaFX is now part of JDK. JDK 7u45 release includes JavaFX version 2.2.45.
JDK for Linux ARM
A JDK for Linux ARM is also available in this release.
New Features and Changes
Protections Against Unauthorized Redistribution of Java Applications
Starting with 7u45, application developers can specify new JAR manifest file attributes:
Application-Name: This attribute provides a secure title for your RIA.
Caller-Allowable-Codebase: This attribute specifies the codebase/locations from which JavaScript is allowed to call Applet classes.
JavaScript to Java calls will be allowed without any security dialog prompt only if:
- JAR is signed by a trusted CA, has the
Caller-Allowable-Codebasemanifest entry and JavaScript runs on the domain that matches it. - JAR is unsigned and JavaScript calls happens from the same domain as the JAR location.
The JavaScript to Java (LiveConnect) security dialog prompt is shown once per AppletclassLoader instance.
Application-Library-Allowable-Codebase: If the JNLP file or HTML page is in a different location than the JAR file, the Application-Library-Allowable-Codebase attribute identifies the locations from which your RIA can be expected to be started.
If the attribute is not present or if the attribute and location do not match, then the location of the JNLP file or HTML page is displayed in the security prompt shown to the user.
Note that the RIA can still be started in any of the above cases.
Developers can refer to JAR File Manifest Attributes for more information.
Restore Security Prompts
A new button is available in the Java Control Panel (JCP) to clear previously remembered trust decisions. A trust decision occurs when the user has selected the Do not show this again option in a security prompt. To show prompts that were previously hidden, click Restore Security Prompts. When asked to confirm the selection, click Restore All. The next time an application is started, the security prompt for that application is shown.
See Restore Security Prompts under the Security section of the Java Control Panel.
JAXP Changes
Starting from JDK 7u45, the following new processing limits are added to the JAXPFEATURE_SECURE_PROCESSING feature.
- totalEntitySizeLimit
- maxGeneralEntitySizeLimit
- maxParameterEntitySizeLimit
For more information, see the new Processing Limits lesson in the JAXP Tutorial.
TimeZone.setDefault Change
The java.util.TimeZone.setDefault(TimeZone) method has been changed to throw aSecurityException if the method is called by any code with which the security manager'scheckPermission call denies PropertyPermission("user.timezone", "write"). The new system property jdk.util.TimeZone.allowSetDefault (a boolean) is provided so that the compatible behavior can be enabled. The property will be evaluated only once when thejava.util.TimeZone class is loaded and initialized.
Bug Fixes
This release contains fixes for security vulnerabilities. For more information, see Oracle Critical Patch Update Advisory.
Known Issues
Area: Deployment/PlugIn
Synopsis: JavaScript-> Java (LiveConnect) call fails silently if JavaScript/HTML and unsigned JAR/class files comes from different codebase host.
If the portion of the codebase that specifies the protocol, host, and port, are not the same for the unsigned JAR file (or class files) as for the JavaScript or HTML, the code will fail without a mixed code dialog warning.
You can work around this using one of the following approaches:
- Put the JAR files (or class files) and the HTML/JavaScript on the same host.
- Sign the JAR files. (Self signed can cause the LiveConnect dialog to show already; or add a manifest file that specifies the Caller-Allowable-Codebase attribute.)
- Use the Deployment Rule Set (DRS) to allow the app and HTML to run without a warning.
When specifying the codebase, using the Caller-Allowable-Codebase attribute or the Deployment Rule Set, make sure to list the domain where the JavaScript/HTML is hosted.
Area: Deployment/Plugin
Synopsis: Using the family CLSID to trigger loading of an applet does not work with certain JRE family versions.
If you use the family CLSID to trigger loading of an applet with a certain JRE family version, the family CLISD will be ignored and the latest JRE version installed on your system is used to load the applet instead. Family CLSID is specific to Internet Explorer. The workaround is to use thejava_version applet parameter or the version attribute of the Java element in JNLP file instead.
Area: Deployment/Plugin
Synopsis: Certificate-based DRS rule does not work when main JAR is in nested resource block
The certificate-based Deployment Rule Set rule does not work properly for JNLP applications when the main JNLP file has no JAR files, or all JAR files are in nested resource blocks nested in<java> or <j2se> elements.
See 8026002.
Area: Deployment/Plugin
Synopsis: Caller-Allowable-Codebase may be ignored when used with Trusted-Library.
If a trusted, signed JAR file is using the Caller-Allowable-Codebase manifest attribute along with Trusted-Library then the Caller-Allowable-Codebase manifest entry will be ignored and, as a result, a JavaScript -> Java call will show the native LiveConnect warning. The workaround is to remove the Trusted-Library manifest entry.
Area: Deployment/Plugin
Synopsis: Applet could fail to load by throwing NPE if pack compression is used with deployment caching disabled.
If a JAR file is using pack compression with manifest entries Permissions and Caller-Allowable-Codebase while deployment caching is disabled, then:
- The Permissions manifest entry will be ignored. (This can be seen from the fact that yellow warning is there on security dialog even though the Permissions attribute is there.) This only happens if Caller-Allowable-Codebase attribute is present along with the Permissionsattribute.
- The Caller-Allowable-Codebase attribute will cause the applet to fail to load by throwing ajava.lang.NullPointerException.
If you want to use pack compression with the Caller-Allowable-Codebase attribute, there are two possible workarounds:
- Enable caching and all issues listed will disappear.
- Do not use the pack property jnlp.packEnabled=true while deploying the applets usingCaller-Allowable-Codebase and premissions property. Instead use the ContentTypeservlet for serving the pack files.
Area: Deployment/Plugin
Synopsis: Non-JNLP trusted applet fails to load using the file:\\ URL.
Local trusted applets that do not deploy using a JNLP file will fail to load by throwing ajava.lang.NullPointerException. You can work around this issue by using one of the following methods:
- Use a JNLP file to launch the applet.
- Try loading the applet over HTTP or HTTPS.
Area: Deployment/Plugin
Synopsis: JNLP applet fails to load if using JNLP versioning.
Due to this bug, if you are using the jnlp.versionEnabled property for JAR versioning in your browser applet, your applet might not start. Also users might see a yellow warning about a missingPermissions attribute in the following two scenarios:
- The jnlp.versionEnabled property is set to false inside the JNLP file and the version is defined against the main JAR file.
- You use JNLPDownloadServlet for version download support.
The workaround is to either not use versioning via jnlp.versionEnabled, or to use theJNLPDownloadServlet servlet for version support instead.
업데이트 방법은 자바의 자동 업데이트를 실행하던가,
[제어판]에 가서 [JAVA] 를 실행시킨 후 [지금 업데이트] 하면 된다.
댓글