New Initiative Simply Secure Aims to Make Security Tools Easier to Use

The dramatic revelations of large-scale government surveillance and deep penetration of the Internet by intelligence services and other adversaries have increased the interest of the general public in tools such as encryption software, anonymity services and others that previously were mainly of interest to technophiles and activists. But many of those tools are difficult to use […]

Airplane WiFi – Secure surfing or danger for onboard electronics?

The “fasten your seatbelts” signs turn off and you can finally recline, fold down the tray table, and switch on your notebook or tablet. Many airlines now even offer WiFi access in the cabin, so you can surf the Internet, post to Facebook, and write emails without restriction. Hard to believe, given that it wasn’t long ago that you couldn’t even leave your cell phone switched on during the flight. So, is it safe and secure to use WiFi and portable devices? There are two major aspects to this question:

  • First, whether airplane systems are secure, even though WiFi radio waves are used to communicate and passengers have access to the digital infrastructure aboard the airplane.
  • And second, whether passengers’ devices are also safe and secure, as they share the airplane WiFi network with all other users in the cabin.

Hacking airplane systems

A clear answer can be given to the first question, at least at the moment: Yes, the airplane is still safe and secure. The radio waves are irrelevant to the onboard electronics in terms of power and frequency, as the cockpit and internal technology have to be able to cope with completely different types of possible interference. In addition, there is no potential risk of airplane systems being hacked into. Every airplane manufacturer separates the in-flight entertainment and WiFi systems from the critical airplane systems. Furthermore, they use data and signal formats to communicate, which are incompatible with Ethernet; they also don’t use the TCP/IP protocol. Frequently, additional security functions are integrated into the systems, such as specific transmitter restrictions and extremely strict time intervals, within which data must be exchanged between communication partners. And even if there was a widespread failure of the electronics system, irrespective of what measures are taken to deal with it, all flight-critical systems have a mechanical backup – cable controls and hydraulic systems instead of servos and electronic actuators.

This doesn’t mean, however, that airplanes are immune to potential security loopholes. Researchers are repeatedly discovering weaknesses in various systems, such as those involved in satellite communications, which could theoretically be exploited. By exploiting this bug, false positioning data can be transmitted to the airplane while in flight causing a change of course; however, other experts have given the all-clear. Even if a person were able to exploit this security loophole, the pilots themselves could just simply make a course correction. Other means of communication are available in each passenger airplane which allow verification of positioning data and flight plans. On top of this, the flight-control center would also spot each course change and alarm the pilots.

The statistical probability of mounting such attacks successfully is far below the other typical causes of failure, technical or human error, which are also rare. Airplane manufacturers also want to save costs and are trying wherever possible to integrate standard IT components that transfer and process data using standard IT formats.

Airline operators have set out countless operational cases where digital data would improve services, shorten ground times, and resultingly save costs. Whether over the short term or long term, manufacturers will eventually meet these requests and integrate an ever greater amount of standard IT equipment into airplanes. Hopefully the security measures will be tightened to meet the aviation industry’s more stringent requirements.

Security measures above the clouds

So how about the information on your notebook or tablet? WiFi access aboard an airplane is just like a standard public hotspot – no difference from the one in the airport or at Starbucks. Those who use the WiFi network share the wireless network with all other users. Whether airplane manufacturers integrate specific security measures in their switches and routers is information that currently only they know. For this reason exactly, the same security measures that are also suitable at Starbucks or in the airport should apply: Either you encrypt all data traffic using a virtual private network (VPN), which companies usually install on professional users’ devices anyway, or you encrypt each app’s data. In the case of email, this can be done using encryption programs like Pretty Good Privacy (PGP), EnigMail or GnuPG. For browser-based communications, it can be achieved using Secure Sockets Layer (SSL) technology, usually identifiable by the little padlock icon in the address bar. Plug-ins for many browsers can also take care of this automatically if required, such as HTTPS Everywhere for Firefox and Chrome. Naturally, the internal firewall should be enabled on each device and the latest version of a security software solution such as Avira Antivirus Pro, Avira Internet Security Suite or Avira Free Antivirus should also be installed and active.

 

The post Airplane WiFi – Secure surfing or danger for onboard electronics? appeared first on Avira Blog.

Apple Releases Security Updates for iOS, Apple TV, and Xcode

