Blog Updates:
Minor updates:
- Update labels on some old posts
Will continue to make minor improvements for this blog!
- wong chee tat :)
Thursday, April 21, 2016
Oracle patches 136 flaws in 49 products
Oracle patches 136 flaws in 49 products
Oracle released the April 2016 Critical Patch Update, which provides fixes for 136 vulnerabilities in 49 products, including Java SE and MySQL, the company’s Database Server and E-Business Suite, its Fusion Middleware, and its Sun Systems Products Suite.
Oracle patches
“Oracle continues to periodically receive reports of attempts to maliciously exploit vulnerabilities for which Oracle has already released fixes. In some instances, it has been reported that attackers have been successful because targeted customers had failed to apply available Oracle patches. Oracle therefore strongly recommends that customers remain on actively-supported versions and apply Critical Patch Update fixes without delay,” the company advised.
“There are a few indicators that can help you prioritize what updates you should worry about first. Exploit code examples being available in Metasploit is an easy one. If it is in Metasploit, it is also in the threat actor’s hands. Beyond that things like public disclosures help to identify vulnerabilities that stand a higher chance of being exploited,” noted Shavlik’s Chris Goettl, pointing out that vulnerabilities that get the highest CVSS score (10.0) are usually exploited in the wild in less than a month after they have been disclosed and patched.
Therefore he recommends Java SE, MySQL, and Sun Systems Products Suite to be updated before anything else.
For more information about the specific vulnerabilities and patched, check out the advisory accompanying the update.
It’s interesting to note that Oracle is slowly switching to version 3.0 of the Common Vulnerability Scoring Standard (CVSS), which is used as a shorthand for quickly gauging the seriousness of the flaws.
In this update they still ranked the vulnerabilities according to both CVSS 2.0 and 3.0, but will switch to the latter completely in future Security Alerts and Critical Patch Updates (the next CPU is scheduled for 19 July 2016).
The newer scoring standard is supposed to be more accurate than the older one.
ERPScan’s research team posted a good write-up about the Oracle CPU in which they explain the scoring changes succinctly, as well as detail the most critical vulnerabilities fixed in this round of updates.
- wong chee tat :)
Oracle released the April 2016 Critical Patch Update, which provides fixes for 136 vulnerabilities in 49 products, including Java SE and MySQL, the company’s Database Server and E-Business Suite, its Fusion Middleware, and its Sun Systems Products Suite.
Oracle patches
“Oracle continues to periodically receive reports of attempts to maliciously exploit vulnerabilities for which Oracle has already released fixes. In some instances, it has been reported that attackers have been successful because targeted customers had failed to apply available Oracle patches. Oracle therefore strongly recommends that customers remain on actively-supported versions and apply Critical Patch Update fixes without delay,” the company advised.
“There are a few indicators that can help you prioritize what updates you should worry about first. Exploit code examples being available in Metasploit is an easy one. If it is in Metasploit, it is also in the threat actor’s hands. Beyond that things like public disclosures help to identify vulnerabilities that stand a higher chance of being exploited,” noted Shavlik’s Chris Goettl, pointing out that vulnerabilities that get the highest CVSS score (10.0) are usually exploited in the wild in less than a month after they have been disclosed and patched.
Therefore he recommends Java SE, MySQL, and Sun Systems Products Suite to be updated before anything else.
For more information about the specific vulnerabilities and patched, check out the advisory accompanying the update.
It’s interesting to note that Oracle is slowly switching to version 3.0 of the Common Vulnerability Scoring Standard (CVSS), which is used as a shorthand for quickly gauging the seriousness of the flaws.
In this update they still ranked the vulnerabilities according to both CVSS 2.0 and 3.0, but will switch to the latter completely in future Security Alerts and Critical Patch Updates (the next CPU is scheduled for 19 July 2016).
The newer scoring standard is supposed to be more accurate than the older one.
ERPScan’s research team posted a good write-up about the Oracle CPU in which they explain the scoring changes succinctly, as well as detail the most critical vulnerabilities fixed in this round of updates.
- wong chee tat :)
8u91 Update Release Notes
8u91 Update Release Notes
Java™ SE Development Kit 8, Update 91 (JDK 8u91)
The full version string for this update release is 1.8.0_91-b14 (where "b" means "build"). The version number is 8u91.
This update release contains several enhancements and changes including the following.
IANA Data 2016a
JDK 8u91 contains IANA time zone data version 2016a. 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 8u91 are specified in the following table:
| JRE Family Version | JRE Security Baseline (Full Version String) |
|---|---|
| 8 | 1.8.0_91 |
| 7 | 1.7.0_101 |
| 6 | 1.6.0_115 |
JRE Expiration Date
The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 8u91) will expire with the release of the next critical patch update scheduled for July 19, 2016.
For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u91) on August 19, 2016. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see JRE Expiration Date.
Bug Fixes
This release contains fixes for security vulnerabilities. For more information, see Oracle Java SE Critical Patch Update Advisory. For a list of bug fixes included in this release, see JDK 8u91 Bug Fixes page.
The following are some of the notable bug fixes included in this release:
DSA signature generation is now subject to a key strength check
For signature generation, if the security strength of the digest algorithm is weaker than the security strength of the key used to sign the signature (e.g. using (2048, 256)-bit DSA keys with SHA1withDSA signature), the operation will fail with the error message:
For signature generation, if the security strength of the digest algorithm is weaker than the security strength of the key used to sign the signature (e.g. using (2048, 256)-bit DSA keys with SHA1withDSA signature), the operation will fail with the error message:
"The security strength of SHA1 digest algorithm is not sufficient for this key size."
JDK-8138593 (not public)
Firefox 42 liveconnect problem
Because it might cause the browser to hang, we don't process JavaScript-to-Java calls when the Java plugin is launched from plugin-container.exe (the default behavior for Firefox 42) and the applet status is not Ready(2). If the applet is not ready (the status is not 2), we don't execute the actual Java method and only return null.
Because it might cause the browser to hang, we don't process JavaScript-to-Java calls when the Java plugin is launched from plugin-container.exe (the default behavior for Firefox 42) and the applet status is not Ready(2). If the applet is not ready (the status is not 2), we don't execute the actual Java method and only return null.
If the plugin is launched from plugin-container.exe, do not use JavaScript-To-Java calls that may require more than 11 seconds(the default value of dom.ipc.plugins.hangUITimeoutSecs) to be completed or show a modal dialog during JavaScript-To-Java call. In this case, the main browser thread must be blocked, which might cause the browser to hang and the plugin to terminate.
Workaround (for Firefox 42):
User’s can set dom.ipc.plugins.enabled=false. The side effect of this workaround is that it changes the setting for all plugins.
User’s can set dom.ipc.plugins.enabled=false. The side effect of this workaround is that it changes the setting for all plugins.
JDK-8144079 (not public)
New attribute for JMX RMI JRMP servers specifies a list of class names to use when deserializing server credentials
A new java attribute has been defined for the environment to allow a JMX RMI JRMP server to specify a list of class names. These names correspond to the closure of class names that are expected by the server when deserializing credentials. For instance, if the expected credentials were a List, then the closure would constitute all the concrete classes that should be expected in the serial form of a list of Strings.
A new java attribute has been defined for the environment to allow a JMX RMI JRMP server to specify a list of class names. These names correspond to the closure of class names that are expected by the server when deserializing credentials. For instance, if the expected credentials were a List
By default, this attribute is used only by the default agent with the following:
{
"[Ljava.lang.String;",
"java.lang.String"
} Only arrays of Strings and Strings will be accepted when deserializing the credentials.
The attribute name is:
The attribute name is:
"jmx.remote.rmi.server.credential.types"
The following is an example of a user starting a server with the specified credentials class names:
Mapenv = new HashMap<>(1);
env.put (
"jmx.remote.rmi.server.credential.types",
new String[]{
String[].class.getName(),
String.class.getName()
}
);
JMXConnectorServer server
= JMXConnectorServerFactory.newJMXConnectorServer(url, env, mbeanServer);The new feature should be used by directly specifying:
"jmx.remote.rmi.server.credential.types"
"jmx.remote.rmi.server.credential.types"
JDK-8144430 (not public)
Disable MD5withRSA signature algorithm in the JSSE provider
The MD5withRSA signature algorithm is now considered insecure and should no longer be used. Accordingly, MD5withRSA has been deactivated by default in the Oracle JSSE implementation by adding "MD5withRSA" to the "jdk.tls.disabledAlgorithms" security property. Now, both TLS handshake messages and X.509 certificates signed with MD5withRSA algorithm are no longer acceptable by default. This change extends the previous MD5-based certificate restriction ("jdk.certpath.disabledAlgorithms") to also include handshake messages in TLS version 1.2. If required, this algorithm can be reactivated by removing "MD5withRSA" from the "jdk.tls.disabledAlgorithms" security property.
The MD5withRSA signature algorithm is now considered insecure and should no longer be used. Accordingly, MD5withRSA has been deactivated by default in the Oracle JSSE implementation by adding "MD5withRSA" to the "jdk.tls.disabledAlgorithms" security property. Now, both TLS handshake messages and X.509 certificates signed with MD5withRSA algorithm are no longer acceptable by default. This change extends the previous MD5-based certificate restriction ("jdk.certpath.disabledAlgorithms") to also include handshake messages in TLS version 1.2. If required, this algorithm can be reactivated by removing "MD5withRSA" from the "jdk.tls.disabledAlgorithms" security property.
JDK-8144773 (not public)
New certificates added to root CAs
Eight new root certificates have been added :
Eight new root certificates have been added :
QuoVadis Root CA 1 G3
alias: quovadisrootca1g3
DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM
alias: quovadisrootca1g3
DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM
QuoVadis Root CA 2 G3
alias: quovadisrootca2g3
DN: CN=QuoVadis Root CA 2 G3
alias: quovadisrootca2g3
DN: CN=QuoVadis Root CA 2 G3
QuoVadis Root CA 3 G3
alias: quovadisrootca3g3
DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM
alias: quovadisrootca3g3
DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM
DigiCert Assured ID Root G2
alias: digicertassuredidg2
DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US
alias: digicertassuredidg2
DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US
DigiCert Assured ID Root G3
alias: digicertassuredidg3
DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US
alias: digicertassuredidg3
DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US
DigiCert Global Root G2
alias: digicertglobalrootg2
DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US
alias: digicertglobalrootg2
DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US
DigiCert Global Root G3
alias: digicertglobalrootg3
DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US
alias: digicertglobalrootg3
DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US
DigiCert Trusted Root G4
alias: digicerttrustedrootg4
DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US
alias: digicerttrustedrootg4
DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US
See JDK-8145954 and JDK-8145955
- wong chee tat :)
Scheduled Maintenance - POSB
Scheduled Maintenance - POSB
We are constantly upgrading our systems to bring you a more pleasant banking experience. During the mentioned period of scheduled maintenance, some of the services will not be available:
iBanking | ||
|---|---|---|
Date
|
Maintenance Period
|
Services under Maintenance
|
Every Sunday
|
0400hrs to 0700hrs
|
System Maintenance
- Foreign Currency Current Account (FCCA) - Foreign Currency Fixed Deposit (FCFD) - Multi-currency Autosave (MCA) - Multiplier Account |
23 April 2016
|
1625hrs to 1630hrs
|
System Maintenance
- MCSA Funds Transfer, and Portfolio Enquiry |
23 April 2016
|
1625hrs to 0000hrs
|
System Maintenance
- Online Equity Trading (OET) |
23 April 2016
|
1000hrs to 0000hrs
|
System Maintenance
- Online Equity Trading (SG) - iB trading services |
24 April 2016
|
0000hrs to 1900hrs
|
System Maintenance
- Online Equity Trading (SG) - iB trading services |
24 April 2016
|
1245hrs to 1250hrs
1305hrs to 1320hrs 1330hrs to 1345hrs |
System Maintenance
- MCSA Funds Transfer, and Portfolio Enquiry |
27 April 2016
|
0100hrs to 0300hrs
|
System Maintenance
- Credit Card Payment: Pay Other Banks' Visa and Mastercard bills: Make Payment, Add Beneficiary, View/Delete Beneficiary - Send Money to an Overseas Visa Card (Visa Personal Payments): Send Money, Add Beneficiary, View/Delete Beneficiary |
08 May 2016
|
0000hrs to 0600hrs
|
System Maintenance
- Fast Funds Transfer to Other Bank (New/Existing Payee) - Adhoc Fast Funds Transfer to Other Bank - Fast Transaction History - View/Delete Post Dated Funds Transfer |
06 May 2016 to
09 May 2016 |
06 May 2016 2130hrs
to 09 May 2016 0900hrs |
System Maintenance
- Fast Funds Transfer to HSBC Banking (New/Existing Payee) - Adhoc Fast Funds Transfer to HSBC Bank |
digibank app | ||
|---|---|---|
Date
|
Maintenance Period
|
Services under Maintenance
|
23 April 2016
|
1625hrs to 1630hrs
|
System Maintenance
- MCSA Funds Transfer, and Portfolio Enquiry |
24 April 2016
|
1245hrs to 1250hrs
1305hrs to 1320hrs 1330hrs to 1345hrs |
System Maintenance
- MCSA Funds Transfer, and Portfolio Enquiry |
27 April 2016
|
0100hrs to 0300hrs
|
System Maintenance
- Credit Card Payment: Pay Other Banks' Visa and Mastercard bills: Make Payment, Add Beneficiary, View/Delete Beneficiary - Send Money to an Overseas Visa Card (Visa Personal Payments): Send Money, Add Beneficiary, View/Delete Beneficiary |
08 May 2016
|
0000hrs to 0600hrs
|
System Maintenance
- Fast Funds Transfer to Other Bank (New/Existing Payee) - Adhoc Fast Funds Transfer to Other Bank - Fast Transaction History - View/Delete Post Dated Funds Transfer |
06 May 2016 to
09 May 2016 |
06 May 2016 2130hrs
to 09 May 2016 0900hrs |
System Maintenance
- Fast Funds Transfer to HSBC Banking (New/Existing Payee) - Adhoc Fast Funds Transfer to HSBC Bank |
PayLah! | ||
|---|---|---|
Date
|
Maintenance Period
|
Services under Maintenance
|
06 May 2016 to
09 May 2016 |
06 May 2016 2130hrs
to 09 May 2016 0900hrs |
System Maintenance
For PayLah! wallets belonging to non-DBS/POSB iBanking users: - Verification of HSBC Bank accounts - Send money back to HSBC Bank accounts |
- wong chee tat :)
Agent Handlers in an enterprise network
In this figure, all Agent Handlers:
• Are connected to the McAfee ePO SQL database using low-latency high-speed links
• Are located close to the clients they support
• Have failover configured between Agent Handlers in other cities
• Are managed from the McAfee ePO server
The Agent Handlers in these cities have specific configurations.
• Dallas — The Agent Handler is configured with failover support to the Agent Handler in Los
Angeles.
• Los Angeles — The two Agent Handlers have load balancing configured.
• Washington DC — The Agent Handler uses specific ports to connect to the McAfee ePO server
from behind a firewall.
- Ref: ePolicy Orchestrator 5.1.0 Best Practices Guide - Rev B
- wong chee tat :)
Subscribe to:
Posts (Atom)