search for: shellshock

...r applying the latest bash RPM listed at http://lists.centos.org/pipermail/centos-announce/2014-September/020594.html : The fixed RPM (bash-3.2-33.el5_10.4.x86_64.rpm) DOES work just fine on CentOS 5.10. However, it DOES NOT work on CentOS 5.4. That is, bash runs fine, but IS STILL VULNERABLE TO SHELLSHOCK! Scary screenie at: http://i.imgur.com/yR7sBjV.png It looks like the released RPM somehow behaves DIFFERENTLY on 5.4 as opposed to 5.10. This has been validated by one of my coworkers; it's apparently not just me. Best, Jessica

Hello all, Amongst a number of modern CentOS machines we have this one RHEL 3 machine (don't ask me why:) and on it we have bash 2.05b. I was trying to compile a version of bash for it that would be Shellshock-proofed. To do that, I downloaded a copy of the code from the GNU along with all the 13 patches, applied the patches, compiled the code and installed the executable. All vulnerabilities appear to be fixed with the exception of CVE-2014-7187. Does anybody know why this may be? Thanks. Boris.

For those of us still in shell shock, the following was sent several days ago under a misleading subject/thread mixed in with a bunch of other nonsense. (Message-ID: <54291071.7010209 at centos.org>) According to Johnny the second bash patch addressed all of the known issues. I had been waiting for a third patch to come through and missed this important information sent on Monday. On

I'm right now handling this beach-ball sized grenade, and trying to figure out which of our services need to be locked down right away. Since dovecot passes values via environment variables based on user input (e.g. username, password, mailbox?) to auxilliary executables (including possibly bash shell scripts), is dovecot vulnerable to this exploit? (This is not a fault of dovecot, but

The AstLinux Team has released 1.2.0. All current users are encouraged to upgrade as this release addresses the bash "ShellShock" bug. New in 1.2.0: * New Linux Kernel 3.2.x * "igb" ethernet driver for Intel Atom C2000 * Enable AES-NI support * New "sip-user-agent" firewall plugin * New versions of Asterisk 11 and 1.8 * Bash "ShellShock" security fixes A full changelog can be viewed in th...

According to the vulnerability test script from shellshocker.net, the latest bash versions on CentOS5 and CentOS6, 3.2-33.el5_11.4 and 4.1.2-15.el6_5.2, resp., are still vulnerable to CVE-2014-6277. In fact, on CentOS6, abrtd will send you a nice report about it. Does anyone know if upstream is working on a fix? [root at host ~]# bash ~/shellshock_tes...

Hi, As part of the bash 'shellshock' bug / vulnerability in unix/linux environments i would like to know whether the use of the samba parameter 'template shell' in my product may cause my product to be vulnerable to the shellshock bug , since this 'template shell' parameter , as per my understanding allows to op...

...The CentOS wiki pages found by a title page search are: http://wiki.centos.org/HelpOnConfiguration/SecurityPolicy http://wiki.centos.org/HowTos/Security http://wiki.centos.org/Security http://wiki.centos.org/Security/Heartbleed http://wiki.centos.org/Security/POODLE http://wiki.centos.org/Security/Shellshock with translations for the zh and zh-tw languages.

On Wed, Feb 4, 2015 at 6:32 PM, Warren Young <wyml at etr-usa.com> wrote: > >>> Most such vulns are against Apache, PHP, etc, which do not run as root. >> >> Those are common. Combine them with anything called a 'local >> privilege escalation' vulnerability and you've got a remote root >> exploit. > > Not quite. An LPE can only be used

...point to something that would >> constitute big flop RedHat of then. One only criticizes something while >> one cares about it ;-) > > Heartbleed was pretty scary, no? I'd consider that at least as bad as > the predictable number generator issue. > Well, heratbleed and shellshock were pretty much global: all systems (not only Linuxes, not to say particular Linux distributions - my FreeBSD boxes were affected too) using openssl or bash were affected... Same bad, yet these were not flops of particular distribution, so whichever system you decided to stick with , you had these...

...y a title page search are: > http://wiki.centos.org/HelpOnConfiguration/SecurityPolicy > http://wiki.centos.org/HowTos/Security > http://wiki.centos.org/Security > http://wiki.centos.org/Security/Heartbleed > http://wiki.centos.org/Security/POODLE > http://wiki.centos.org/Security/Shellshock 1. HelpOnConfiguration/SecurityPolicy = 2007-04-01 1(a). Link 'SecurityPolicy' = HTML status code 404 1(b). Link 'MoinMoin' = 2007-04-01 2. HowTos/Security = 2010-02-19 (RHEL 5) 3. Security = 2014-10-16 and refer to Heartbleed, Shellshock, POODLE *** NOTHING about Firewalls...