Original release date: September 18, 2014

Apple released security updates for iOS devices, Apple TV, and Xcode to address multiple vulnerabilities, some of which could allow attackers to execute code with system privileges or cause an unexpected application termination.

Updates available include:

  • iOS 8 for iPhone 4s and later, iPod touch 5th generation and later, and iPad 2 and later
  • Apple TV 7 for Apple TV 3rd generation and later
  • Xcode 6.0.1 for OS X Mavericks v10.9.4 and later

Users and administrators are encouraged to review Apple security updates HT6441, HT6442, and HT6444 and apply the necessary updates.


This product is provided subject to this Notification and this Privacy & Use policy.

Enterprise Linux 5.10 to 5.11 risk report

Red Hat Enterprise Linux 5.11 was released this month (September 2014), eleven months since the release of 5.10 in October 2013. So, as usual, let’s use this opportunity to take a look back over the vulnerabilities and security updates made in that time, specifically for Red Hat Enterprise Linux 5 Server.

Red Hat Enterprise Linux 5 is in Production 3 phase, being over seven years since general availability in March 2007, and will receive security updates until March 31st 2017.

<!–Red Hat is transitioning to Red Hat Subscription Management for all Red Hat products by July 31, 2017. All systems registered as clients to Red Hat Network Classic Hosted directly, or indirectly with Red Hat Proxy, must be migrated to Red Hat Subscription Management by July 31, 2017.–>

Errata count

The chart below illustrates the total number of security updates issued for Red Hat Enterprise Linux 5 Server if you had installed 5.10, up to and including the 5.11 release, broken down by severity. It’s split into two columns, one for the packages you’d get if you did a default install, and the other if you installed every single package.

Note that during installation there actually isn’t an option to install every package, you’d have to manually select them all, and it’s not a likely scenario. For a given installation, the number of package updates and vulnerabilities that affected your systems will depend on exactly what you selected during installation and which packages you have subsequently installed or removed.

Security errata 5.10 to 5.11 Red Hat Enterprise Linux 5 ServerFor a default install, from release of 5.10 up to and including 5.11, we shipped 41 advisories to address 129 vulnerabilities. 8 advisories were rated critical, 11 were important, and the remaining 22 were moderate and low.

For all packages, from release of 5.10 up to and including 5.11, we shipped 82 advisories to address 298 vulnerabilities. 12 advisories were rated critical, 29 were important, and the remaining 41 were moderate and low.

You can cut down the number of security issues you need to deal with by carefully choosing the right Red Hat Enterprise Linux variant and package set when deploying a new system, and ensuring you install the latest available Update release.

Critical vulnerabilities

Vulnerabilities rated critical severity are the ones that can pose the most risk to an organisation. By definition, a critical vulnerability is one that could be exploited remotely and automatically by a worm. However we also stretch that definition to include those flaws that affect web browsers or plug-ins where a user only needs to visit a malicious (or compromised) website in order to be exploited. Most of the critical vulnerabilities we fix fall into that latter category.

The 12 critical advisories addressed 33 critical vulnerabilities across just three different projects:

  • An update to NSS/NSPR: RHSA-2014:0916(July 2014). A race condition was found in the way NSS verified certain certificates which could lead to arbitrary code execution with the privileges of the user running that application.
  • Updates to PHP, PHP53: RHSA-2013:1813, RHSA-2013:1814
    (December 2013). A flaw in the parsing of X.509 certificates could allow scripts using the affected function to potentially execute arbitrary code. An update to PHP: RHSA-2014:0311
    (March 2014). A flaw in the conversion of strings to numbers could allow scripts using the affected function to potentially execute arbitrary code.
  • Updates to Firefox, RHSA-2013:1268 (September 2013), RHSA-2013:1476 (October 2013), RHSA-2013:1812 (December 2013), RHSA-2014:0132 (February 2014), RHSA-2014:0310 (March 2014), RHSA-2014:0448 (Apr 2014), RHSA-2014:0741 (June 2014), RHSA-2014:0919 (July 2014) where a malicious web site could potentially run arbitrary code as the user running Firefox.

Updates to correct 32 of the 33 critical vulnerabilities were available via Red Hat Network either the same day or the next calendar day after the issues were public.

