Ubuntu LTS: many vulnerabilities despite long-term support

Discussion in 'all things UNIX' started by summerheat, Apr 23, 2016.

  1. wat0114

    wat0114 Registered Member

    Joined:
    Aug 5, 2012
    Posts:
    2,093
    Location:
    Canada
    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.
     
  2. amarildojr

    amarildojr Registered Member

    Joined:
    Aug 8, 2013
    Posts:
    2,065
    Location:
    Brasil
    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
     
  3. summerheat

    summerheat Registered Member

    Joined:
    May 16, 2015
    Posts:
    1,158
    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.
     
  4. summerheat

    summerheat Registered Member

    Joined:
    May 16, 2015
    Posts:
    1,158
    I know this matrix of the Ubuntu security features. Is there something similar for Debian?
     
  5. summerheat

    summerheat Registered Member

    Joined:
    May 16, 2015
    Posts:
    1,158
    Found it. Although not as comprehensive as the Ubuntu one.
     
  6. lotuseclat79

    lotuseclat79 Registered Member

    Joined:
    Jun 16, 2005
    Posts:
    5,385
  7. amarildojr

    amarildojr Registered Member

    Joined:
    Aug 8, 2013
    Posts:
    2,065
    Location:
    Brasil
    Thanks.

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

    oliverjia Registered Member

    Joined:
    Jul 21, 2005
    Posts:
    1,736
    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.
     
  9. oliverjia

    oliverjia Registered Member

    Joined:
    Jul 21, 2005
    Posts:
    1,736
  10. NGRhodes

    NGRhodes Registered Member

    Joined:
    Jun 23, 2003
    Posts:
    2,354
    Location:
    .
    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"
     
  11. amarildojr

    amarildojr Registered Member

    Joined:
    Aug 8, 2013
    Posts:
    2,065
    Location:
    Brasil
    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.
     
  12. NGRhodes

    NGRhodes Registered Member

    Joined:
    Jun 23, 2003
    Posts:
    2,354
    Location:
    .
    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 :)
     
  13. NGRhodes

    NGRhodes Registered Member

    Joined:
    Jun 23, 2003
    Posts:
    2,354
    Location:
    .
    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.
     
  14. NGRhodes

    NGRhodes Registered Member

    Joined:
    Jun 23, 2003
    Posts:
    2,354
    Location:
    .
    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.
     
  15. TS4H

    TS4H Registered Member

    Joined:
    Nov 5, 2013
    Posts:
    523
    Location:
    Australia
    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.
     
  16. summerheat

    summerheat Registered Member

    Joined:
    May 16, 2015
    Posts:
    1,158
    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.
     
  17. summerheat

    summerheat Registered Member

    Joined:
    May 16, 2015
    Posts:
    1,158
    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.
     
  18. amarildojr

    amarildojr Registered Member

    Joined:
    Aug 8, 2013
    Posts:
    2,065
    Location:
    Brasil
    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.
     
    Last edited: Apr 25, 2016
  19. inka

    inka Registered Member

    Joined:
    Oct 21, 2009
    Posts:
    425
    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.
     
  20. amarildojr

    amarildojr Registered Member

    Joined:
    Aug 8, 2013
    Posts:
    2,065
    Location:
    Brasil
    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 ;)
     
    Last edited: Apr 25, 2016
  21. inka

    inka Registered Member

    Joined:
    Oct 21, 2009
    Posts:
    425
    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.)
     
    Last edited: Apr 27, 2016
  22. amarildojr

    amarildojr Registered Member

    Joined:
    Aug 8, 2013
    Posts:
    2,065
    Location:
    Brasil
    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 ;)
     
  23. MisterB

    MisterB Registered Member

    Joined:
    May 31, 2013
    Posts:
    1,171
    Location:
    Southern Rocky Mountains USA
    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.
     
  24. AutoCascade

    AutoCascade Registered Member

    Joined:
    Feb 16, 2014
    Posts:
    671
    Location:
    United States
    Just curious whether you think grsec would conflict with AppArmor?
     
  25. amarildojr

    amarildojr Registered Member

    Joined:
    Aug 8, 2013
    Posts:
    2,065
    Location:
    Brasil
    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
     
Loading...