Are You Vulnerable to Shellshock

Run the following two commands,

env X="() { :;} ; echo busted" /bin/sh -c "echo completed"
env X="() { :;} ; echo busted" `which bash` -c "echo completed"

If you see “busted” then you are vulnerable. When I try it on my pc, second command reveal my ubuntu is vulnerable for shellshock. On Ubuntu, /bin/sh is not bash (it is dash). Only bash is affected by this vulnerability. But latest upgrade have fixed the issue.

Use dpkg to check your installed package version:

dpkg -s bash | grep Version

This will look up info on your bash package, and filter the output to only show you the version. The fixed versions are 4.3-7ubuntu1.4, 4.2-2ubuntu2.5, and 4.1-2ubuntu3.1.

For example, I see:

dpkg -s bash | grep Version
Version: 4.3-7ubuntu1.4

and can determine that I am not vulnerable. (when I was vulnerable to shellshock Version: 4.3-7ubuntu1)

The standard update manager will offer you this update. This is a prime example of how security updates are important, no matter what OS you use or how well-maintained it is.

The USN Bulletin states that new versions have been released for Ubuntu 14.04 Trusty Tahr, 12.04 Precise Pangolin, and 10.04 Lucid Lynx (This is why I’m like to stick to a LTS versions). If you are not on one of these LTS versions, but are on a reasonably-recent version, you’ll most likely be able to find a patched package.

 

 

 

 

 

Advertisements

Mobile Devices: The Biggest Growth Force in IT Today

Selection_005Over 1.5 billion smartphones and tablets to be shipped worldwide in 2016,
growing at a combined annual growth rate (CAGR) of over 20%.
In 2013, mobile devices will generate more than half of total industry’s overall
growth. By comparison, the IT industry will grow by only 2.9% in 2013, with the exclusion of mobile devices.
Leaders in the mobile device market, and ultimately in the next generation PC (and
converged PC/mobile device) market will succeed to attract large numbers of
application developers. Market power fundamentally resides in the operating system
and related application platform software, over 80% of which will be controlled by
Apple and Google in 2016

Cloud Driving Mobile and Vice Versa

Selection_007

IDC expects one in three enterprises have already deployed large scale cloud-
based mobile solution deployment or will do so within 18 months.
Furthermore, mobile application developers remain strongly committed to the cloud:
83% of all mobile app developers plan to use cloud-based back-end systems for
their applications.
Over 65% of mobile application developers plan to develop HTML5 and mobile
web applications in 2013

IT Consumerization and Line of Business Buyers

“Line of business” executives (LOB) will be directly involved in 58% of new
investments involving 3 platform technologies in 2013.
In 2016, that number will rise to 80% of new IT investments, with LOB taking the
lead decision-maker role in at least half of those investments.

Mobile Collaboration: The Next Frontier in a $4 Billion Mobile Enterprise Market

Selection_008

Over 60% of organizations will have rolled out mobile applications beyond email
to their workforce and/or customers by the end of 2013.
Over 20% of firms plan to roll out five or more applications in next 12 months.
80% of enterprises plan to invest in mobile app development resources in 2013.

Email has always been the most mature and successful business mobile application,
but 12 months of rapid IT consumerization has accelerated the adoption of more
advanced applications, including mobile content and collaboration tools. These apps enhance the value of collaboration by enabling users to store, access,
and collaborate on their documents with any device and make decisions anywhere,
anytime.

 

 

 

 

 

 

 

Java 9 Features


Oracle has announced the first set of enhancement proposals (known as JEPs)  for Java 9 which has been targeted for release in early 2016.
Three new APIs have been announced:

Process API Updates for interacting with non-Java operating system processes. The limitations of the current API often force developers to resort to native code. The main risk with this API is differences between operating systems, in particular Windows.The design of this API needs to accommodate possible deployment on smaller devices with different operating system models. It should also take into account environments where multiple Java virtual machines are running in the same operating system process. These considerations could lead to a more abstract API and/or increase the design effort.