...e: >> http://wiki.centos.org/HelpOnConfiguration/SecurityPolicy >> http://wiki.centos.org/HowTos/Security >> http://wiki.centos.org/Security >> http://wiki.centos.org/Security/Heartbleed >> http://wiki.centos.org/Security/POODLE >> http://wiki.centos.org/Security/Shellshock > > > 1. HelpOnConfiguration/SecurityPolicy = 2007-04-01 > > 1(a). Link 'SecurityPolicy' = HTML status code 404 > 1(b). Link 'MoinMoin' = 2007-04-01 > > 2. HowTos/Security = 2010-02-19 (RHEL 5) > > 3. Security = 2014-10-16 and refer to Heartbleed, Shell...

...g flop RedHat of then. One only criticizes something >>>> while >>>> one cares about it ;-) >>> Heartbleed was pretty scary, no? I'd consider that at least as bad as >>> the predictable number generator issue. >>> >> Well, heratbleed and shellshock were pretty much global: all systems >> (not >> only Linuxes, not to say particular Linux distributions - my FreeBSD >> boxes >> were affected too) using openssl or bash were affected... Same bad, yet >> these were not flops of particular distribution, so whichever sys...

I found an interesting email that got caught in my spam quarantine. I?m wondering if dovecot is vulnerable to this kind of code execution (I?m aware that other components could be vulnerable, but this question is specifically targeting dovecot). The idea is to insert shell commands into various header fields that would get executed as part of the message processing/delivery. Examples include:

...Nux! <nux at li.nux.ro> To: CentOS mailing list <centos at centos.org> Subject: Re: [CentOS] yum-plugin-security This plugin does not work on CentOS, at least not yet, there were previous discussions. e.g. http://centos-devel.1051824.n5.nabble.com/CentOS-devel-yum-plugin-security-and-shellshock-td5710031.html ---------------------------- I read this thread and also another, which is refered to therein: http://lists.centos.org/pipermail/centos-devel/2014-September/011893.html > If memory serves the primary factor that is holding this up is a space > requirements issue; the threads...

...ne only criticizes something >>>>> while >>>>> one cares about it ;-) >>>> Heartbleed was pretty scary, no? I'd consider that at least as bad as >>>> the predictable number generator issue. >>>> >>> Well, heratbleed and shellshock were pretty much global: all systems >>> (not >>> only Linuxes, not to say particular Linux distributions - my FreeBSD >>> boxes >>> were affected too) using openssl or bash were affected... Same bad, yet >>> these were not flops of particular distributi...

Hi all, I have difficulties to understand the output of yum-plugin-security. I am on a X86_64 machine and when I query for security updates, yum lists i686 packages, that I don't have installed. -------------------- # yum check-update --security Loaded plugins: changelog, fastestmirror, security Loading mirror speeds from cached hostfile * base: centos.mirror.linuxwerk.com * epel:

...n it comes to quoting because it runs commands on the remote side with the system shell. It would be nice if there were a mode where commands could be run using fork()+exec() or similar, without invoking the shell. This would help avoid quoting confusion, shell metacharacter attacks and things like shellshock. This appears to require a protocol extension to work since RFC 4254 specifies just a string to be passed with exec: https://tools.ietf.org/html/rfc4254#section-6.5 There could be: A client-side option to turn it on. A server-side option (sshd_config, authorized_keys) to allow it. A server-si...

...that would >>> constitute big flop RedHat of then. One only criticizes something while >>> one cares about it ;-) >> Heartbleed was pretty scary, no? I'd consider that at least as bad as >> the predictable number generator issue. >> > Well, heratbleed and shellshock were pretty much global: all systems (not > only Linuxes, not to say particular Linux distributions - my FreeBSD boxes > were affected too) using openssl or bash were affected... Same bad, yet > these were not flops of particular distribution, so whichever system you > decided to stick...

...ver. That?s not what LPE means. ?L? = ?local?, meaning you are logged-in interactively to the server, or have the ability to execute arbitrary commands remotely, which comes to the same thing. The only way Apache can be used in conjunction with an LPE to provide root access is via something like Shellshock. I?m not saying LPEs, remote shell attacks, and arbitrary command execution vulnerabilities do not exist. I?m pointing out that each of these classes of vulnerabilities are rare on their own, and rare times rare equals scarce. There?s no such thing as absolute security. There is only better and...