ICS/Lotus (mostly), Linux, Travel, Skiing, Mixology, and Random Musing of Interest

IBM Protector for Mail Security POODLE Fix

Bill Malchisky  October 22 2014 12:05:00 PM
A day after providing two Technotes on SHA-2, TLS, and POODLE for Domino, IBM released two documents to cover their Protector product. The bulletin covers three vulnerabilities and provides details on each. For the workaround document, mind the side effect mentioned at the bottom, as with some sites, this may introduce a risk assessment against delivery versus the exploit's vulnerability.

1. Bulletin - Security Bulletin: Vulnerabilities in OpenSSL may cause weak cyphers to be used over SSLv3 (POODLE Attack) in IBM Lotus Protector for Mail Security (CVE-2014-3513, CVE-2014-3567, CVE-2014-3568)
2. Suggested workaround - How to protect Lotus Protector for Mail Security against POODLE (Padding Oracle On Downgraded Legacy Encryption) attack

Notation
: It should be noted that the bulletin omits CVE 2014-3566, the primary exploit for POODLE; as per IBM Tech Support they are specifically releasing an HTTPS patch for this exploit--via a PMR opened by a customer.

Hat tip to Samuel Sawatzky for the heads-up.

Silent No More: IBM Makes Security Announcements on SHA-2, TLS, POODLE

Bill Malchisky  October 21 2014 08:45:00 AM
Today (21 Oct 14), IBM created a set of Technotes covering what appears to be a first step in helping soothe the customer and partner concern on the lack of offered direction and plan for resolving the SHA-1, TLS, and POODLE exploits that exist from years of community support and a yet to be implemented capability for increased security. I offer first step as no date for the patch is provided, just that they are stating their intentions and scope with a solution by year-end, which is my conjecture derived from their "several weeks" window statement. Recall that Google forced the hand by what appears to be an arbitrary cut-off for accepting SHA-1 SSL certificates in their browsers (and exempts customers who buy their SSL certificates from Google, I will add).

With IBM responding now, customers, partners --- including ISVs --- can now plan accordingly. Happy to have these documents. Thank you, IBM.


Here is what IBM offered

1. How is IBM Domino Affected by POODLE?
2. Planned SHA-2 Delivers for IBM Domino 9.x
3. As people will undoubtedly ask, Is it Possible to Run IBM HTTP Server (IHS) on the Same Computer as a Domino Server?


Notations

1. These SHA-2 fixes are for ND9 only, and do not work with 8.5.3 due to changes in the security model inherent to each build
2. The POODLE fix goes back to D8.5.1FP5
3. They are covering all the appropriate Internet protocols that your customers use

"With this Interim Fix, Domino administrators will be able to configure Domino 9.x to use a SHA-2 certificate over HTTP, SMTP, LDAP, POP, and IMAP. With a SHA-2 certificate in place, users will be able to use a browser to connect to iNotes, XPages, traditional Domino Web apps, and Sametime (based on Domino HTTP)."




New SSL3 Exploit: The POODLE Is Here and Lifting Its Leg

Bill Malchisky  October 15 2014 03:12:00 AM
Fix Update -
{Update 9, 17 Oct 2014} As companies are working day and night to get a fix for this product, I will keep checking and update you here. Red Hat has a few patches for their various OS releases but they are reported as incomplete and thus not formally released yet. The rest of the post has been updated eight times since initial publication and is pretty static now as we are all in a wait-state until a patch is formally approved and released.
{Update 10, 17 Oct 2014, 10:01 PM} Starting to see smaller client side packages with POODLE fixes being released.
{Update 11, 18 Oct 2014 2:43 AM} Server-side partial fix announced
See the new Impact section below for the two attack permutations, their impact, and risk, plus links to the RHEL version specific package errata in "Fixing the Exploit" at the bottom

Now we are just waiting for primary exploit fix and client-side browsers to ensure that you have a full and complete solution. This gets you one-third of the way there.



Here we go again... another blockbuster security exploit with another clever code name is announced. POODLE (Padding Oracle On Downgraded Legacy Encryption) CVE-2014-3566 specifically allows a man-in-the-middle style attack utilizing an SSL3 connection. Once again, Red Hat does a stellar job offering full details on background, technical specifics, and testing. Google's Online Security Blog post is exceedingly terse when contrasting. Here is what you need to know.

