Don's Pages and my Music

Monday, September 29, 2014

Shellshock - Commands to check for and fix the Shellshock - Bash Vulnerability

Here's a good Article. With the Commands to check for and fix, the Shellshock - Bash Vulnerability. I ran "yum update" and "yum update bash" in my Fedora 14 System and there was no update for Bash, today (09-29-14). There may not be one coming. Since Fedora 14 is Depreciated. And only gets a few Security Updates, every so often. And they only mention Red Hat. Not Fedora, in the Report. Good thing, I'm not running an Open to the Web Server, on this System...

Don

Bash Code Injection Vulnerability via Specially Crafted Environment Variables (CVE-2014-6271, CVE-2014-7169)

Updated 2 hours ago

Red Hat has been made aware of a vulnerability affecting all versions of the bash package as shipped with Red Hat products. This vulnerability CVE-2014-6271 could allow for arbitrary code execution. Certain services and applications allow remote unauthenticated attackers to provide environment variables, allowing them to exploit this issue.

Update: 2014-09-29 05:00 UTC

Malware is circulating that exploits this vulnerability. For more details, see this article.

Update: 2014-09-26 05:15 UTC

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.

Updated bash packages that address CVE-2014-7169 are now available for Red Hat Enterprise Linux 5, 6, and 7, Red Hat Enterprise Linux 4 Extended Life Cycle Support, Red Hat Enterprise Linux 5.6 Long Life, Red Hat Enterprise Linux 5.9 Extended Update Support, Red Hat Enterprise Linux 6.2 Advanced Update Support, and Red Hat Enterprise Linux 6.4 Extended Update Support, and Shift_JIS for Red Hat Enterprise Linux 5 and 6. See also Resolution for Bash Code Injection Vulnerability via Specially Crafted Environment Variables (CVE-2014-6271, CVE-2014-7169) in Red Hat Enterprise Linux.

Diagnostic Steps

Red Hat Access Labs has provided a script to help confirm if a system is patched against to the Shellshock vulnerability. You can also manually test your version of Bash by running the following command:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"  

If the output of the above command contains a line containing only the word vulnerable you are using a vulnerable version of Bash. The patch used to fix this issue ensures that no code is allowed after the end of a Bash function.

Note that different Bash versions will also print different warnings while executing the above command. The Bash versions without any fix produce the following output:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"  vulnerable  bash: BASH_FUNC_x(): line 0: syntax error near unexpected token `)'  bash: BASH_FUNC_x(): line 0: `BASH_FUNC_x() () { :;}; echo vulnerable'  bash: error importing function definition for `BASH_FUNC_x'  test  

The versions with only the original CVE-2014-6271 fix applied produce the following output:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"  bash: warning: x: ignoring function definition attempt  bash: error importing function definition for `x'  bash: error importing function definition for `BASH_FUNC_x()'  test  

The versions with additional fixes from RHSA-2014:1306, RHSA-2014:1311 and RHSA-2014:1312 produce the following output:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"  bash: warning: x: ignoring function definition attempt  bash: error importing function definition for `BASH_FUNC_x'  test  

The difference in the output is caused by additional function processing changes explained in the "How does this impact systems" section below.

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:

$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo  bash: x: line 1: syntax error near unexpected token `='  bash: x: line 1: `'  bash: error importing function definition for `x'  Fri Sep 26 11:49:58 GMT 2014  

If your system is vulnerable, the time and date information will be output on the screen and a file called /tmp/echo will be created.

If your system is not vulnerable, you will see output similar to:

$ 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  

If your system is vulnerable, you can fix these issues by updating to the most recent version of the Bash package by running the following command:

# yum update bash  

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.

See the appropriate remediation article for specifics.

The patch for CVE-2014-7169 introduces changes to how Bash evaluates environment variables. Applications which directly create Bash functions as environment variables need to be made aware of these changes. Previously, a function had to be stored in an environment variable of the same name. For example, the function "compute" would be stored in an environment variable named "compute". With the patch for CVE-2014-7169 applied, it would need to use the name "BASH_FUNC_compute()". As a result, there are now two pairs of parentheses in the environment string, as in "BASH_FUNC_compute()=() { }".

Functions written in Bash itself do not need to be changed, even if they are exported with "export -f". Bash will transparently apply the appropriate naming when exporting, and reverse the process when importing function definitions.

