Wednesday, August 15, 2018

L1 Terminal Fault: Privileged memory access vulnerability in Intel CPUs

Update (08/17)

A regression has been detected in Ubuntu 14.04 in certain instance types, which causes a kernel panic during boot time. More details can be found in Launchpad. Users are advised not to upgrade the kernel in Ubuntu 14.04 until a fix is released.

For users running other operating systems, it is highly recommended to create a full backup of the disk before upgrading the kernel version.


On August 14th 2018, three vulnerabilities affecting x86 processors manufactured by Intel were disclosed:
The security issue is referred to as L1 Terminal Fault (L1TF) by the industry, and as “Foreshadow” by the security researcher.

The L1 Terminal Fault security issue exploits critical vulnerabilities in modern processors. It allows attackers to access sensitive data in a personal computer or third party clouds.

With L1TF, a malicious program can exploit an operating system’s Page Table by reading the data referenced to the virtual memory, before the CPU is able to confirm that a page table entry is valid. Once the Page Table Entry is set as invalid, the CPU signals a Terminal Fault to the OS.

L1 Terminal Fault affects the following systems:

  • Operating systems running virtual machines.
  • Cloud instances: Depending on the cloud provider's infrastructure, it might be even possible to steal data from other customers.

Our team is working on updating all the affected Virtual Machines and Cloud Images available through Bitnami in all our cloud providers. This will ensure that all new launches will be secured against this issue.

At this time, there are patches available for the following operating systems:
  • Ubuntu
  • Oracle Linux
  • Red Hat Enterprise Linux
  • CentOS
  • Amazon Linux
If you are running a Bitnami stack, or you have any running server or virtual machine, we encourage you to apply these patches immediately in order to avoid exploitation of this security issue. You need to update the operating system yourself.

In order to update your operating system, you must follow the instructions below (depending on your distribution or operating system):
  • Ubuntu 14: A regression was detected which causes a kernel panic in certain instance types. Users are advised not to upgrade the kernel in Ubuntu 14.04 instances yet.
  • Ubuntu 16 and 18: Create a full backup of the disk, and then execute the command below.
sudo apt-get update && sudo apt-get dist-upgrade
  • Oracle Linux, Red Hat, CentOS and Amazon Linux: Create a full backup of the disk, and then execute the command below.
sudo yum update
  • Windows and macOS:
Update your system packages when the operating system suggests it. Enable the "Check for updates" option in Windows to get the latest updates and patches.

Once you have completed the steps above, you will have the updated kernel/operating system version after rebooting your server. If you are running on a Linux server, execute the following command to restart it:

sudo shutdown -r now 'Kernel upgrade requires reboot'

NOTE: If, after rebooting, you cannot access the instance via browser or SSH, it is highly likely that the cloud provider assigned a new dynamic IP address to your instance. In this case, enter your cloud provider administration panel to check the new IP address.

If you have any questions about this process, please post to our community support forum and we will be happy to help!

Check out the official Foreshadow site [4] and the RedHat article explaining the attack [5], for more information.

More information can be found in the following links:

Monday, August 13, 2018

Self-service Apps - Automating the Packaging-to-publishing Experience for Kubernetes with Bitnami Stacksmith and Kubeapps

Do you have the need to make containerized applications available to your internal teams? Here is a great way to accomplish not only that, but also automate the workflow associated with packaging, launching, and updating these applications. Learn how combining Bitnami Stacksmith and Kubeapps can provide a marketplace experience from within your current Kubernetes cluster. You can use this one simple workflow to package, deploy and maintain the applications you have developed, the commercial software you have customized, or the older applications you are migrating.

Stacksmith provides automated application packaging and ongoing maintenance of your applications. Kubeapps provides a complete application delivery environment that empowers users to launch, review and share applications. Together they offer a powerful packaging-to-launch experience for Kubernetes applications.

We created a brief how-to video that shows you how easy it is to integrate both Stacksmith and Kubeapps with your preferred artifact repository (such as JFrog Artifactory or ChartMuseum). Doing so streamlines and automates the packaging, updating, and publishing of your applications to a Kubernetes cluster.

In the video, we demonstrate the following:
  • Use Stacksmith to package a .Net Core application for Kubernetes
  • Once packaged, Stacksmith pushes the container image to the registry and the Helm chart to the artifact repository
  • Kubeapps scans the artifact repository and makes the application deployable with just a few clicks
  • The application gets launched via Kubeapps
  • Over time, components of your application will need updating (security and package updates are tracked by Stacksmith). Re-package your application with Stacksmith
  • Stacksmith pushes the updated container image to the registry and the Helm chart to the artifact repository
  • Kubeapps fetches the new version of your application