What is It?

CVE-2014-3566 allows one to decrypt ciphertext using a padding oracle side-channel attack. Look at it this way... this exploit sees every SSL server as a fire hydrant and the man-in-the-middle style POODLE has been drinking water for a long time. The scope is bigger than Shellshock, in my opinion, as it hits any server running SSL 1.0, 2.0, 3.0, and TLS 1.0, plus client-side applications like browsers, but the damage impact appears to be less that one can cause with Shellshock as there is not a remote code execution capability and your system would have some capacity to be productive. To that point, it is (or should be) a high priority for any vendor who hosts SSL and is listed as a high impact
Red Hat published a Security impact key.


Severity

It is categorized as a High priority and High Severity, which is the third highest of the former and second highest on the latter. So, although this is a nasty exploit, the damage to your systems could be worse. In summary, take care of it, but do not panic.

Red Hat is making this a top priority and has a KB article (#1232123) on the subject. Excerpts are below. Also, Google's security blog has a couple of paragraphs on this exploit and an eye towards a patch for their products.

Impact

{Update 10 - 17 OCT 2014; new section}
Two Attack Permutations
1. Man-in-the-Middle: To quote Red Hat on this exploit's impact, they say, "Exploiting this vulnerability is not easily accomplished. Man-in-the-middle attacks require large amounts of time and resources. While likelihood is low, Red Hat recommends implementing only TLS to avoid flaws in SSL." -- Red Hat via Knowledge Base Article 1232123;
2. Fallback Attack -- correlated secondary exploit, explained below.

Red Hat (among others) indicated a TLS Fallback option to let client side applications (e.g. Browsers) to inform a server that they can handle the newer SSL/TLS versions (safer ones). Here is the issue, not all browsers support this capability. So rather than being dropped, a dubious connection attempts to revert to a lower protocol version when the server supports a newer secure protocol version, the unsupported browser flavors allow the insecure protocol connection--creating a POODLE exploit.

Chromium is the only Linux graphical browser that supports the fallback attack security. Once enabled on a server, the client must support it as well. Firefox and Curl (tui browser) are vulnerable at the time of this writing.

Additional concerns

As a workaround, it has been suggested to disable SSL and utilize TLS until a proper SSL patch is released. This of course works for HTTPs client tools that support TLS. If the tool does not understand TLS and you disable SSL, then you have zero security which is much worse than having a POODLE vulnerable SSL version in production.
Therefore, it is quite important to understand your use case needs before implementing any workaround.
Note:
Technical details on the browser attack are located here.

A fix for the openssl packages that addresses the Fallback attack is available; the primary SSL3 exploit remains open. See "Fixing the Exploit" section below.



Testing for the Vulnerability

Three convenient tests exist to verify the status of concerned servers.
1. Run this command on your server or remotely if easier to see if your server is vulnerable. This does not text specific applications on said server that may be configured to use SSLv3. Change the "$(hostname)" value to a FQDN.

malchw@san-domino:~$if echo Q | openssl s_client -connect $(hostname):443 -ssl3 2> /dev/null | grep -v "Cipher.*0000"; then echo "SSLv3 enabled"; else echo "SSLv3 disabled"; fi


Results

Negative: SSLv3 disabled
Positive: SSLv3 enabled

2. Red Hat Access Lab created a SSLv3 (POODLE) Detector  GUI testing tool including a browser check, a BASH shell script to check servers offline, and a realtime check for public facing-servers via a FQDN and port of your choosing--launched from their network. You will need an RHN account to access it. I like the third option with Red Hat's tool because it can make easy work allowing customers while at work to check outside their office with ease.

3. If you want a more verbose output, try the original test here
malchw@san-domino:~$ openssl s_client -connect localhost:443 -ssl3

malchw@san-domino:~$ openssl s_client -connect [hostname.foo.com]:443 -ssl3


Note: Change the port number and hostname to suite your specific test case.


Positive result

If you see something similar to this, you are vulnerable
Results - New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA

Server public key is 1024 bit

Secure Renegotiation IS NOT supported

Compression: NONE

Expansion: NONE

SSL-Session:

Protocol  : SSLv3



Negative Result

Else, you are fine, if this excerpt is close to your output:
140128201074504:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1257:SSL alert number 40

140128201074504:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596:

---

New, (NONE), Cipher is (NONE)

Secure Renegotiation IS NOT supported

Compression: NONE

Expansion: NONESSL-Session:


I suspect most servers with SSL will have SSL3 enabled, making the situation more wide-spread than some people may realize. This is operating system agnostic, so Microsoft, IBM, Red Hat, Oracle, VCE, et alia will all have upcoming product lists with affected products and tools, needing attention.


Fixing The Exploit
-- {Update 18 Oct 2014 - Patches released}
Fix Announced
-- 1 of {n}
Red Hat offers a fix for POODLE's secondary Fallback attack exploit is available under advisory: RHSA-2014:1652-1 for RHEL 6, 7 plus address two memory leak fixes that can cause a crash; and RHSA-2014-1653-1 for RHEL 5.
After patching, be certain to restart the httpd,ssld, and all other SSL-enabled services running on your box. And patch your box prior to applying this patch, to ensure success. Details from OpenSSL are available in their POODLE security advisory.

"The openssl packages errata linked [above] do not address the SSL 3.0 protocol issue, to which the CVE-2014-3566 was assigned.  They add support for the TLS_FALLBACK_SCSV, which enables TLS servers to detect forced protocol downgrades against clients that do re-connect protocol version fallback.  Both server and client need to implement this feature, and clients have to actively use it for the protection to work." --Tomas Hoger, Red Hat Product Security

If you need assistance in applying package updates from RHN, see article 11258.

Further details on the main link provided as made available.


{Update - four times this morning, plus early evening, 15 Oct, EDT}
At this time a proper fix is unavailable. As of midnight EDT on Wednesday, Red Hat has not released a fix yet, but is working on it. Other companies will need to do the same, as well as browser ISVs to ensure compatibility. In the mean time, the suggested work-arounds are as follows:
1. Disable SSLv3 on your servers
2. Even if impractical to do disable SSLv3, consider using TLSv1.1 and TLSv1.2 with the  TLS_FALLBACK_SCSV parameter on your TLS servers enabled (Internet white paper draft available). This process may cause a few issues with some IBM products (to be fair, most vendors products will have issues even temporarily)
3. If you run nginx, here is a solution: https://news.ycombinator.com/item?id=8456178
4. If you are running Domino, you need a TLS 1.1+ server in-front of it, as IBM has not provided a solution; fellow IBM community member, Darren Duke has a work-around with Apache on Ubuntu utilizing TLS 1.2 (and v1.1) for advanced users
--The problem with Domino as it is now is that if you remove SSLv2 and SSLv3, then you need a new TLS solution in-front of that server for protocols such as HTTP, SMTP, et alia.
5. As Domino is directly impacted, please add your voice here as well

{Update - 12:08 PM EDT}
6. As Craig Wiseman reminded me, there are a few great (but hardly trivial) nginx workarounds published by the community
Jesse Gallagher: Domino and SSL: Come with Me If You Want to Live
Richard Moy: Installing Nginx Reverse Proxy on CentOS for Domino Our Experience
Ray Davies: Domino Interface: Installing Nginx Reverse Proxy on CentOS for Domino Our Experience
{End of Update}

Red Hat's in-scope products (at this time) are here:
Product
Affected Component(s)
Red Hat Enterprise Linux Tomcat, Firefox/Chromium, httpd, OpenSSL
JBoss Enterprise Middleware Tomcat/JBoss Web, httpd, OpenSSL
Red Hat Network Satellite Tomcat
Red Hat Certificate System Tomcat
Inktank Ceph Enterprise httpd
Red Hat Enterprise OpenShift OpenShift Configuration , RHC client tools
Red Hat Enterprise Linux OpenStack Platform httpd
Red Hat CloudForms httpd
Red Hat Directory Server Directory Server Configuration
Red Hat Enterprise Virtualization RHEV-M








Notations

1. Each affected component's hotspot offers a product specific technote on how to address the fix for the specific product and more focused testing too;
2. The table is current at the time of this writing and may expand as a fix is released by Red Hat and other products identified
3. To their credit Red Hat is working constantly to update their product list and resolution guides, adding the four appended rows to this table, early evening, 15 Oct 2014 EDT; and now a fifth for Enterprise Virtualization, late afternoon, 17 October 2014 EDT

Google provided a white paper entitled, This POODLE Bites: Exploiting the SSL 3.0 Fallback, which provides greater detail on the TLS suggested settings and the exploit itself. Google is suggesting the use of TLS_FALLBACK_SCSV too.

More later when a fix is released. Good luck.

Shellshock - Final Fix Released: Time to Re-Patch

Bill Malchisky  September 29 2014 12:17:00 AM
Author's Note: Thank you to the ICS community for their tremendous support of my first Shellshock post. For those that read it early, you received critical information 14-72 hours before many sites released their stories. Several readers were fully patched before big names tweeted the issue. You were well ahead of the curve. Shellshock stories released over the weekend proved outdated and incomplete. This post provides better information faster. I am grateful for your support.


As I mentioned last week, the Shellshock bug is real, but the then available fix handled all exploits but one. Very early on Saturday, 27 September 2014, a patch became available after two days of community scrutiny. Getting patched for this exploit is important to ensure a full complete production-grade solution for the Shellshock bug. Fortunately, the fix for this and two the two additional Bash exploits identified is trivial to apply.


New Exploits Identified

"The original flaw in Bash was assigned CVE-2014-6271. Shortly after that issue went public a researcher found a similar flaw that wasn’t blocked by the first fix and this was assigned CVE-2014-7169. Later, Red Hat Product Security researcher Florian Weimer found additional problems and they were assigned CVE-2014-7186 and CVE-2014-7187. It’s possible that other issues will be found in the future and assigned a CVE designator even if they are blocked by the existing patches." --Via Red Hat's Shellshock FAQ

The excellent work of Florian Weimer at Red Hat in identifying two additional moderate exploits. Because of this, you should see reference to the later exploits if you are using a GUI update tool like Ubuntu's Update Manager (image below). Regardless, follow the respective distro update step provided below to ensure you are protected. Then, test for success.

Red Hat updated their Shellshock Impact Statement for this issue.

Image:Shellshock - Final Fix Released: Time to Re-Patch


Testing for the Initial Remaining Exploit
-- CVE-2014-7169
The fix for CVE-2014-7169 ensures that the system is protected from the file creation issue. To test if your version of Bash is vulnerable to CVE-2014-7169, run the following command:

[malchw@localhost Desktop]$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo


Positive Result

bash: x: line 1: syntax error near unexpected token `='

bash: x: line 1: `'

bash: error importing function definition for `x'

Sun Sep 28 00:03:50 PDT 2014


Negative Result

date

cat: /tmp/echo: No such file or directory


Notations

1. If you are running any Linux appliance, security server, or server application on Linux such as IBM Protector, ensure you test for this exploit
2. Apple Macintosh computers running OS X are in-scope, albeit casual users are a lower risk, power users should take this exploit seriously
3. No reboot is required when updating Bash
4. The fix for CVE-2014-7169 includes fixes for CVE-2014-7186 and CVE-2014-7187 if you updated Bash on or after Saturday, 27 September: indicated with RHSA-2014:1306-1, RHSA-2014:1311-1, and RHSA-2014:1312-1
(Japanese coding fix)
-- RHSA = Red Hat Security Advisory
5. Red Hat just released a Shellshock Vulnerability Detector shell script which you can run instead -- available here
6. The fix for CVE-2014-7169 is Important and should be patched; the two new moderate exploits being addressed is not justification for this type of blog post, just a bonus


Applying the Fix

Some distros released a Bash update early Sunday morning, 28 September. Ubuntu's fix hit my machines at 2:15 am EDT.
Red Hat made the fix available via RHN and all registered systems can download it easily, else you download the file from RHN for manual installation.
The confirmation section below shows you how to ensure you have the correct patch installed, as the fix version management can get confusing.
RHEL: # yum update bash
On my older RHEL 5 box: # rpm -Uvh bash-3.2-33.el5_11.4.i386.rpm
Centos: # yum update bash
Ubuntu: $update-manager -or- $sudo apt-get update

Notations

1. If you receive the message, "No Packages marked for Update", then run # yum clean all && yum bash install
2. If you are still seeing this message and you have not updated bash, pull the latest file from your distro's support site
3. Apple was notified privately by the Bash maintainer several times along with a patch to use: Apple still has not released a fix (as of this post's time-stamp)
4. Hat tip Frank for providing a Mac solution for power users, located here

UPDATES
5. Apple finally released a Bash update for Mavericks, Lion, and Mountain Lion via App Store, as of dinner time, EDT
Hat tip Theo for the patch link
6. IBM released an updated Bash patch for Protector over the weekend, replacing Friday's Bash patch
Hat tip Mathieu for the patch update


Example Output - RHEL 6.5 Client

[root@localhost ~]# yum update bash

Loaded plugins: product-id, refresh-packagekit, rhnplugin, security,

 : subscription-manager

This system is receiving updates from Red Hat Subscription Management.

This system is receiving updates from RHN Classic or RHN Satellite.

rhel-6-desktop-rpms                                      | 3.7 kB     00:00    
rhel-6-desktop-rpms/primary_db                           |  27 MB     01:10    
rhel-x86_64-client-6                                     | 1.8 kB     00:00    
rhel-x86_64-client-6/primary                             |  18 MB     00:19    
rhel-x86_64-client-6                                                10417/10417

Setting up Update Process

Resolving Dependencies

--> Running transaction check

---> Package bash.x86_64 0:4.1.2-15.el6_4 will be updated

---> Package bash.x86_64 0:4.1.2-15.el6_5.2 will be an update

--> Finished Dependency Resolution


Dependencies Resolved


================================================================================

Package    Arch         Version                Repository                 Size

================================================================================

Updating:

bash       x86_64       4.1.2-15.el6_5.2       rhel-6-desktop-rpms       905 k


Transaction Summary

================================================================================

Upgrade       1 Package(s)


Total download size: 905 k

Is this ok [y/N]: y

Downloading Packages:

bash-4.1.2-15.el6_5.2.x86_64.rpm                         | 905 kB     00:02    
Running rpm_check_debug

Running Transaction Test

Transaction Test Succeeded

Running Transaction

Updating   : bash-4.1.2-15.el6_5.2.x86_64                                 1/2
Cleanup    : bash-4.1.2-15.el6_4.x86_64                                   2/2
rhel-6-desktop-rpms/productid                            | 1.7 kB     00:00    
Verifying  : bash-4.1.2-15.el6_5.2.x86_64                                 1/2
Verifying  : bash-4.1.2-15.el6_4.x86_64                                   2/2

Updated:

bash.x86_64 0:4.1.2-15.el6_5.2                                                


Complete!



Confirmation of Success

[root@localhost ~]# cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo

date

cat: /tmp/echo: No such file or directory

[root@localhost tmp]#


On Red Hat based systems, you want to ensure that you have the ".2" release for your respective newer version, as below for my RHEL 6.5 box
[root@localhost tmp]# rpm -qi bash-4.1.2

rpm -qi bash-4.1.2

Name        : bash                         Relocations: (not relocatable)

Version     : 4.1.2                             Vendor: Red Hat, Inc.

Release     : 15.el6_5.2  
                 Build Date: Thu 25 Sep 2014 08:10:26 AM PDT
Install Date: Sun 28 Sep 2014 12:16:27 AM PDT      Build Host: x86-023.build.eng.bos.redhat.com


Results after the first Shellshock Bash release fix -- using my CentOS 6.5 box, which fails the above test (patched after this query).
[bill@localhost tmp]$ rpm -qi bash

Name        : bash                         Relocations: (not relocatable)

Version     : 4.1.2                             Vendor: CentOS

Release     : 15.el6_5.1
                   Build Date: Wed 24 Sep 2014 07:45:54 AM PDT
Install Date: Wed 24 Sep 2014 11:05:39 PM PDT      Build Host: c6b8.bsys.dev.cen


Red Hat Bash Releases with the New Fix (Also Addressing CentOS)

* RHEL 7 - bash-4.2.45-5.el7_0.4
* RHEL 6 - bash-4.1.2-15.el6_5.2
* RHEL 5 - bash-3.2-33.el5_11.4


Additional Mitigation Options

The linked document contains several mitigations if you are waiting for approval to patch, or are unable to patch your servers.
Via Red Hat -- Mitigating the shellshock vulnerability (CVE-2014-6271 and CVE-2014-7169)

Linux Bash Bug - Shellshock - is Real: Get Patched (AIX, Mac Too)

Bill Malchisky  September 25 2014 06:00:00 AM
This is ugly, but fortunately you just have to update to a fixed Bash version and you are fine (for now). No need to reboot your system either. Red Hat is out early on this and escalated this appropriately. Their first round of updates got all but one exploit permutation, so they re-issued another bug identifier and are working to close it soon.

Their initial timeline: Red Hat announced the bug on 14 Sep, had a proposed upstream patch seven hours later (0500h 15 Sep), backported it to Bash 3.0, 3.1, 3,2, 4.0, 4.1, and 4.2 three days later on 18 Sep; announced the release 1h later and made it public with an updated issue description six hours after that. Pretty impressive. On the 24th, Red Hat provided public documentation on this matter; six hours later it was reported that the fix is missing one exploit, so they are working to resolve that as I write this post. Things move fast in the world of open source.

Impact Statement
from Red Hat, provides direct prose for the next two sections. "Bash Code Injection Vulnerability via Specially Crafted Environment Variables (CVE-2014-6271)"

Abstract Update

Red Hat has become aware that the patch for
CVE-2014-6271 is incomplete. An attacker can provide specially-crafted environment variables containing arbitrary commands that will be executed on vulnerable systems under certain conditions. The new issue has been assigned CVE-2014-7169. Red Hat is working on patches in conjunction with the upstream developers as a critical priority.

How does this impact systems

This issue affects all products which use the Bash shell and parse values of environment variables. This issue is especially dangerous as there are many possible ways Bash can be called by an application. Quite often if an application executes another binary, Bash is invoked to accomplish this. Because of the pervasive use of the Bash shell, this issue is quite serious and should be treated as such.
All versions prior to those listed as updates for this issue are vulnerable to some degree.


Test If You Have The Bug

malchw@san-domino:~/Documents/$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test" env x='() { :;}; echo vulnerable' bash -c "echo this is a test"


Positive Result

vulnerable

this is a test


Negative Result

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test


Notations
1. Your response may be something similar and be just fine; the difference is getting noise versus a clean response as the positive result indicates
2. Run this check on any Apple Mac product running OS X, as tests show Macs are vulnerable
3. Anyone running AIX, Solaris, or HP-UX should also check, as Bash is available on those systems

Addition - 26 September 2014
4. Update -- IBM released a patch for Protector that addresses Shellshock; verified by a customer of its success


Mitigation

Red Hat's Security Blog has a detailed analysis of which programs utilizing Bash can cause issues and why. "Bash specially-crafted environment variables code injection attack"


Resolution

Ideally, you need to be running bash-4.1.2-15 with current RHEL versions. Despite the bug's significance, the fix is really easy.
RHEL: #yum clean all && yum update bash
On my older RHEL 5 box: # rpm -Uvh bash-3.2-33.el5.1.i386.rpm

CentOS: #yum clean all && yum update bash
Ubuntu: $update-manager -or- $sudo apt-get update

If you know the version number, you can always specify it too (package name example is for RHEL6.5)
# yum update bash-4.1.2-15.el6_5.1


-OR-
Get the update manually and update the RPM -> https://rhn.redhat.com/rhn/errata/details/Packages.do?eid=27888

Note
: the "clean all" parameter above tells yum to clean all cached data, ensuring that bash can be updated more reliably, particularly with older systems; it may be considered optional on current systems


Distro Provided Resolution Documents

CentOS posted a document on the exploit and obtaining fixes through their list serv, "[CentOS] Critical update for bash released today."
Red Hat's is here: "Resolution for Bash Code Injection Vulnerability via Specially Crafted Environment Variables (CVE-2014-6271) in Red Hat Enterprise Linux"
Novell/SUSE; bug report with patches here
Debian
Ubuntu

Example Output - CentOS 6.5

[root@localhost ~]# yum clean all && yum update bash

Loaded plugins: fastestmirror, refresh-packagekit, security

Cleaning repos: base extras updates

Cleaning up Everything

Cleaning up list of fastest mirrors

Loaded plugins: fastestmirror, refresh-packagekit, security

Determining fastest mirrors

* base: centos.chi.host-engine.com

* extras: cosmos.cites.illinois.edu

* updates: mirror.atlanticmetro.net

base                                                     | 3.7 kB     00:00    
base/primary_db                                          | 4.4 MB     00:05    
extras                                                   | 3.3 kB     00:00    
extras/primary_db                                        |  19 kB     00:00    
updates                                                  | 3.4 kB     00:00    
updates/primary_db                                       | 5.3 MB     00:06    
Setting up Update Process

Loaded plugins: fastestmirror, refresh-packagekit, security

Loading mirror speeds from cached hostfile

* base: mirrors.lga7.us.voxel.net

* extras: mirror.es.its.nyu.edu

* updates: centos.aol.com

Setting up Update Process

Resolving Dependencies

--> Running transaction check

---> Package bash.x86_64 0:4.1.2-15.el6_4 will be updated

---> Package bash.x86_64 0:4.1.2-15.el6_5.1 will be an update

--> Finished Dependency Resolution


Dependencies Resolved

================================================================================

Package       Arch            Version                   Repository        Size

================================================================================

Updating:

bash          x86_64          4.1.2-15.el6_5.1          updates          905 k


Transaction Summary

================================================================================

Upgrade       1 Package(s)


Total download size: 905 k

Is this ok [y/N]: y

Downloading Packages:

bash-4.1.2-15.el6_5.1.x86_64.rpm                         | 905 kB     00:00    
Running rpm_check_debug

Running Transaction Test

Transaction Test Succeeded

Running Transaction

Updating   : bash-4.1.2-15.el6_5.1.x86_64                                 1/2
Cleanup    : bash-4.1.2-15.el6_4.x86_64                                   2/2
Verifying  : bash-4.1.2-15.el6_5.1.x86_64                                 1/2
Verifying  : bash-4.1.2-15.el6_4.x86_64                                   2/2

Updated:

bash.x86_64 0:4.1.2-15.el6_5.1                                                


Complete!



Quick and Dirty Work-around
, provided by Jake DePoy
# iptables --append INPUT -m string --algo kmp --hex-string '|28 29 20 7B|' --jump DROP


The Red Hat Customer Portal indicates the risk with the above work-around,
"Is not a good option because the attacker can easily send one or two characters per packet and avoid this signature easily. However, it may provide an overview of automated attempts at exploiting this vulnerability."

Ryder Cup Skype Chat Announced

Bill Malchisky  September 24 2014 08:07:54 PM
Image:Ryder Cup Skype Chat Announced

It is that time again when the best pro golfers in The United States of America take on the best pro golfers in Europe for the coveted Ryder Cup. This year, it is played at the beautiful Gleneagles course in Scotland designed by pro golf legend Jack Nicklaus, who describes his course hole by hole. Play commences Friday, Saturday at 7:35am local time, or 2:35am EDT, with a more respectable Sunday start at 11:36a local time, or 6:36a EDT for singles play.

I will open a Skype chat for the event. If you would like to join, leave a comment below, DM me, e-mail me with the subject ("Ryder Cup") or send me a message on Skype directly. Good luck and may the team with the best overall record win. :)



Team USA's site is here
Team Europe's site is here

Electronic Coverage Options

Watch the live stream here;
The iOS app is here;
The Android app is here;
The TV app is here for Samsung devices.

Big News for ICS Partners!

Bill Malchisky  September 17 2014 09:43:00 PM
After three years of working with IBM, I am proud to make the first public announcement of the beta milestone of a new IBM community feedback continuity tool entitled, Voice of the Partner. ICS is behind this at the highest levels and there is a strong desire within IBM to make this a success.

Imagine that as a partner you have a tool where you can input ideas and concerns to IBM and receive a response in a meaningful way, that also ensures continuity of feedback throughout the issue's life span. This tool will be a handshake if you will, from the partner community to IBM on pressing matters where other partners can contribute, join the conversation on relevant issues to them, share their concerns and be part of the process.

The goal of Voice of the Partner is to strengthen the relationship between IBM and its valued partners.

I have been working with IBM executives to create this bi-directional communication tool through which partners input concerning matters and then receive a response through a visible dashboard including a resolution timetable, issue owner, and item status with details -- updated quarterly. Each item of course contains a link to the underlying forum details to provide context and continuity.


Timeline

We are live in Greenhouse -- ready for the beta
Image:Big News for ICS Partners!

Beta 1: 19 September -- six week duration; small participation already filled; finalize dashboard, review workflow
Beta 2:  3 November -- six week duration; direct input from expanded participants, logistics review, debugging; (Still finalizing this list--if your company is interested in filling a slot, contact me)
Launch: 15 December -- go live date for the entire partner community

I want to thank IBM for working with me to help ensure this tool became a reality. Please comment below with any questions you might have.

Using Sametime Mobile? Avoid iOS 8 for Now

Bill Malchisky  September 16 2014 04:36:15 AM
IBM released a Technote yesterday on the issues with their Sametime Mobile applications on iPhones and iPads running iOS 8 -- due for release on Wednesday, 17 September 2014. My friends Gabriella Davis and Matteo Bisi both blogged on the Technote. Beyond that, there exists a post on The Sametime Blog offering a behind-the-scenes look as to the challenges therein, written by the on-premises Sametime Product Manager - Marlon Machado. In meeting Marlon previously, I can tell you he is a good guy and I appreciate his candor in getting ahead of this, which allows customers to plan and avoid internal help desk calls. I dislike telling customers that they have to wait to upgrade their Apple mobile devices, but if your users want to run Sametime, then you need to tell them now: wait.

Here is Marlon's post, via The Sametime Blog entitled, "About IBM Sametime Mobile Apps and iOS8".

I AM Speaking at ICON UK

Bill Malchisky  September 11 2014 10:00:00 AM
Image:I AM Speaking at ICON UK

Long story short, I will be speaking this Friday, 12 September in London, for the ICON UK renaissance. You can find me acting as emcee for the Ask IBM session at 2:00pm (1400h) and then again at 3:45pm (1545h) presenting The Headless Collaborator: Sametime 9 Command Line Install.

If you are in London for this wonderful event, please do say, "Hi," or better yet, attend one of my sessions. See you Friday!

iNotes Users -- Chrome 37 Creates Compatibility Issues

Bill Malchisky  September 5 2014 01:35:57 PM
IBM released today, a new Technote for iNotes users, entitled, "Some iNotes operations fail to work correctly in Chrome browsers upgraded to Chrome version 37" and is available here.

These five key areas introducing concern stem from Google deprecating the showModalDialog API.
1. Create/Edit Mail rule
2. Contacts Form and the Print action
3. Calendar view and results window displayed when using the "Import Holidays" action (off the "More" menu)
4. Preferences (Select default folder, Preferred rooms/resources site, Change HTTP password error, Security/Show ID info)
5. Validation of entered names/address from certain input forms where "Ambiguous Name", "Name not found" and "Certificate error" dialog might occur (Preferences, To Do, Group Calendar, Group, Phone Message)

As a work-around, Google is allowing the API to be available in a manually applied patch until May 1, 2105, with developer details located here.

The Technote provides two workarounds to handle the situation for impacted users--either one, or none may be appropriate for your organization, which then also introduces the avoidance permutation.

Updated -- Below here
As IBM codes a permanent fix by removing all requests for this API call, one hopes for an iNotes hotfix soon, particularly as Mozilla expressed interest in removing this API call too.


Further Reading

The initial change pitch is cited here
Blink Intents - Issue Dashboard spreadsheet captures the link, see row 59
"Intent to Remove: window.showModalDialog()" is linked here
"Window.showModalDialog: What it is and why you should never use it"
"Issue 345831: Delete showModalDialog" is linked here, commenced on 24 Feb 2014
For more information on iNotes, the documentation portal is located here

Powered by IBM Lotus Domino 8 | Lotus User Group | Get Firefox! | This blog is listed on Planet Lotus   IBM Certified

© 2010 William Malchisky.