Services that create such environment variables will need to be restarted to work with the new version of Bash. This behavior is not used by any of the packages provided in any version of Red Hat Enterprise Linux.

Products Affected:

Product/Channel Fixed in package Remediation details
Red Hat Enterprise Linux 7 bash-4.2.45-5.el7_0.4 Red Hat Enterprise Linux
Red Hat Enterprise Linux 6 bash-4.1.2-15.el6_5.2 Red Hat Enterprise Linux
bash-4.1.2-15.el6_5.1.sjis.2 Red Hat Enterprise Linux
bash-4.1.2-9.el6_2.2 Red Hat Enterprise Linux 6.2 AUS
bash-4.1.2-15.el6_4.2 Red Hat Enterprise Linux 6.4 EUS
Red Hat Enterprise Linux 5 bash-3.2-33.el5_11.4 Red Hat Enterprise Linux
bash-3.2-33.el5_11.1.sjis.2 Red Hat Enterprise Linux
bash-3.2-24.el5_6.2 Red Hat Enterprise Linux 5.6 LL
bash-3.2-32.el5_9.3 Red Hat Enterprise Linux 5.9 EUS
Red Hat Enterprise Linux 4 bash-3.0-27.el4.4 Red Hat Enterprise Linux 4 ELS

Common Configuration Examples:

Red Hat performed an analysis to better understand the magnitude of this issue and how it affects various configurations. The below list is not exhaustive, but is meant to give some examples of how this issue affects certain configurations, and why the high level of complexity makes it impossible to specify something is not affected by this issue. The best course of action is to upgrade Bash to a fixed version.

Package Description
httpd CGI scripts are likely affected by this issue: when a CGI script is run by the web server, it uses environment variables to pass data to the script. These environment variables can be controlled by the attacker. If the CGI script calls Bash, the script could execute arbitrary code as the httpd user. mod_php, mod_perl, and mod_python do not use environment variables and we believe they are not affected.
Secure Shell (SSH) It is not uncommon to restrict remote commands that a user can run via SSH, such as rsync or git. In these instances, this issue can be used to execute any command, not just the restricted command.
dhclient The Dynamic Host Configuration Protocol Client (dhclient) is used to automatically obtain network configuration information via DHCP. This client uses various environment variables and runs Bash to configure the network interface. Connecting to a malicious DHCP server could allow an attacker to run arbitrary code on the client machine.
CUPS It is believed that CUPS is affected by this issue. Various user supplied values are stored in environment variables when cups filters are executed.
sudo Commands run via sudo are not affected by this issue. Sudo specifically looks for environment variables that are also functions. It could still be possible for the running command to set an environment variable that could cause a Bash child process to execute arbitrary code.
Firefox We do not believe Firefox can be forced to set an environment variable in a manner that would allow Bash to run arbitrary commands. It is still advisable to upgrade Bash as it is common to install various plug-ins and extensions that could allow this behavior.
Postfix The Postfix server will replace various characters with a ?. While the Postfix server does call Bash in a variety of ways, we do not believe an arbitrary environment variable can be set by the server. It is however possible that a filter could set environment variables.

A more detailed analysis of the flaw is available at: https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack

Frequently Asked Questions

This FAQ is for the vulnerability CVE-2014-6271 in Bash.
Some additional information regarding CVE-2014-6271 and CVE-2014-7169 is available at: https://securityblog.redhat.com/2014/09/26/frequently-asked-questions-about-the-shellshock-bash-flaws/

I believe my system may have been compromised due to this vulnerability, what should I do?

If you have run the diagnostic steps in this article, and your system still appears to be vulnerable, or you believe your system has been compromised, open a support case with Red Hat or contact Red Hat support by phone.

Do I need to reboot or restart services after installing this update?

No, a reboot of your system or any of your services is not required. This vulnerability is in the initial import of the process environment from the kernel. This only happens when Bash is started. After the update that fixes this issue is installed, such new processes will use the new code, and will not be vulnerable. Conversely, old processes will not be started again, so the vulnerability does not materialize. If you have a strong reason to suspect that a system was compromised by this vulnerability then a system reboot should be performed after the update is installed as a best security practice and security checks should be analyzed for suspicious activity.

Are other shells vulnerable to this issue?

