Red Hat Security Advisory 2014-1285-01

Red Hat Security Advisory 2014-1285-01 – Red Hat JBoss Enterprise Application Platform 6 is a platform for Java applications based on JBoss Application Server 7. It was discovered that the implementation of org.hibernate.validator.util.ReflectionHelper together with the permissions required to run Hibernate Validator under the Java Security Manager could allow a malicious application deployed in the same application container to execute several actions with escalated privileges, which might otherwise not be possible. This flaw could be used to perform various attacks, including but not restricted to, arbitrary code execution in systems that are otherwise secured by the Java Security Manager.

Red Hat Security Advisory 2014-1284-01

Red Hat Security Advisory 2014-1284-01 – Red Hat JBoss Data Virtualization is a lean data integration solution that provides easy, real-time, and unified data access across disparate sources to multiple applications and users. JBoss Data Virtualization makes data spread across physically distinct systems—such as multiple databases, XML files, and even Hadoop systems—appear as a set of tables in a local database. This roll up patch serves as a cumulative upgrade for Red Hat JBoss Data Virtualization 6.0.0. It includes various bug fixes, which are listed in the README file included with the patch files.

Twitter has joined the Bounty Programs. Now only Apple remains.

In the technology world, it is now quite common for companies to reward the efforts of those advanced users who dedicate some of their time to uncovering security holes in their programs or platforms.

Although there are still some who are yet to be convinced of the effectiveness of such ‘bounty programs’, many firms apparently see them as being extremely useful, not just to discover new bugs that have gone undetected, but also to get these expert users on their side.

bounty programs - hackers

Such is the value of what is at stake, that most technology companies now have bounty programs in place. A while back, we described the world of bounty programs, and how rewards can fluctuate depending on the company and the importance of the security hole.

Twitter was still among those that had yet to take up the idea. The social network seemed reluctant to put its hand in its pocket to encourage experts to find bugs in its service. Now the company has announced that it’s offering a minimum reward of $140 (get it?) for those who find security holes in Twitter.com, ads.twitter, mobile Twitter, TweetDeck, apps.twitter, as well as in the apps for iOS and Android.

This sum is still way off what others are offering. Bounty programs at firms like Facebook or Google reward users that uncover vulnerabilities with amounts upwards of $500 and$1000 respectively.

bounty programs - facebook

And it’s not only the money that’s different, Twitter’s bounty program also uses a new platform which offers information to anyone who wants to see what each company is offering.

This platform, called HackerOne, is a kind of notice board on which companies announce new features of their bounty programs and where those looking to profit from their ability to sniff out vulnerabilities can easily discover whether it’s worth their while, depending on the money on offer.

This platform was set up in 2012 by several experts who had previously worked in IT security for companies like Facebook, Google or Microsoft. In their previous jobs they had been responsible for coordinating the implementation of bounty programs, so they had first-hand knowledge of the issue. They decided to offer different technology companies, no matter how big or small, the option to delegate the coordination of their bounty programs.

Companies that have taken up the offer include Yahoo!, Square, Automattic and 4chan. So even without offering the same amounts as other firms, there are many companies who, while saving on the costs of running bounty programs, are also addressing the concerns of users who want reassurance that there are no holes in the security of the companies’ platforms. Something that users have been demanding of Twitter for some time.

bounty programs - reward

Apple, still reluctant

The only leading technology company still to launch its own bounty program is none other than Apple. The company has so far taken no steps in this direction, despite the scandals that threatened to tarnish its image in early September when users, including celebrities, had leaked photos, which were hosted in iCloud, published on the Internet. Had there been a program for rewarding hackers that find security holes, perhaps one of those that did find the vulnerability might have warned security officials of the problem and enabled them to act in time. 

They say money can’t buy happiness, but it helps. That’s why, perhaps as a lesson to Apple, the Russian hacker who discovered such a hole in the company’s iCloud was quick to boast of his discovery. As Alexey Troshichev admitted, he would have warned the company about the flaw in the platform if there was a reward. But as there wasn’t, he decided to share the information on Github, where many other experts were able to exploit the hole maliciously, thereby highlighting the importance of bounty programs.

The post Twitter has joined the Bounty Programs. Now only Apple remains. appeared first on MediaCenter Panda Security.

