Ubuntu LTS: many vulnerabilities despite long-term support

My comments are primarily to those members, especially the security-savvy ones, who anguish over this stuff, similar to what we see in other threads that report on applications with security vulnerabilities. At any rate, I don't want to steer this thread OT.

 

Even more common sense tells that's not enough these days All it takes is one specially crafted file (e.g. even a malformed GNUPG Key) to own a Linux box.
Without grsecurity or other protections (like what Ubuntu does at compilation time to it's packages), it's not hard to crack into a Linux machine, specially now with Snaps I think.

https://micahflee.com/2016/01/debian-grsecurity/

One example of this is the AMD Catalyst driver. It can't operate under grsecurity because it has a really buffer overflow bug. So in order to use Catalyst on Linux you either have to use regular Linux Kernel (because it doesn't care for the overflow, it's not built with 100% security in mind), or you use the grsec kernel but disable CONFIG_PAX_USERCOPY and CONFIG_PAX_MEMORY_UDEREF at the time of compilation, thus making the Kernel way less secure.

Ubuntu, contraty to Debian, builds it's packages with buffer overflow protection, so I don't think it's so easy to exploit it in this regard (not impossible, though). However, given that vulnerabilities are not limited to BOF, and given the fact that Canonical only provides security updates to the Main repo (contrary to Debian who provides security patches to all repos except Non-Free because they can't read the source code), it is highly recommended that users install and run software through at least Firejail (in Ubuntu repos), and if possible, use Grsec as well.

Here's a list showing how vulnerable the Linux Kernel is, how bad other alternatives are, and what grsec can do to protect users (in addition to being the easiest to manage): https://grsecurity.net/compare.php

 

This thread is not meant to frighten people but to help them making an educated decision as I believe that what I wrote is unknown to many users. And it's an important aspect, IMO.

 

I know this matrix of the Ubuntu security features. Is there something similar for Debian?

 

Found it. Although not as comprehensive as the Ubuntu one.

 

Linux expert Matthew Garrett: Ubuntu 16.04's new Snap format is a security risk

-- Tom

 

Thanks.

Yes, the Debian Wiki can be very outdated and poorly formated
For Non-Debian searches, I always use the Arch Wiki.

 

Interesting. My understanding is, this article revealed the true potential and source of danger: the support and development of certain software packages that are maintained by the community could be abandoned at some point. Further fix of the newly discovered security holes will not be possible although the packages are still being used by various distro. Linux really need a centralized, united mechanism in order to remedy this situation.

 

The title of this article is misleading. Snap format will be risky only when X11 is being used, which is not always the case. X11 is bring replaced if my memory serves me well.

 

FYI

https://www.debian.org/security/faq

"Contrib and non-free aren't official parts of the Debian Distribution and are not released, and thus not supported by the security team"

 

Exactly, because these packages either aren't Free (meaning no source-code, meaning no patches can be applied) or they depend on non-free packages.

I think the Main Debian Repo is like Ubuntu's Main+Universe repos together, in terms of what software is there.

 

They can be non-free (non DFSG compliant) and still have source code. Sometimes its only a part of the package that is non-free (such as a binary blob firmware in a Wifi driver), so patches can be applied.

I think so

 

Ubuntu supports less packages than Debian, but for longer with their LTS releases (5 years VS approx 3 years), which is better is down to what your individual requirements are.

 

Further security patches will be possible because the distros have access to the source to patch and build themselves and they already do this frequently.
If you visit the popular sec-lists, you will see that patches are frequently shared and tested.
I don't there is any problem that needs fixing.

 

Common sense is very much user dependant and far from common. Security is an arbitrary perspective and a lot of things need to line up for this "specially crafted file" to exhibit it intended purpose. Regardless of the effectiveness of in-place security measures the key is being able to tell if you are infected. In that case a system restore from a backup image makes any severity redundant for the desktop user, while on servers its a different storey altogether. Security holes, vulnerabilities or insecure operating systems are only as dangerous as ones backup plan. These issues, at most times are severely hyped imo. Im sure many users here agree in some parts with this statement.

Completely agree, it should be governed imo. But that will go against the core beliefs of free software or opensource environments. This will always be the fundamental issue that linux faces. How could this be solved? or Implemented? Is it in every distros best interests to utilise this centralised mechanism?

If im not mistaken, Firejail will soon have this covered or already covers it.

regards.

 

Besides, in a Debian standard installation only main is enabled by default if I'm not mistaken. You have to add contrib and non-free manually to sources.list. This alone makes a difference.

 

Actually the problem is another one: Even if a package still receives updates from upstream many of them in the Ubuntu universe repo are not maintained. A "centralized, united mechanism" wouldn't change that. In the Debian main repo they are maintained: in Debian stable usually no new versions are added but security patches are backported.

 

That depends. I've always used the expert installer, and in there they as if we want to use Contrib and Non-Free, but both options are disabled by default , so if you click Enter by mistake you won't be using those packages.

 

Because someone has dragged "ubuntu snaps" into this discussion, I want to mention this Jan 2016 video
in which Shuttleworth explains the rationale (?) for introducing snaps.
https://www.youtube.com/watch?v=ybuwdpnEbZU
(skip the intro, jump to 11:00 or so)

takeaways:
A distro should rightly be engaged in maintaining the core platform, not in vetting and packaging tens of thousands of apps.
Snap packages approach avoids waiting for various distros to package updated versions of each app.
When a user installs a package, the relationship will be (should be) between the user and the developer.

FWIW, I don't have a horse in the race; I'm not a ubuntu user.

 

The problem relies on the fact that most distros are not rolling-release, so if the package creator/maintainer finds a bug in it = the distro developers have to backport the patches to the version that they are holding back. If they don't do that,the package stays buggy/vulnerable.

If the distro is rolling-release then there's little need to get between the package developer and users.

In regards to Snaps, yes. In regards to the regular repo, no, because the distro developers should ensure all programs are bug/malware Free. That's one of the reasons why we're more secure than Windows

 

Those "takeaways" I typed, they're incomplete but I think they do accurately convey Mr. Shuttleworth's points in his presentation.

Clearly the package maintainers do not unfailingly scrutinize the code within each updated program they're packaging.
Also, package maintainers often preconfigure (or overlook) injudicious program preferences.

In your recent wrestling to remove/avoid "geoclue", you found preinstalled apps which depended on it, right?
Not malware, but unwelcome, and the "distro developers" don't bother to warn you of such potentially unwelcome "features"
present in packages curated by the distro's repo. (Same occurs across most distros, not just ubuntu.)

 

Because geoclue is not malware, neither unwanted by most people. The program is licensed under GPL and the source code shows that every location request is dealt by the user. I couldn't find any evidence that geoclue informs my location without my knowlege - but also, I will not look into the source code of every program I use to see if they respect me.

So I don't think they should take it out just because a few paranoid people like me don't like it

 

Geoclue is easily removed anyway. No need to be paranoid, it's always good to get rid of bloat and tailor the OS to your needs.

 

Just curious whether you think grsec would conflict with AppArmor?

 

It doesn't It's fully compatible:

"unlike the LSMs you're used to, grsecurity and SELinux, or grsecurity and AppArmor, or grsecurity and any other LSM will work together perfectly. In fact, in addition to all the improvements listed below, grsecurity specifically protects several sensitive data structures involved in SELinux and other LSMs that have made them easy targets for kernel exploit writers."

https://grsecurity.net/compare.php