Besides the convenience and automation provided by integrating Stacksmith and Kubeapps with the repositories that store and verify assets, are there other benefits? Yes - doing so provides an end-to-end solution that maintains trust between development, security and operations. Now you can ensure that your code, dependencies, security policies, operations scripts and orchestration come from a trusted repository, and that they will get securely and continuously packaged.

Generate, maintain, store and present - trusted applications from trusted artifacts

And Bitnami can deliver these benefits regardless of your level of DevOps sophistication, whether you are using only basic tools or have a fully automated process in place. It is easy to integrate the packaging, distribution, and maintenance capabilities we are talking about here into any existing tool chain or DevOps process.

Learn more - check out the video and visit the Stacksmith and Kubeapps pages.

Wednesday, August 8, 2018

Enterprise CI / CD Integration and Application Packaging

By Matt Small, Head of Customer Success 

Application Packaging is probably not something you’re familiar with hearing about as part of a “CI/CD process.” Most companies that are working towards full DevOps automation feel that as long as the Dev side and the Ops side are automated independently, tying those two processes together is all that’s needed. However, that is a challenging problem when you’re dealing with a heterogeneous collection of team-selected tools in your tool chain. Enterprises that encourage Development and Operations teams to select the best tools for the job are getting stuck trying to implement policies and best practices that can handle that heterogeneity. This heterogeneity in tooling and the rapid pace at which that tooling is changing also means the beginning of the end for the full-stack developer in the Enterprise. It’s just not feasible for someone to know it all well enough to enforce it all.

New, container-centric CI tools that leverage the relative simplicity that container abstraction provides try and merge the two entirely: a check-in of code will automatically deploy that code. While that’s the ideal approach to automation, it ignores both legacy premise-based infrastructure as well as evolving trends in the industry toward PaaS and FaaS. As new applications are built and as old ones are modernized, they too will be heterogeneous in nature and designed to take advantage of the best-fit cloud services.

That’s a lot of of technical complexity and distributed tribal knowledge that must be managed just to answer the questions “what is this application, how does it run, and is it up to date?” 

A logical place to answer that question is in the Application Package. If done correctly, Enterprises now have a way to define their infrastructure in an application-centric way, inclusive of the code, the dependencies, the configuration and the orchestration required to deliver that application. This is how Bitnami Stacksmith handles application packaging. Developers, Security and Operations continue to use their tooling of choice to trigger the process, and Application Packaging automation pulls in the required Artifacts and Assets from their trusted sources to create deployment ready outputs that can be picked up downstream.

Examples of ways to integrate application packaging and maintenance with your CI / CD tools

In practice, Developers push their code to their CI tool of choice and may also contribute their application dependencies and configuration logic as scripts in their source control management tool of choice. Information Security teams maintain OS hardening process and other security policies as scripts or orchestration templates. Operations contributes best practices, reference deployment automation, and prefered cloud service configurations and defines their preferred Template and image output formats. A new contribution from any team triggers a repackaging process, ensuring that the resulting Templates, Images, Containers and PaaS integrations are continuously maintained and up-to-date.

In addition to team-provided changes, updates and changes to the OS and application system packages, dependencies, and any related CVEs should also prompt a repackaging. This tightens the refresh cycle and ensures that the process can be made continuously secure.

The package is an immutable and versionable point in time in an application’s lifecycle. It promotes best practices in testing, providing the ability to launch and test against all components of the application as a complete package. It facilitates in-place application upgrades using native cloud orchestration tooling as well as leveraging blue-green release process or canary deployments by recreating net-new deployments for a full refresh. It also simplifies roll-back, allowing previous application packages to be completely redeployed.

Logging the image creation process gives you a detailed record of the event and every step of the process, as well as a manifest of everything that was packaged into the images or containers and is now immutable. These logs and manifests provide important assurances to the organization: assurance that everyone’s contributions are verifiably included, that the IT infrastructure is auditable, and that no affected library is left unpatched in the event of a critical vulnerability.

As the cloud continues to rapidly evolve with more services and functions, as tooling continues to evolve with new strategies and optimized approaches, the Application Package remains at the center of the DevOps handoff, providing the needed flexibility for application and infrastructure stakeholders to leverage their own best-fit tools and services while enforcing the policies and best practices that are important to them.

Want to learn more? Join us on August 27 at 9 am Pacific for a Stacksmith demo where we will focus on this topic. See it first hand with a live demo, and ask any questions you have. Register here.