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