Bash specially-crafted environment variables code injection attack

Update 2014-09-30 19:30 UTC

Questions have arisen around whether Red Hat products are vulnerable to CVE-2014-6277 and CVE-2014-6278.  We have determined that RHSA-2014:1306, RHSA-2014:1311, and RHSA-2014:1312 successfully mitigate the vulnerability and no additional actions need to be taken.


 

Update 2014-09-26 12:00 UTC

We have written a FAQ to address some of the more common questions seen regarding the recent bash issues.

Frequently Asked Questions about the Shellshock Bash flaws


Update 2014-09-26 02:20 UTC

Red Hat has released patched versions of Bash that fix CVE-2014-7169.  Information regarding these updates can be found in the errata.  All customers are strongly encouraged to apply the update as this flaw is being actively attacked in the wild.
Fedora has also released a patched version of Bash that fixes CVE-2014-7169.  Additional information can be found on Fedora Magazine.

Update 2014-09-25 16:00 UTC

Red Hat is 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.
We are working on patches in conjunction with the upstream developers as a critical priority. For details on a workaround, please see the knowledgebase article.
Red Hat advises customers to upgrade to the version of Bash which contains the fix for CVE-2014-6271 and not wait for the patch which fixes CVE-2014-7169. CVE-2014-7169 is a less severe issue and patches for it are being worked on.

Bash or the Bourne again shell, is a UNIX like shell, which is perhaps one of the most installed utilities on any Linux system. From its creation in 1980, Bash has evolved from a simple terminal based command interpreter to many other fancy uses.

In Linux, environment variables provide a way to influence the behavior of software on the system. They typically consists of a name which has a value assigned to it. The same is true of the Bash shell. It is common for a lot of programs to run Bash shell in the background. It is often used to provide a shell to a remote user (via ssh, telnet, for example), provide a parser for CGI scripts (Apache, etc) or even provide limited command execution support (git, etc)

Coming back to the topic, the vulnerability arises from the fact that you can create environment variables with specially-crafted values before calling the Bash shell. These variables can contain code, which gets executed as soon as the shell is invoked. The name of these crafted variables does not matter, only their contents. As a result, this vulnerability is exposed in many contexts, for example:

  • ForceCommand is used in sshd configs to provide limited command execution capabilities for remote users. This flaw can be used to bypass that and provide arbitrary command execution. Some Git and Subversion deployments use such restricted shells. Regular use of OpenSSH is not affected because users already have shell access.
  • Apache server using mod_cgi or mod_cgid are affected if CGI scripts are either written in Bash, or spawn subshells. Such subshells are implicitly used by system/popen in C, by os.system/os.popen in Python, system/exec in PHP (when run in CGI mode), and open/system in Perl if a shell is used (which depends on the command string).
  • PHP scripts executed with mod_php are not affected even if they spawn subshells.
  • DHCP clients invoke shell scripts to configure the system, with values taken from a potentially malicious server. This would allow arbitrary commands to be run, typically as root, on the DHCP client machine.
  • Various daemons and SUID/privileged programs may execute shell scripts with environment variable values set / influenced by the user, which would allow for arbitrary commands to be run.
  • Any other application which is hooked onto a shell or runs a shell script as using Bash as the interpreter. Shell scripts which do not export variables are not vulnerable to this issue, even if they process untrusted content and store it in (unexported) shell variables and open subshells.

Like “real” programming languages, Bash has functions, though in a somewhat limited implementation, and it is possible to put these Bash functions into environment variables. This flaw is triggered when extra code is added to the end of these function definitions (inside the enivronment variable). Something like:

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

The patch used to fix this flaw, ensures that no code is allowed after the end of a Bash function. So if you run the above example with the patched version of Bash, you should get an output similar to:

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

We believe this should not affect any backward compatibility. This would, of course, affect any scripts which try to use environment variables created in the way as described above, but doing so should be considered a bad programming practice.

Red Hat has issued security advisories that fixes this issue for Red Hat Enterprise Linux. Fedora has also shipped packages that fixes this issue.

We have additional information regarding specific Red Hat products affected by this issue that can be found at https://access.redhat.com/site/solutions/1207723

Information on CentOS can be found at http://lists.centos.org/pipermail/centos/2014-September/146099.html.