4 ms·

> A high severity CVE-2017-9780 (CVSS Score 7.2) has indeed been assigned to this vulnerability. Flatpak developers consider this a minor security issue. The a

by thayne 6y ago

> A high severity CVE-2017-9780 (CVSS Score 7.2) has indeed been assigned to this vulnerability. Flatpak developers consider this a minor security issue. The actual wording in the linked release is "This is a minor security update, matching the behaviour on master where we avoid ever creating setuid files or world-writable directories." The wording is perhaps a little ambiguous, but my interpretation of that is, "this is a minor update that fixes a security issue," not "this is an update that fixes a minor security issue." The author also implies that simply including a setuid binary would allow the app itself to get elevated privileges. This seems at odds with the way flatpak uses containers to sandbox the app, and in fact when I looked at the linked CVE, the actual vulnerability is that a seperate attack could use a setuid binary installed as part of a flatpak to get privilege escalation. Don't get me wrong, it's still a sever vulnerability. But it is much more difficult to exploit than the author first led me to believe.

choeger 6y ago
Add to that the first paragraph, which is literally a complaint that flatpack does not make things better compared to rpm. Indeed the one about security updates is valid and my biggest grievance with such an approach. Note, however, that propietary software like sublime could easily use statically linked or embedded libraries anyways, as they do not have to adhere to any packaging guidelines. So this applies only to free software that has been packaged with the distro.
- vetinari 6y ago
  > Indeed the one about security updates is valid and my biggest grievance with such an approach. And that stems from misunderstanding. Flatpak has a concept of runtimes. If you have some basic library that would be updated by your distribution, you have pretty much big chance that it would be part of the runtime and updated by runtime maintainers, not by the application authors. I.e. you would get your security updates, subject to the maintenance period of the runtime (for example, the org.freedesktop.Platform has 2-year support).
  - danieldk 6y ago
    If you have some basic library that would be updated by your distribution, you have pretty much big chance that it would be part of the runtime and updated by runtime maintainers, not by the application authors. Unfortunately, this is not true. Many of the Flathub Flatpaks compile custom versions of a lot widely-used libraries. E.g., the most recently updated Flathub package of an open source project (as of writing), compiles by itself [1]: Boost 1.73, Eigen 3.3.7, OpenCV 4.3.0, exiv2 0.27.2, marble 20.04.1, lensfun 0.3.2, ImageMagick 7.0.10-13, libgphoto2 2.5.25, libusb 1.0.23, jasper 2.0.16, libksane 20.04.1, sane-backends 1.0.27, libqlr master, qtav 1.13.0, x265 3.3 Most of these are standard dependencies that are in most Linux distributions. [1] https://github.com/flathub/org.kde.digikam/blob/2d0b5b369382afa08074bc72b34774c022fe15ef/org.kde.digikam.json https://github.com/flathub/org.kde.digikam/blob/2d0b5b369382...
    - vetinari 6y ago
      Widely used does not mean, that they are good candidate for a platform library. Many of them do not have stable API, so you either keep everything on an ancient version (hopefully compilable against), or stuff breaks. E.g. Boost. Fedora 32, which was released this April, but has version 1.69 (released in Dec 2018), while the current one is 1.73. Similarly, ImageMagick is updated every few days. In these cases, it is better to let the applications decide which versions they want, and keep up with updates.
waihtis 6y ago
This is, btw, the current main problem with the CVE system - something having a CVE doesn't actually mean there's acute risk in it. It requires a lot of technical prowess to actually confirm whether a specific CVE actually is exploitable or not. Then you have to figure out how vulnerable your context of use actually is. Then whether somebody is actually actively using this vulnerability. It's a much longer chain of risk decisions than you would first be lead to believe.
saagarjha 6y ago
CVSS Scores aren’t very accurate, to be honest. Actually, assigning any kind of score to a vulnerability is fairly difficult even if you know what you’re doing.

by thayne 6y ago

choeger 6y ago

Add to that the first paragraph, which is literally a complaint that flatpack does not make things better compared to rpm. Indeed the one about security updates is valid and my biggest grievance with such an approach. Note, however, that propietary software like sublime could easily use statically linked or embedded libraries anyways, as they do not have to adhere to any packaging guidelines. So this applies only to free software that has been packaged with the distro.

vetinari 6y ago
> Indeed the one about security updates is valid and my biggest grievance with such an approach. And that stems from misunderstanding. Flatpak has a concept of runtimes. If you have some basic library that would be updated by your distribution, you have pretty much big chance that it would be part of the runtime and updated by runtime maintainers, not by the application authors. I.e. you would get your security updates, subject to the maintenance period of the runtime (for example, the org.freedesktop.Platform has 2-year support).
- danieldk 6y ago
  If you have some basic library that would be updated by your distribution, you have pretty much big chance that it would be part of the runtime and updated by runtime maintainers, not by the application authors. Unfortunately, this is not true. Many of the Flathub Flatpaks compile custom versions of a lot widely-used libraries. E.g., the most recently updated Flathub package of an open source project (as of writing), compiles by itself [1]: Boost 1.73, Eigen 3.3.7, OpenCV 4.3.0, exiv2 0.27.2, marble 20.04.1, lensfun 0.3.2, ImageMagick 7.0.10-13, libgphoto2 2.5.25, libusb 1.0.23, jasper 2.0.16, libksane 20.04.1, sane-backends 1.0.27, libqlr master, qtav 1.13.0, x265 3.3 Most of these are standard dependencies that are in most Linux distributions. [1] https://github.com/flathub/org.kde.digikam/blob/2d0b5b369382afa08074bc72b34774c022fe15ef/org.kde.digikam.json https://github.com/flathub/org.kde.digikam/blob/2d0b5b369382...
  - vetinari 6y ago
    Widely used does not mean, that they are good candidate for a platform library. Many of them do not have stable API, so you either keep everything on an ancient version (hopefully compilable against), or stuff breaks. E.g. Boost. Fedora 32, which was released this April, but has version 1.69 (released in Dec 2018), while the current one is 1.73. Similarly, ImageMagick is updated every few days. In these cases, it is better to let the applications decide which versions they want, and keep up with updates.

waihtis 6y ago

This is, btw, the current main problem with the CVE system - something having a CVE doesn't actually mean there's acute risk in it. It requires a lot of technical prowess to actually confirm whether a specific CVE actually is exploitable or not. Then you have to figure out how vulnerable your context of use actually is. Then whether somebody is actually actively using this vulnerability. It's a much longer chain of risk decisions than you would first be lead to believe.

saagarjha 6y ago

CVSS Scores aren’t very accurate, to be honest. Actually, assigning any kind of score to a vulnerability is fairly difficult even if you know what you’re doing.