All,

The second fix has just been released for SL.

—Ian

On 26 Sep 2014, at 14:39, [log in to unmask] wrote:

> Hi Ewan, others,
> 
> EGI issued an advisory on this this morning to site and ngi security contacts.  (attached for those who didn't see it via other means)
> 
> A 'heads up' was also sent yesterday.
> 
> SANS has also produced some info - but I haven't looked yet I'm at the EGI big data meeting - but pointer below in case anyone is interested.
> 
> Linda.
> --------------
> 1. How important is Shellshock (which specific types of systems can actually be exploited now)?
> 
> 2. What is the primary way that this vulnerability is being exploited?
> 
> 3. What went wrong? Where did the vulnerability come from?
> 
> 4. How can you find out which of your systems are vulnerable? and How easy it is for attackers to find the vulnerable systems on your network?
> 
> 5. How can you protect yourself? 
> 
> You can see the slides and listen to his briefing at:
> https://isc.sans.edu/forums/diary/Webcast+Briefing+Bash+Code+Injection+Vulnerability/18709
> 
> Storm Center has also posted a FAQ which is being updated as new data is found:
> https://isc.sans.edu/forums/diary/Update+on+CVE-2014-6271+Vulnerability+in+bash+shellshock+/18707
> 
> --------------------------
>> -----Original Message-----
>> From: Ewan MacMahon [mailto:[log in to unmask]]
>> Sent: 26 September 2014 13:30
>> To: Testbed Support for GridPP member institutes (TB-
>> [log in to unmask])
>> Cc: [log in to unmask]
>> Subject: Bash bug
>> 
>> 
>> Afternoon[1] all,
>> 
>> I'm sure everyone's seen the publicity for the new bash security bug already,
>> but here's a summary from me too (since I'm this week's security duty
>> person), and there are a couple of wrinkles to be aware of.
>> 
>> This is actually quite a nasty one, largely because of the sheer range of places
>> that it may be exploitable without that necessarily being obvious - the exploit
>> can be passed down a chain of processes in an environment variable, so if
>> you've got a Python cgi scipt that calls a command written in Perl, that calls
>> something written in C but uses system() to do it, there's probably an implicit
>> execution of bash in there.
>> 
>> The good news is that it's easy to apply the fix - all that's required is a simple
>> update of the bash package and, in general, that'll do it without needing
>> service restarts, node reboots, or anything else invasive, so my practical
>> advice is not to think too deeply about this, just patch everything. The nodes
>> most likely to be problematic are ones you forget about, so not so much the
>> obviously exposed machines like grid worker nodes, but the one-off oddballs
>> like little web servers running local monitoring tools with web interfaces.
>> 
>> The EGI advisory (attached, just in case anyone's not already seen it)
>> mentions CentOS and RHEL updates but not SL; the updates exist for
>> Scientific Linux too, but the advisory (which is on the web at:
>> https://www.scientificlinux.org/sl-errata/slsa-20141293-1/) doesn't seem to
>> have made it to their usual email list.
>> 
>> However, just to complicate matters, there are two versions of the Red Hat
>> update, the first one:
>> https://rhn.redhat.com/errata/RHSA-2014-1293.html
>> and a new one today with a better fix:
>> https://rhn.redhat.com/errata/RHSA-2014-1306.html
>> 
>> As of now, the second update appears not to exist for SL, however, the first
>> update closes the major hole, the vulnerability addressed by the second
>> patch is somewhat less serious. Therefore the current advice is to update to
>> at least the first patch as soon as possible, that will give you bash versions:
>> 
>> SL5: bash-3.2-33.el5.1
>> SL6: bash-4.1.2-15.el6_5.1
>> 
>> Then simply be ready to install the second patch once SL releases it.
>> 
>> If anyone has any systems lurking around with unsupported OSes like SL4,
>> they'll need dealing with too; preferably by simply getting rid of them,
>> otherwise by manually installing a suitably patched bash.
>> 
>> Ewan
>> 
>> 
>> [1] That said 'Morning' initially, but I'm afraid it's taken a while to pull all this
>> together.
> 
> -- 
> Scanned by iCritical.
> 
> <Mail Attachment.eml>