You are not logged in.

#1 2020-03-25 21:21:06

Cyberpunk_Is_Bae
Member
Registered: 2020-03-23
Posts: 36

How Do We Stack Up For CVEs?

Thanks for your time in reading my post.

I'm reading:
https://www.cvedetails.com/
https://cve.mitre.org/


I'm looking around at different CVE information databases and having a really hard time getting a lock on how we generally rank on total number of && severity of the vulnerabilities we can expect when using Arch daily.  I would appreciate any useful input on how to go about pulling up this information in both a singularly useful (scoped only to Arch itself) and also comparative (scoped relative to other major distributions) so that I can better understand my own system, and make an apples-to-apples comparison without bias.

Thank you in advance for any help.

Offline

#2 2020-03-25 22:07:53

loqs
Member
Registered: 2014-03-06
Posts: 17,196

Re: How Do We Stack Up For CVEs?

https://security.archlinux.org/ is scoped to arch but a distribution being vulnerable does not mean your particular system would be even if the package in question is installed e.g. CVE-2020-9383 requires a floppy drive.
Also there is no guarantee any such list is comprehensive e.g. it has no record of any vulnerabilities ever being present in ming https://bugs.archlinux.org/task/57961

Offline

#3 2020-03-25 22:50:11

SurlyCycler
Member
Registered: 2019-10-26
Posts: 47

Re: How Do We Stack Up For CVEs?

If your interested you can use the code below and see which ones are on your own system

$ arch-audit

on my machine i have

Package openjpeg2 is affected by CVE-2019-6988. Low risk!
Package podofo is affected by CVE-2018-20751. Low risk!
Package qemu is affected by CVE-2019-20382. Low risk!
Package unzip is affected by CVE-2018-1000035. Low risk!

they have been around for a while and are low grade. Im not particularly worried about them.
If i chose to i am sure i could find replacements for them or just wait for an update that fixes it.

Offline

#4 2020-03-25 22:58:40

loqs
Member
Registered: 2014-03-06
Posts: 17,196

Re: How Do We Stack Up For CVEs?

podofo has a few more vulnerabilities see https://bugs.archlinux.org/task/61651

Offline

#5 2020-03-26 00:04:51

Cyberpunk_Is_Bae
Member
Registered: 2020-03-23
Posts: 36

Re: How Do We Stack Up For CVEs?

I guess maybe a good follow-up question is, how do I delineate between OS-specific bugs and package bugs?  Will checking a repo (core vs extra vs community etc) be sufficient?

Offline

#6 2020-03-26 00:39:50

loqs
Member
Registered: 2014-03-06
Posts: 17,196

Re: How Do We Stack Up For CVEs?

Could you explain more about what you mean by OS-specific bugs and package bugs?

Offline

#7 2020-03-26 00:53:51

Cyberpunk_Is_Bae
Member
Registered: 2020-03-23
Posts: 36

Re: How Do We Stack Up For CVEs?

Certainly.

Each distribution of Linux shares certain packages or as one might think of it in Windows/OSX land "Apps" or "Programs" - I mean to, attempt mind you, to compare apples-to-apples (no pun intended) on just the core of the subset of al things which are not "Apps" or "Programs" (because compatibility of these will vary on the order of hundreds or thousands and conflate my readings) and to compare solely the integral parts of each OS on its own merit.  My goal is to feel or think myself more confident in distribution choice and to have a better understanding of the Linux landscape.  I apologize if the second part is out of the scope of this forum, but I hope you will humor me.

Thank you for any help.

Offline

#8 2020-03-26 01:10:40

loqs
Member
Registered: 2014-03-06
Posts: 17,196

Re: How Do We Stack Up For CVEs?

Installation_guide#Install_essential_packages covers the minimal set of packages expected to be installed.  It should be noted dependencies of those packages can pull in more packages.

Offline

#9 2020-03-26 01:57:59

Cyberpunk_Is_Bae
Member
Registered: 2020-03-23
Posts: 36

Re: How Do We Stack Up For CVEs?

Right... I'm just trying to figure out how to limit my CVE details to those things without going through each one individually, but this may be an impossible/unreasonable task given our current level of tech.

Thanks though.

Offline

#10 2020-03-26 04:13:43

loqs
Member
Registered: 2014-03-06
Posts: 17,196

Re: How Do We Stack Up For CVEs?

None of the packages listed on https://security.archlinux.org/ is in base + linux + linux-firmware which expands to