Overall, for Red Hat Enterprise Linux 5 since release until 5.11, 98% of critical vulnerabilities have had an update available to address them available from the Red Hat Network either the same day or the next calendar day after the issue was public.

Other significant vulnerabilities

Although not in the definition of critical severity, also of interest are other remote flaws and local privilege escalation flaws:

  • A flaw in glibc, CVE-2014-5119, fixed by RHSA-2014:1110 (August 2014). A local user could use this flaw to escalate their privileges. A public exploit is available which targets the polkit application on 32-bit systems although polkit is not shipped in Red Hat Enterprise Linux 5. It may be possible to create an exploit for Red Hat Enterprise Linux 5 by targeting a different application.
  • Two flaws in squid, CVE-2014-4115, and CVE-2014-3609, fixed by RHSA-2014:1148 (September 2014). A remote attacker could cause Squid to crash.
  • A flaw in procmail, CVE-2014-3618, fixed by RHSA-2014:1172 (September 2014). A remote attacker could send an email with specially crafted headers that, when processed by formail, could cause procmail to crash or, possibly, execute arbitrary code as the user running formail.
  • A flaw in Apache Struts, CVE-2014-0114, fixed by RHSA-2014:0474 (April 2014). A remote attacker could use this flaw to manipulate the ClassLoader used by an application server running Stuts 1 potentially leading to arbitrary code execution under some conditions.
  • A flaw where yum-updatesd did not properly perform RPM signature checks, CVE-2014-0022, fixed by RHSA-2014:1004 (Jan 2014). Where yum-updatesd was configured to automatically install updates, a remote attacker could use this flaw to install a malicious update on the target system using an unsigned RPM or an RPM signed with an untrusted key.
  • A flaw in the kernel floppy driver, CVE-2014-1737, fixed by RHSA-2014:0740 (June 2014). A local user who has write access to /dev/fdX on a system with floppy drive could use this flaw to escalate their privileges. A public exploit is available for this issue. Note that access to /dev/fdX is by default restricted only to members of the floppy group.
  • A flaw in libXfont, CVE-2013-6462, fixed by RHSA-2014:0018 (Jan 2014). A local user could potentially use this flaw to escalate their privileges to root.
  • A flaw in xorg-x11-server, CVE-2013-6424, fixed by RHSA-2013:1868 (Dec 2013). An authorized client could potentially use this flaw to escalate their privileges to root.
  • A flaw in the kernel QETH network device driver, CVE-2013-6381, fixed by RHSA-2014:0285 (March 2014). A local, unprivileged user could potentially use this flaw to escalate their privileges. Note this device is only found on s390x architecture systems.

Note that Red Hat Enterprise Linux 5 was not affected by the OpenSSL issue, CVE-2014-0160, “Heartbleed”.

Previous update releases

We generally measure risk in terms of the number of vulnerabilities, but the actual effort in maintaining a Red Hat Enterprise Linux system is more related to the number of advisories we released: a single Firefox advisory may fix ten different issues of critical severity, but takes far less total effort to manage than ten separate advisories each fixing one critical PHP vulnerability.

To compare these statistics with previous update releases we need to take into account that the time between each update release is different. So looking at a default installation and calculating the number of advisories per month gives the following chart:

Security Errata per month to 5.10This data is interesting to get a feel for the risk of running Enterprise Linux 5 Server, but isn’t really useful for comparisons with other major versions, distributions, or operating systems — for example, a default install of Red Hat Enterprise Linux 4AS did not include Firefox, but 5 Server does. You can use our public security measurement data and tools, and run your own custom metrics for any given Red Hat product, package set, time scales, and severity range of interest.

See also:
5.10, 5.9, 5.8, 5.7, 5.6, 5.5, 5.4, 5.3, 5.2, and 5.1 risk reports.

How to change Safari’s default search engine in iOS 8 for greater privacy

With iOS 8, you can – for the first time – switch your Safari browser’s search engine to alternatives such as DuckDuckGo. Find out why you might want to and, in fairness, why you might NOT want to…

The post How to change Safari’s default search engine in iOS 8 for greater privacy appeared first on We Live Security.

How to make your social media accounts (almost) unhackable

Now more than ever, its important to make sure your social media accounts are safe and secure. Here are our 6 top tips to make your social media accounts almost unhackable.

The post How to make your social media accounts (almost) unhackable appeared first on We Live Security.