Security improvements in Red Hat Enterprise Linux 7

Each new release of Red Hat® Enterprise Linux® is not only built on top of the previous version, but a large number of its components incorporate development from the Fedora distribution. For Red Hat Enterprise Linux 7, most components are aligned with Fedora 19, and with select components coming from Fedora 20. This means that users benefit from new development in Fedora, such as firewalld which is described below. While preparing the next release of Red Hat Enterprise Linux, we review components for their readiness for an enterprise-class distribution. We also make sure that we address known vulnerabilities before the initial release. And we review new components to check that they meet our standards regarding security and general suitability for enterprise use.

One of the first things that happens is a review of the material going into a new version of Red Hat Enterprise Linux. Each release includes new packages that Red Hat has never shipped before and anything that has never been shipped in a Red Hat product receives a security review. We look for various problems – from security bugs in the actual software to packaging issues. It’s even possible that some packages won’t make the cut if they prove to have issues that cannot be resolved in a manner we decide is acceptable. It’s also possible that a package was once included as a dependency or feature that is no longer planned for the release. Rather than leave those in the release, we do our best to remove the unneeded packages as they could result in security problems later down the road.

Previously fixed security issues are also reviewed to ensure nothing has been missed since the last version. While uncommon, it is possible that a security fix didn’t make it upstream, or was somehow dropped from a package at some point during the move between major releases. We spend time reviewing these to ensure nothing important was missed that could create problems later.

Red Hat Product Security also adds several new security features in order to better protect the system.

Before its 2011 revision, the C++ language definition was ambiguous as to what should happen if an integer overflow occurs during the size computation of an array allocation. The C++ compiler in Red Hat Enterprise Linux 7 will perform a size check (and throw std::bad_alloc on failure) if the size (in bytes) of the allocated array exceeds the width of a register, even in C++98 mode. This change affects the code generated by the compiler–it is not a library-level correction. Consequently, we compiled all of Red Hat Enterprise Linux 7 with a compiler version that performs this additional check.

When we compiled Red Hat Enterprise Linux 7, we also tuned the compiler to add “stack protector” instrumentation to additional functions. The GCC compiler in Red Hat Enterprise Linux 6 used heuristics to determine whether a function warrants “stack protector” instrumentation. In contrast, the compiler in Red Hat Enterprise Linux 7 uses precise rules that add the instrumentation to only those functions that need it. This allowed us to instrument additional functions with minimal performance impact, extending this probabilistic defense against stack-based buffer overflows to an even larger part of the code base.

Red Hat Enterprise Linux 7 also includes firewalld. firewalld allows for centralized firewall management using high-level concepts, such as zones. It also extends spoofing protection based on reverse path filters to IPv6, where previous Red Hat Enterprise Linux versions only applied anti-spoofing filter rules to IPv4 network traffic.

Every version of Red Hat Enterprise Linux is the result of countless hours of work from many individuals. Above we highlighted a few of the efforts that the Red Hat Product Security team assisted with in the release of Red Hat Enterprise Linux 7. We also worked with a number of other individuals to see these changes become reality. Our job doesn’t stop there, though. Once Red Hat Enterprise Linux 7 was released, we immediately began tracking new security issues and deciding how to fix them. We’ll further explain that process in an upcoming blog post about fixing security issues in Red Hat Enterprise Linux 7.

CVE-2015-1376 (pixabay_images)

pixabay-images.php in the Pixabay Images plugin before 2.4 for WordPress does not validate hostnames, which allows remote authenticated users to write to arbitrary files via an upload URL with a host other than pixabay.com.

Mobile App Developers Unwittingly Aid Criminals

In turn, app developers eager to earn revenues from their hard work find it lucrative to collect as much data from their users as possible in order to offer more ad targeting data, and they can find many convenient ‘mobile monetizing kits’ to handle all the in-app ad publishing details for them.

Unfortunately, both of these practices can cause app developers unwittingly to become a mule for corrupt ad networks and privacy exploits.

Collecting too much information is a privacy risk

Collecting more information from users than is necessary just to have more data to offer to advertisers is not necessarily a good strategy. A recent study published by the Information Commissioner’s Office (ICO) in the UK found that 49% of app users decided not to download an app due to privacy concerns.

If scaring off half of your potential downloads isn’t reason enough to reconsider your app privacy policies, consider the privacy risks and negative publicity. The ICO study was part of a global survey of 1,211 mobile apps, sponsored by the Global Privacy Enforcement Network (GPEN), which enlisted 26 privacy regulators from around the world. The much-publicized conclusion of the survey was that 85% of all apps fail to properly explain what data they are collecting and how they are using it, and that 31% of apps request an “excessive number of permissions to access personal information.”

The numbers and negative attention will only get worse, as privacy groups and media continue to increase their scrutiny of data collection practices.

Corrupt ad networks imperil you and your users

Unbeknownst to many mobile app developers, their ad networks may be engaging in aggressive practices with their users and where the network has been compromised, even installing malware on their phones. Examples include:

  • Directing users to pornographic websites and/or fake app download sites
  • Reading users’ address book contacts and sending outbound emails or calendar event requests
  • Deleting or defacing users’ USB storage accounts connected to the phone
  • Dialing out to revenue-generating numbers or sending premium SMS messages
  • Automatically authorizing in-app purchases

Other technical deficiencies in your mobile app code – such as failing to properly check SSL / TLS certificates or inter-app injection flaws – let hackers exploit your users directly.

With ad-funded mobile apps, the ad network is the data controller technically responsible for stopping malvertisments and other corruptions. But the app developer carries the responsibility to collect only as much user data as needed, to protect that data from exfiltration, and to do background checks of the ad publishing networks being used. Otherwise the mobile app developer may become an unwitting aid to criminals.

The post Mobile App Developers Unwittingly Aid Criminals appeared first on Avira Blog.