Packages (117) acl-2.2.53-2  archlinux-keyring-20200108-1  argon2-20190702-2  attr-2.4.48-2  audit-2.8.5-6  bash-5.0.016-1  bzip2-1.0.8-3  ca-certificates-20181109-3
               ca-certificates-mozilla-3.51-1  ca-certificates-utils-20181109-3  coreutils-8.31-3  cracklib-2.9.7-2  cryptsetup-2.3.1-1  curl-7.69.1-1  db-5.3.28-5  dbus-1.12.16-5
               device-mapper-2.02.186-5  diffutils-3.7-3  e2fsprogs-1.45.6-1  expat-2.2.9-3  file-5.38-3  filesystem-2019.10-2  findutils-4.7.0-2  gawk-5.0.1-2  gcc-libs-9.3.0-1
               gdbm-1.18.1-3  gettext-0.20.1-3  glib2-2.64.1-1  glibc-2.31-2  gmp-6.2.0-1  gnupg-2.2.20-1  gnutls-3.6.12-1  gpgme-1.13.1-3  grep-3.4-1  gzip-1.10-3  hwids-20200306-1
               iana-etc-20200311-1  icu-65.1-3  iproute2-5.5.0-1  iptables-1:1.8.4-1  iputils-20190709-2  json-c-0.13.1-3  kbd-2.2.0-5  keyutils-1.6.1-3  kmod-27-1  krb5-1.17.1-1
               less-551-3  libarchive-3.4.2-1  libassuan-2.5.3-2  libcap-2.33-1  libcap-ng-0.7.10-1  libcroco-0.6.13-1  libelf-0.178-2  libffi-3.2.1-4  libgcrypt-1.8.5-2
               libgpg-error-1.37-1  libidn2-2.3.0-1  libksba-1.3.5-2  libldap-2.4.49-1  libmnl-1.0.4-3  libnetfilter_conntrack-1.0.7-1  libnfnetlink-1.0.1-3  libnftnl-1.1.5-1
               libnghttp2-1.39.2-2  libnl-3.5.0-2  libp11-kit-0.23.20-3  libpcap-1.9.1-2  libpsl-0.21.0-2  libsasl-2.1.27-2  libseccomp-2.4.2-1  libsecret-0.20.2-1  libssh2-1.9.0-2
               libtasn1-4.16.0-1  libtirpc-1.2.5-1  libunistring-0.9.10-2  libusb-1.0.23-2  libutil-linux-2.35.1-1  libxml2-2.9.10-1  licenses-20191011-2  linux-api-headers-5.4.17-1
               lz4-1:1.9.2-2  mkinitcpio-27-3  mkinitcpio-busybox-1.31.1-1  mpfr-4.0.2-2  ncurses-6.2-1  nettle-3.5.1-2  npth-1.6-2  openssl-1.1.1.e-1  p11-kit-0.23.20-3  pacman-5.2.1-4
               pacman-mirrorlist-20200207-1  pam-1.3.1-2  pambase-20190105.1-2  pciutils-3.6.4-1  pcre-8.44-1  pcre2-10.34-3  perl-5.30.1-1  pinentry-1.1.0-5  popt-1.16-12
               procps-ng-3.3.16-1  psmisc-23.3-2  readline-8.0.004-1  sed-4.8-1  shadow-4.8.1-1  sqlite-3.31.1-1  systemd-245.2-2  systemd-libs-245.2-2  systemd-sysvcompat-245.2-2
               tar-1.32-3  tzdata-2019c-3  util-linux-2.35.1-1  xz-5.2.5-1  zlib-1:1.2.11-4  zstd-1.4.4-1  base-2-2  linux-5.5.11.arch1-1  linux-firmware-20200224.efcfa03-1

Offline

#11 2020-03-26 05:40:28

progandy
Member
Registered: 2012-05-17
Posts: 5,184

Re: How Do We Stack Up For CVEs?

You might be interested in packages like arch-audit or pacaudit
https://wiki.archlinux.org/index.php/Pacaudit


| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

Offline

#12 2020-03-26 13:40:24

Cyberpunk_Is_Bae
Member
Registered: 2020-03-23
Posts: 36

Re: How Do We Stack Up For CVEs?

loqs wrote:

None of the packages listed on https://security.archlinux.org/ is in base + linux + linux-firmware which expands to

// giant ass list of packages

Hmm maybe I'm just being paranoid.  I read about Ubuntu getting pwned during Pwn2Own this year and just assumed the base components of the OS were as full of holes as the package universe clearly is given the number of CVE's that exist everywhere (on any flavor of Linux, let alone another less audited or closed-source OS).

Do we generally just assume the base components are "completely" secure then?

progandy wrote:

You might be interested in packages like arch-audit or pacaudit
https://wiki.archlinux.org/index.php/Pacaudit

Yeah I really like arch-audit, thanks for the tip to both you and SurlyCycler.  I also really like how in Linux, if I don't like or trust a package due to an audit, I can just remove it, or I can delete the executable within it until a fix is provided.  I'm really digging the way of the penguin.

Offline

#13 2020-03-26 14:22:56

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,449
Website

Re: How Do We Stack Up For CVEs?

Cyberpunk_Is_Bae wrote:

That was reportedly a kernel bug - so the fact that it was done on Ubuntu is tangetial.  The same could have been done on any linux including arch.