Red Hat has tested other shells for this issue. We could not reproduce the behavior seen in Bash. If similar issues are discovered in other shells we will release updates as appropriate.

Are there any possible mitigations against this issue?

Please see Mitigating the shellshock vulnerability (CVE-2014-6271 and CVE-2014-7169) for details on potential mitigations if you are unable to install the updated packages. The best mitigation is to install the latest available packages (noted above) as they currently protect against all reported vulnerabilities.

Statement on Red Hat Website Vulnerability

The following Red Hat websites, which provide services to customers have been confirmed to be updated:

  • www.redhat.com
  • access.redhat.com (Red Hat Customer Portal)
  • rhn.redhat.com (Red Hat Network)

Red Hat utilises Salesforce to deliver services to customers. Salesforce have released a statement that it has determined Salesforce services are not vulnerable to this issue.

Red Hat has observed unsuccessful attempts to exploit this vulnerability against the above websites. We continue to monitor our systems to ensure their confidentiality, integrity and availability.

Comments

Read More...
https://access.redhat.com/articles/1200223


Shellshock - Commands to check for and fix the Shellshock - Bash Vulnerability

Shellshock: Better 'bash' patches now available | ZDNet
Shellshock bash patch - Google Search
Shellshock bash patch - Google Search
SHELLSHOCKED: Fortune 1000 outfits Bash out batches of patches • The Register
SMASH the Bash bug! Red Hat, Apple scramble for patch batches • The Register
Bash To Require Further Patching, As More Shellshock Holes Found - Slashdot
security - What is the CVE-2014-6271 bash vulnerability (Shellshock) and how do I fix it? - Ask Ubuntu
How to Protect your Server Against the Shellshock Bash Vulnerability | DigitalOcean
Still more vulnerabilities in bash? Shellshock becomes whack-a-mole | Ars Technica
How to patch OS X for the bash/Shellshock vulnerability | TUAW: Apple news, reviews and how-tos since 2004
Bash Code Injection Vulnerability via Specially Crafted Environment Variables (CVE-2014-6271, CVE-2014-7169) - Red Hat Customer Portal

Sunday, September 21, 2014

Welders - DIY a Professional Spot Welder Made out of a Microwave Transformer - YouTube Video and How To info

Check out this How To Video, on making A Professional Grade Spot Welder Made out of a Microwave Transformer. There's more info, in the links below and check out the related links too...

Don

DIY resistance fine-spot welder

Video Link...
https://www.youtube.com/watch?v=HdyLPcTVVFI

5,735

Published on Nov 2, 2013

A fine-spot welder is one of the few equipment where building yourself is cheaper than buying.
See more here: http://www.avdweb.nl/tech-tips/spot-w...

These are some unique features:
It can be used in 2 welding applications: opposed and series configuration.
The construction is kept very simple.
Accurate electrode force adjustment.
It has a solid electrode holder, made of a radiator earthing clamp.
An Arduino microcontroller is used to set the weld time accurately.
Creates a double pulse which improves clamping.
The current can be reduced for welding sensitive parts.


Medical Records For Sale in Underground Stolen From Texas Life Insurance Firm — Krebs on Security

Here's another Security Breach Story. This one is on Stolen Medical Records in Texas. And it could effect people out side of TX too. Thieves can use this info, to open up Credit Card Accounts and Access Bank Accounts too! These Records were Stolen from an insurance company, in TX. We give way too much Personal information, to Insurance Companies. And not enough attention, is being paid, to the Security of our Data...

Don


Medical Records For Sale in Underground Stolen From Texas Life Insurance Firm

How much are your medical records worth in the cybercrime underground? This week, KrebsOnSecurity discovered medical records being sold in bulk for as little as $6.40 apiece. The digital documents, several of which were obtained by sources working with this publication, were apparently stolen from a Texas-based life insurance company that now says it is working with federal authorities on an investigation into a possible data breach.

Read More...
http://krebsonsecurity.com/2014/09/medical-records-for-sale-in-underground-stolen-from-texas-life-insurance-firm/


Medical Records For Sale in Underground Stolen From Texas Life Insurance Firm 09-21-14


Hackers Selling Stolen Medical Records
Medical Records For Sale in Underground Stolen From Texas Life Insurance Firm — Krebs on Security
Are Credit Monitoring Services Worth It? — Krebs on Security