New HTTP Client that includes HTTP/2 support.
Problems with the existing API and implementation:

  • URLConnection based API was designed with multiple protocols in mind, nearly all of which are defunct now (ftp, gopher, etc.)
  • predates HTTP 1.1 and is too abstract
  • hard to use (much behavior undocumented)
  • works in blocking mode only (one thread per request/response)
  • very hard to maintain

Https 2.0 support depends on TLS ALPN (Application Layer Negotiation Extension) which is not currently supported in JDK. The Http 2.0 spec itself is still in internet-draft form, but is expected to be submitted as a draft standard Nov 2014.

New lightweight JSON API which provide a light-weight API for consuming and generating JSON documents and data streams.. The latter is expected to build upon the JSON support already standardized as part of JSR 353.

There are also three JVM / performance related features announced:

Improve contended locking for better performance when threads are competing for access to objects. Improving contended locking will significantly benefit real world applications, in addition to industry benchmarks such as Volano and DaCapo.

This project will explore performance improvements in the following areas related to contended Java Monitors:

  • Field reordering and cache line alignment
  • Speed up PlatformEvent::unpark()
  • Fast Java monitor enter operations
  • Fast Java monitor exit operations
  • Fast Java monitor notify/notifyAll operations
  • Adaptive spin improvements and SpinPause on SPARC

Segmentation of the JIT compiler’s code cache (for better JIT performance on large applications). Divide the code cache into distinct segments, each of which contains compiled code of a particular type, in order to improve performance and enable future extensions.

The organization and maintenance of compiled code has a significant impact on performance. Instances of performance regressions of several factors have been reported if the code cache takes the wrong actions. With the introduction of tiered compilation the role of the code cache has become even more important, since the amount of compiled code increases by a factor of 2X–4X compared to using non-tiered compilation. Tiered compilation also introduces a new compiled code type: instrumented compiled code (profiled code). Profiled code has different properties than non-profiled code; one important difference is that profiled code has a predefined, limited lifetime while non-profiled code potentially remains in the code cache forever.

The current code cache is optimized to handle homogeneous code, i.e., only one type of compiled code. The code cache is organized as a single heap data structure on top of a contiguous chunk of memory. Therefore, profiled code which has a predefined limited lifetime is mixed with non-profiled code, which potentially remains in the code cache forever. This leads to different performance and design problems. For example, the method sweeper has to scan the entire code cache while sweeping, even if some entries are never flushed or contain non-method code.

Further development of the “smart” Java compiler, sjavac, which promises parallel and shared compilation among other features.

Due to various issues relating to stability and portability, sjavac is not used by default in the JDK build scripts. The first goal of this JEP is to resolve these issues. This involves making sure the tool produces reliable results on all software/hardware configurations at all times.

The overarching goal is to improve the quality of sjavac to the point where it can serve as a general purpose javac wrapper able to compile large arbitrary Java projects.

A follow-on project will explore how sjavac is to be exposed in the JDK tool chain, if at all; this might be a separate supported standalone tool, an unsupported standalone tool, integration with javac, or something else.

Finally, one tantalizing feature has been promised in the form of JEP 201 – Modular Source Code. This is not, as yet, the modularity solution known as Project Jigsaw (initially targeted as part of Java 8).

Project Jigsaw aims to design and implement a standard module system for the Java SE Platform and to apply that system to the Platform itself, and to the JDK. Its primary goals are to make implementations of the Platform more easily scalable down to small devices, improve the security and maintainability, enable improved application performance, and provide developers with better tools for programming in the large.

This JEP is part of the first phase of Project Jigsaw; later JEPs will modularize the JRE and JDK images and then introduce a module system.

The motivations to reorganize the source code at this early stage are to:

  1. Give JDK developers the opportunity to become familiar with the modular structure of the system;
  2. Preserve that structure going forward by enforcing module boundaries in the build, even prior to the introduction of a module system; and
  3. Enable further development of Project Jigsaw to proceed without always having to “shuffle” the present non-modular source code into modular form.