Cyberpunk_Is_Bae wrote:

I just assumed the base components of the OS were as full of holes as the package universe clearly is ...

There are no 'base compenents' and 'package universe' as clearly delineated categories.  Linux (writ large) is a community project.  What's on your computer was not written by programmers all working for one company (e.g., Microsoft) but by thousands of people working for all different companies or many just independents.  There is a range of quality control with the Kernel certainly getting a lot more checks and oversight than your average tiling window manager.  But there are also several orders of magnitude more complexity in the kernel than in your average tiling WM, so the former is - by this criteria - more prone to security concerns.

Cyberpunk_Is_Bae wrote:

Do we generally just assume the base components are "completely" secure then?

Absolutely not.  That would be a stunning comination of ignorance and arrogance.  There are new issues discovered daily.  There are also new fixes and patches daily.

Do you "just assume" that airplanes are completely safe?  You shouldn't.  Teams inspect them before every flight.  Engineers test and redesign them periodically.  They are continually checked, prodded, and improved.  This is why we should feel generally ok flying on well maintained planes - not because everyone assumes they are safe, but because there are teams of smart people who do just the opposite and keep working to make them incrementally safer.

Cyberpunk_Is_Bae wrote:

Hmm maybe I'm just being paranoid.

No, you're being self-polarizing.  Assuming everything is completely safe at one extreme or paranoia at the other are not the only options.  Sanity shoud be one.

Last edited by Trilby (2020-03-26 14:24:20)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#14 2020-03-26 16:02:40

Cyberpunk_Is_Bae
Member
Registered: 2020-03-23
Posts: 36

Re: How Do We Stack Up For CVEs?

You make good points.  This one I take one minor issue with:

Trilby wrote:

Do you "just assume" that airplanes are completely safe?  You shouldn't.  Teams inspect them before every flight.  Engineers test and redesign them periodically.  They are continually checked, prodded, and improved.  This is why we should feel generally ok flying on well maintained planes - not because everyone assumes they are safe, but because there are teams of smart people who do just the opposite and keep working to make them incrementally safer.

Generally speaking an aircraft keeps the same functionality throughout its entire life.  In the early days of computing when static, burn-once chips were the home of our programs, we could not afford to make haphazard or fast changes because the cost of doing so would be catastrophic during manufacturing.

Speaking personally, the greatest mental hurdle of using Arch is the idea that things are continually in flux.  I love the architectural purity and democratized paradigm that this OS uses, but the way things continually "reflow" is, again me personally here, very against the grain of what I consider to be the concept of the word "stable."

That was the original impetus for why I created this thread asking about CVE's.  I understand that it's important to make updates, that sometimes updates and features can blur the line of which is which, and that Arch does not distinguish between the two, preferring - to your comment above - to "maintain the engine" and the metaphor is certainly not completely lost on me.  I recognize that an operating system is not a plane.  Equally I recognize that the definition of "maintenance" will differ between the two, and so I hope you do not find my reply willfully obtuse, it is not intended that way.

But to my own personal feelings, when I see my icons change or my window manager's styling update, or (in a prior life) the http change to https in apt-get, or (even earlier) when a package updates and the manual change needed in Slack to make the change involves a deprecated or forked library, I cannot help but to feel that I am being messed with a little, and I long for the predictability of an earlier age.

Offline

#15 2020-03-26 16:56:08

Head_on_a_Stick
Member
From: London
Registered: 2014-02-20
Posts: 7,680
Website

Re: How Do We Stack Up For CVEs?

Cyberpunk_Is_Bae wrote:

the greatest mental hurdle of using Arch is the idea that things are continually in flux

But the rapid stream of updates ensures that your system will always receive the upstream fixes in a timely manner. "Reliability" and "stability" are not necessarily synonymous.

Offline

#16 2020-03-26 17:58:21

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,449
Website

Re: How Do We Stack Up For CVEs?

Cyberpunk_Is_Bae wrote:

In the early days of computing when static, burn-once chips were the home of our programs, we could not afford to make haphazard or fast changes because the cost of doing so would be catastrophic during manufacturing.

True.  Though I'm not sure if this suggests to you that the current situation is more or less safe than those early days.  I would argue computers/software are more secure now (relatively, given the astonomical changes in motivation for wrong-doers).

There were probably not so many listings of CVEs in those early days.  There'd be less motivation to pay people to find flaws in your mass produced and unchangable chip.  Finding a flaw would only expose it as there'd be little to no hope of "patching" for it.  So it would be a public embarassment, and a liability.  But now, finding bugs is an opportunity to fix them because changes can be made quickly.

The fact that the system in question is capable of faster change (compared to "burn-once chips") does not imply that fast changes must be haphazard.

Changes never deliberately create security holes, but certainly on occasion unintentionally do so.  Changes often patch/close security holes.  So on par, changing faster leads to a net increase in securty.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

Board footer

Powered by FluxBB